정말 HTTPS에 대해서 알고 있는가?

HTTPS는 왜 이런 구조로 만들어졌을까?

HTTPS의 구조를 제대로 이해하려면, 각 보안 요소들이 왜 필요하게 되었는지를 먼저 이해해야 합니다.

이 글에서는 HTTP의 한계에서 시작해, HTTPS가 지금의 형태로 발전한 과정의 흐름을 순서대로 살펴보겠습니다.

 

우선 HTTP는 웹에서 데이터를 주고받는 통신 규약이고, HTTPS는 여기에 보안을 강화하기 위해 TLS(SSL) 암호화를 추가한 프로토콜입니다. SSL 인증서를 통해...

 

한번에 HTTPS의 통신 구조를 이해하기란 어렵습니다. 여러개의 구조들을 파악하고 어떤 것들이 진정으로 보완이 되어서 완성이 되었는지 이해가 되어야 비로소 HTTPS 구조를 이해할 수 있습니다.

 

HTTP

먼저 HTTP부터 입니다.

HTTP는 웹에서 데이터를 주고받는 기본 통신 규약입니다. 하지만 데이터를 평문(암호화되지 않은 형태)으로 주고받기 때문에,

중간에 제3자가 데이터를 도청하거나 변조할 수 있는 위험이 있습니다. 그렇기에 보안적으로 추가되어야 합니다.

대칭키 방식

보안을 추가해주기 위해 먼저 대칭키 방식으로 시도해보겠습니다.

대칭키 방식은 하나의 키를 통해서 클라이언트와 서버간에 데이터를 암호화하고 복호화하는 방식으로 통신을 해줍니다.

 

그렇다면 해당 키는 어떻게 안전하게 전달해줄 수 있을까요?

만약 이 대칭키를 네트워크를 통해 그냥 평문으로 전달한다면, 중간에서 해당 키가 탈취되어 제 3자가 데이터를 해독할 수 있게 됩니다.

 

그렇게 보완해주기 위해서 HTTPS는 비대칭키 방식을 추가적으로 사용하게 됩니다.

비대칭키 방식

비대칭키는 두 개의 키인 공개키, 개인키를 사용해서 데이터를 암호화하여 통신해줍니다. 서버는 공개키를 전달해주고 클라이언트는 해당 공개키로 세션키를 암호화해서 전달합니다. 해당 세션키는 서버의 개인키로만 복호화할 수 있습니다.

 

그렇게 세션키를 안전하게 전달 받아서 대칭키 방식과 동일하게 해당 세션키(대칭키)를 가지고 데이터를 암호화, 복호화하여 안전하게 데이터를 주고받습니다.

“왜 비대칭만 쓰지 않고 대칭도 같이 쓰는가?”

비대칭키는 보안성은 높지만 연산 속도가 느립니다. 반면 대칭키는 빠르지만 키 교환이 취약합니다.

그래서 HTTPS는 비대칭키로 세션키를 안전하게 교환하고, 실제 데이터 전송은 대칭키로 처리하는 하이브리드 구조를 사용합니다.

SSL 인증서

하지만. 해당 공개키를 만약에 제3자가 줘서 서버인척을 한다면? 클라이언트는 데이터를 무방비하게 주게됩니다. 그렇게 SSL 인증서가 나오게 됩니다. SSL 인증서를 통해 공개키가 신뢰할 수 있는 기관(CA)에 의해 발급되었음을 검증하고, 해당 서버가 실제로 인증서의 도메인과 일치하는지 확인합니다. 최종적으로 신뢰하는 서버에서 키를 주고 받고 데이터를 안전하게 주고 받을 수 있게 됩니다.

HTTPS - (RSA 기반 기준)

최종적으로 HTTPS는 아래와 같은 흐름이 완성됩니다.

1. 클라이언트->서버: ClientHello 전송
2. 서버->클라이언트: SSL 인증서(공개키 포함) 전달
3. 클라이언트->서버: 클라이언트가 인증서를 검증하고 세션키 생성하고, 서버 공개키로 세션키를 암호화 후 전달
4. 서버는 개인키로 복호화하여 같은 세션키 확보
5. 이후 모든 데이터는 세션키(대칭키)로 암호화되어 안전하게 통신