HTTPS는 어떻게 신뢰성있는 통신을 보장할까❓

약 1년만에 고향 티스토리로 돌아와 글을 쓰는 감회가 새롭다

현재 HTTP 완벽 가이드 책으로 스터디를 진행중인데, 14장 보안 HTTP 단원 발표 준비를 하며 당연하게만 쓰고있었던 HTTPS를 제대로 이해보고자 한다

https://2jinishappy.tistory.com/338

대칭 키/공개 키/단방향 암호화 알고리즘(정의와 예시)

이전에 대칭키, 공개키 암호화 알고리즘에 관한 글을 작성한 적이 있었다.

대칭키 공개키가 어떤건지는 알겠는데, 실제로 어떻게 활용되고 있는지 궁금했다.

HTTPS 통신에서 암호화 알고리즘이 적용되는 방식을 확인하고 기본 동작에 대해 이해해보자 ❗️

 

1. HTTPS란

HTTP는 기본적으로 클라이언트-서버 간 TCP 연결을 수립하고 데이터를 주고받는다.

HTTPS는 HTTP 메시지를 TCP로 보내기 전 암호화 하는 SSL/TCS 보안 계층을 추가해서 안전한 데이터 교환을 보장한다.

SSL 트래픽은 바이너리 프로토콜이기 때문에 HTTP와는 다른 포트를 사용해야 한다.

 

2. HTTPS 트랜잭션

scheme이 HTTPS인 요청은 어떤 웹 트랜잭션에서 동작하는지 알아보자.

기본적인 포맷은 HTTP를 따르기 때문에, 커넥션을 수립하기 위한 핸드셰이크 과정 또한 필요하다.

아래 그림은 일반적인 HTTP 연결과 HTTPS 연결의 차이를 나타낸다. 간단하게 HTTPS 트랜잭션이 어떻게 동작하는지 살펴보자.

 

1️⃣ 서버의 443 포트로 TCP 커넥션을 수립한다

2️⃣ SSL 보안 매개변수를 주고받으며 핸드셰이크를 한다

3️⃣ 클라이언트에서 SSL을 통해 보내진 HTTP 요청/TCP를 통해 보내진 암호화된 요청을 전송한다

4️⃣ 서버에서 SSL을 통해 보내진 HTTP 응답/TCP를 통해 보내진 암호화된 응답을 전송한다

5️⃣ SSL 닫힘을 통지한다

6️⃣ TCP 커넥션을 종료한다

 

언급한 것 처럼 SSL 계층을 통해 보안 커넥션을 새로 생성하는 것 이외에는 기존 HTTP 트랜잭션과 크게 다른 것은 없다.

이제 SSL 핸드셰이크 과정이 구체적으로 어떻게 이루어져 있는지, 어떻게 안전한 커넥션을 수립하는지 알아보자.

 

3. SSL 핸드셰이크 과정

SSL 핸드셰이크는 암호화된 HTTP 메시지를 주고받을 수 있게 하는 준비 과정이다.

 

처음에는 호환 가능한 HTTP 프로토콜 버전을 교환한다.

그리고 양쪽이 알고 있는 암호화 알고리즘으로 통신하기 위해, 클라이언트는 서버로 알고리즘 후보들을 보내는 동시에 서버의 인증서를 요구한다.

서버는 해당 목록 중 하나의 암호화 알고리즘을 선택하고, 인증서를 함께 보낸다. (서버 인증서 내부 정보들은 잠시 후 알아보자)

클라이언트는 대칭 키로 사용할 세션 키를 생성하여 인증서에 포함된 공개 키로 암호화한 뒤, 서버로 보낸다.

(서버는 암호화된 세션 키를 자신의 개인 키로 복호화해서 이후 통신 시 해당 세션 키를 사용할 수 있다.)

핸드셰이크가 완료되어 암호화 통신을 시작한다고 알린다.

 

4. 서버 인증서

인증서는 클라 -> 서버에서만 요구하는 것이 아닌, (신뢰할 수 있는 클라이언트인지 확인하기 위한) 클라이언트 인증서도 존재한다.

하지만 대부분의 경우에서는 HTTPS 트랜잭션 상에서 서버 인증서만을 요구한다.

클라이언트 입장에서는 로그인, 신용카드 결제 등의 민감한 요청을 수행할 때 의도한 서버와 통신하고 있는지 확인이 필요하다.

SSL 핸드셰이크 시점에서 얻을 수 있는 서버 인증서의 내용은 아래와 같다.

• 조직 이름
• 주소
• 서버 DNS 도메인 이름
• 인증서 일련번호
• 인증서 유효기간
• 인증서 발급자
• 대상 공개키 및 알고리즘

www.naver.com  에 접속하여 주소창의 자물쇠 버튼을 클릭하면 현재 https로 연결된 서버의 인증서 정보를 확인할 수 있다.

인증서를 이용해서 신뢰성을 보장할 수 있는 방법은 몇 가지가 있다.

• 날짜 검사: 인증서의 시작 및 종료일을 통해 유효성 검사가 가능하다.
• 서명자 신뢰도 검사: 신뢰할만한 기관에서 서명한 인증서인지 확인할 수 있다. 신뢰할 수 없는 인증서일 경우 대부분 브라우저에서 경고창을 표시한다.
• 서명 검사: 서명 기관이 믿을 만하다면, 서명기관의 알려진 공개키를 서명에 적용하여 인증서 무결성을 검사한다.
• 사이트 신원 검사: 인증서 도메인명이 대화중인 서버 도메인명과 일치하는지 검사한다.

 

5. 프록시를 통한 보안 트래픽 터널링

많은 경우에서 클라이언트-서버가 직접 연결되는 대신 프록시 서버가 중간에 위치할 수 있다.

하지만 클라이언트가 서버로 보낼 데이터를 (서버 공개키, 주고받은 세션키)로 암호화했다면, 프락시는 HTTP 헤더를 읽을 수 없다.

이는 곧 프락시가 요청을 전달해야 할 서버를 찾지 못할수도 있다는 것이다.

이를 위해 HTTPS SSL 터널링 프로토콜을 사용한다.

SSL 터널링 프로토콜: 암호화가 시작되기 전, 클라이언트가 먼저 프록시에게 자신이 연결하고자 하는 호스트와 포트를 말해주는 방식

 

아래와 같은 방식으로 CONNECT라 불리는 HTTP Method를 사용하여 프록시에게 희망하는 서버와 연결을 요청할 수 있다.

CONNECT naver.com:443 HTTP/1.0
User-agent: Mozilla/1.1N

...

프록시가 요청의 유효성을 평가하여 커넥션을 연결할 수 있다면, 목적지 서버로 연결을 맺어주고 200 응답을 내려줄 것 이다.

 

정리

HTTPS는 HTTP에 SSL 보안 계층을 추가하여 신뢰성 있는 통신을 가능하게 했다.
클라이언트는 서버 인증서를 확인하여 통신을 검증할 수 있고, 이 과정에서의 위변조 및 데이터 탈취를 방지하기 위해 대칭키 및 공개키 알고리즘을 활용한다.

 

참고자료

• https://www.digicert.com/faq/ssl-cryptography.htm