HTTPS 통신을 파헤쳐 보자

본 포스팅에서는 이전에 정리했던 HTTPS 통신 과정에서 생략된 부분이나 부족했던 개념을 보충하며 자세하게 하나하나 뜯어서 다루어보려고 한다.

HTTPS 통신은 HTTP 통신 과정에서 중요한 데이터를 암호화하는 과정을 추가시킨 것이라고 볼 수 있는데, 이에 사용되는 SSL HandShak, 인증서(CA) 전달, 세션키(대칭키)의 생성 및 전달, 암호화 알고리즘 등에 대해 알아보자.

1. SSL HandShake

SSL HandShake는 송/수신자 간의 암호환 데이터를 교환하기 위한 일련의 협상과정이다. 데이터를 암호화 할 세션키를 만들고 이를 안전하게 전달하는 과정이라고 볼 수 있다. HTTPS는 TCP(연결지향성)기반의 프로토콜이기 때문에, SSL HandShake에 앞서 클라이언트와 서버간의 연결을 생성하는 과정을 우선적으로 거친다.

각 과정을 알아보기 전, SSL HandShake은 어떤 방식으로 키를 주고받는지 간단하게 알아보자.

하이브리드 방식

하이브리드 방식이란, 대칭키/비대칭키 전략을 모두 사용하는 방법이다.
대칭키 전략은 같은 키를 사용하기에 과정이 비교적 간단하지만 탈취위험 등 보안성에 위험이 있으며, 비대칭키(공개키) 전략은 서로 다른 키를 사용하기에 과정이 복잡하지만 안전하다.
데이터의 암/복호화에 사용되는 방식에는 세션키(대칭키) 전략을 사용하는데, 이 세션키의 전달 과정을 비대칭키 전략을 사용하여 효율성과 안정성을 모두 확보한 방식이다.

1-1. Client Hello - (Client Side)

Client Hello 는 클라이언트(브라우저)가 웹 서버에 연결을 시도하며 전송하는 패킷이다. 아래의 정보를 담아 해당 단계에서 보낸다.

- SSL Protocol Version: 브라우저가 사용하는 SSL(TSL) 버전 정보
- Cipher Suite: 브라우저가 지원하는 암호화 방식
- Random Byte: 브라우저가 생성한 난수
- SSL handshake가 완료된 상태라면, 그 때 생성된 Session ID
기타 정보 (Session Id, Session Ticket ... etc)

Cipher Suite의 종류

이미지 출처: https://aws-hyoh.tistory.com/39

1-2. Server Hello - (Server Side)

웹 서버는 Client Hello에 응답하며 아래의 정보를 담아 클라이언트에게 보낸다.

- Cipher Suite: 브라우저의 암호화 방식 중, 서버가 지원하고 선택한 암호화 방식
- Random: 서버가 생성한 난수
기타 정보

이미지 출처: https://aws-hyoh.tistory.com/39

위와 같이 하나의 Cipher Suite만 선택된 것을 알 수 있다.

1-3. Certificate - (Client Side)

Server는 자신의 공개키가 포함된 SSL 인증서를 Client에게 전달한다.(CA에서 발급한 비밀키로 암호화 됨) Client는 Server가 보낸 SSL 인증서를 CA(Certificate Authority, 인증기관)의 공개키를 사용하여 복호화 한다. 이 과정을 통해 SSL 인증서가 CA에서 서명받았음을 검증한다.

이미지 출처: https://aws-hyoh.tistory.com/39

위와 같이 SSL 인증서가 무슨 알고리즘(RSA)로 암호화 되고, 무슨 Hash 알고리즘(SHA256)으로 서명되어있는지 확인이 가능하다.

1-4. Server Key Exchange / Server Hello Done - (Server Side)

해당 과정은 Server의 공개키가 SSL 인증서 내부에 없는 경우, Server가 직접 전달함을 의미한다. 공개키가 SSL 인증서 내부에 있는경우 해당 과정은 생략된다. 그리고 Server는 행동을 마쳤다는 Server Hello Done 패킷을 전달한다.

1-5. Client Key Exchange / ChangeCipherSpec - (Client Side)

Client는 자신과 서버의 난수를 조합하여 SSL 인증서에서 추출한(혹은 전달받은) 공개키로 암호화 하여 세션키(Pre-master-secret)를 생성한 뒤, 서버로 전달한다.

여기서 전달된 '세션키/대칭키(Pre-master-secret)'가 바로 SSL HadnShake의 주목적 이다. 해당 키를 통해 이후의 데이터를 실제로 암호화 한다.

이러한 방법은 RSA 키 교환 알고리즘의 방식에 해당되며, Diffie-Hellman(DH, HDE) 알고리즘을 사용하는 경우 세션키를 생성하기 위한 재료들을 Client와 Server가 교환하게 되며 각자 재료들을 합쳐 동일한 세션키(대칭키)를 생성한다고 한다.

클라이언트는 통신할 준비가 완료되었음을 알리는 ChangeCipherSpec 패킷을 최종적으로 전달한다.

1-6. ChangeCipherSpec - (Server Side)

Client Key Exchange 과정을 통해 클라이언트와 서버는 세션키(대칭키)의 준비를 모두 마쳤다. 서버 클라이언트가 가진 pre-master secret은 일련의 과정을 거쳐 master secret으로 만들며 master secret으로 session key를 생성한다.

서버또한 통신할 준비가 완료되었음을 알리는 ChangeCipherSpec 패킷을 최종적으로 전달한다.

1-7. Data - (Server Side)

서버는 세션키를 통해 암호화 된 데이터를 클라이언트로 전달하고, 클라이언트는 세션키를 통해 데이터를 복호화 한다!

2. SSL HandShake 그 이후..

HTTPS의 통신 과정을 보면 SSL HandShake 과정이 모두 수립되어야 암호화된 데이터를 주고 받을 수 있다. 하지만 매번 handshake 과정을 반복하게 된다면 트래픽이 증가하는 상황에서 많은 지연시간과 비효율성이 발생할 수 있다.

이런점을 해결하기 SSL HandShake 과정을 개선하여 간소화 하는 방법이 2가지 있다고 한다!

2-1. SSL IDentifier

최초 통신과정

최초의 SSL HandShake 과정에서, Client Hello 패킷에 Session id값이 존재하지 않는다. 서버에서 Server Hello 메시지에 Session id를 포함하여 전달하게 되면 클라이언트는 이를 로컬에 저장한다.

클라이언트는 다음 HTTPS 통신을 맺을 때, 아래와 같이 Session id를 사용하게 된다.

이미지 출처: https://aws-hyoh.tistory.com/39

이후 통신과정

서버는 클라이언트가 전달한 Session id정보를 검증하고 유효하다면, Session id값을 포함하여 전달한다.

클라이언트는 전달받은 Session id가 같은지(유효한지) 확인이 되면 다음의 과정들을 생략할 수 있다.

1. 서버의 SSL 인증서 확인 (CA의 공개키로 복호화)
   (1-3. Certificate 생략)
2. 암/복호화에 사용되는 Cipher Suite 결정
3. 암/복호화에 사용되는 세션키(pre-master-secret) 교환
   (1-4. Server Key Exchange, 1-5. Client Key Exchange 생략)

이전의 SSL HandShake 과정을 통해 저장된(교환없이) pre-master secret 정보를 통해 동일한 세션키를 생성하여 데이터를 암/복호화한다.

2-2. Session Ticket

최초 통신과정

Session Ticket 메커니즘을 사용하기 위해서는 서버와 클라이언트 모두 해당 메커니즘을 지원해야한다. 따라서, Client Hello 패킷에 값이 없는 Session Ticket을 담아 서버에 전달해야 한다. (Server Hello도 마찬가지)

서로 Session Ticket이 지원되는 것을 확인했다면 SSL 인증이 완료됨을 알리는 ChangeCipherSpec 단계에서 New Session Ticket 메시지를 서버의 비밀키로 암호화 하여 클라이언트에게 전달한다.

이후 통신과정

클라이언트는 저장된 New Session Ticket 메시지를 Client Hello 패킷에 담아 서버에 전달하며, 서버는 이를 비밀키로 복호화 하여 이전 세션에 대한 정보(pre-master secret, Cipher Suite)를 사용한다.

2-3. Session id와 Session Ticket중에 무엇을?

둘 다 이전 세션의 정보를 재활용함으로서 SSL HandShake의 과정을 간소화 하는것은 똑같다!

• Session id 방식은 서버에 세션 정보를 저장하기 때문에 그 양이 많아진다면 메모리 자원에 영향을 줄 수 있다.
• Session Ticket 방식은 클라이언트가 New Session Ticket을 저장하는 방식이기 때문에 서버의 메모리 자원에 적은 영향을 주지만, Session Ticket을 암/복호화 하는 과정에서 CPU 부담이 발생하며 Cookie와 비슷하게 XSS와 같은 공격에 대한 탈취위험이 있다.

현재는 Sesssion Ticket 방식이 더 많이 사용된다고 한다. (TLS 1.3의 기본 세션 재사용 방식이 Session Ticket)

[참고문헌]

https://aws-hyoh.tistory.com/39
https://velog.io/@wonseok97/%EB%8C%80%EC%B9%AD%ED%82%A4%EC%99%80-%EB%B9%84%EB%8C%80%EC%B9%AD%ED%82%A4
https://velog.io/@wonseok97/HTTP%EC%99%80-HTTPS
https://velog.io/@gs0351/%EB%8C%80%EC%B9%AD%ED%82%A4-vs-%EA%B3%B5%EA%B0%9C%ED%82%A4%EB%B9%84%EB%8C%80%EC%B9%AD%ED%82%A4