HTTPS 통신 원리 쉽게 이해하기 (Feat. SSL Handshake, SSL 인증서)

이 글을 쓰게 된 이유는,, 

나의 평소 HTTPS 에 대한 지식은

• HTTPS 가 암호화된 네트워크 통신 프로토콜이고
• HTTPS 를 사용한 네트워크 통신에서는 주고받는 패킷을 까도 데이터가 암호화되어 있어 안전하다!

이 정도였다. 그래서 평소에 근데 어떻게 암호화된 데이터를 서버와 클라이언트는 복호화하고 서로 어떻게 신뢰하지? 등의 원리가 항상 궁금했었는데, 이번 기회(원래 안드로이드 SSL Pinning 공부하다가,, 여기까지 와버렸다^^)에 아주 깔끔하게 이해해버렸다. 너무 시원해 !!!!

---

목차

• HTTPS 기본 개념
• SSL 인증서란, 발급 과정 및 원리
• SSL Handshake 동작 원리 (와이어 샤크로 패킷까지 까 봤다)

 

---

HTTPS 가 뭐야?

혹시 잘 모르는 분들을 위해 짧은 개념 설명.

Hypertext Transfer Protocol Secure 의 준말로, 컴퓨터 네트워크를 통한 보안 통신에 사용되며 인터넷에서 널리 사용된다. HTTPS에서 통신 프로토콜은 TLS(Transport Layer Security) 또는 이전에는 SSL(Secure Sockets Layer)을 사용하여 암호화된다. 따라서 "HTTP over TLS" 또는 "HTTP over SSL" 이라고도 불린다.

HTTPS 를 사용하는 웹 사이트는 https://~ 와 같은 주소를 갖는다.

 

HTTPS 프로토콜을 사용하기 위해서는 인증기관(CA)으로 부터 SSL 인증서를 발급받아야 한다. 

 

---

SSL 인증서

인증서를 발급받은 웹 사이트에서는 아래와 같이 인증서 정보를 확인할 수 있다. 

브라우저에서 SSL 인증서를 확인하는 방법

 

인증서 발급 과정 및 원리 

서버에서 HTTPS 프로토콜 사용을 위해 SSL 인증서를 발급받는 과정은 아래와 같다. 여기서 CA 란 인증기관을 뜻한다.

1. (서버) 서버의 공개키(public key)와 비밀키(private key)를 생성한다.
2. (서버 → CA) 인증서를 발급받기 위해, 서버는 CA 에 아래의 정보들을 전달한다.
   1. 1번에서 생성한 서버의 공개키(public key)
   2. 서버의 각종 정보
3. (CA) 2번에서 서버로부터 받은 정보(서버의 공개키도 들어있음)들을 담아 SSL 인증서를 발급한다.
4. (CA) 3번에서 만든 인증서를 암호화하기 위해, CA의 공개키(public key)와 비밀키(private key)를 생성한다. CA의 비밀키를 이용해 SSL 인증서를 암호화한다.
5. (CA → Server) 4번에서 암호화한 SSL 인증서를 다시 서버에 전달한다. SSL 인증서 발급 완료 😇

위에서 bold 처리한 4번 과정을 잘 기억해둘 것. 아래에서 설명할 SSL Handshake 에서 써먹는 개념이다 !!!

 

이렇게 발급받은 SSL 인증서에 대한 정보(4번에서 생성한 CA의 공개키 정보까지)는 모두 공개되어 있다. 브라우저에서 모두 확인 가능 👇

tistory.com 의 인증서 정보. 공개키 정보까지 모두 볼 수 있다.

 

 

---

 

SSL Handshake 동작 원리 및 과정 

Handshake 란? 악수라는 뜻인데, 쉽게 말하면

• 서버와 클라이언트가 통신을 연결할 때 서로 악수(협상)를 통해 이런저런 정보를 주고받으며,
• 신뢰할 수 있는 서버인지,
• 우리 통신할 때 암호화는 이렇게 하자~

등등을 검증하고 정하는 과정이라고 생각하면 된다.

 

🧤SSL Handshake 의 궁극적 목표 2가지 (이를 통해 얻는 2가지 중요 요소)

요것이 포인트 !!!!

• 서버와 클라이언트가 주고받을 데이터의 암호화 알고리즘을 결정
• 서버와 클라이언트가 주고받을 데이터의 암호화를 위한 동일한 대칭키(데이터를 암호화하는 키)를 얻는다 (대칭키 알고리즘 wiki)

 

자, 그럼 이제 handshake 과정을 살펴볼까? 전체 플로우를 그림으로 보면 아래와 같다. 

출처: https://www.cloudflare.com/ko-kr/learning/ssl/what-happens-in-a-tls-handshake/

 

위 이미지에서 노란색 플로우가 SSL Handshake 과정이다.

파란색 플로우인(SYN, SYN ACK, ACK)는 TCP 프로토콜의 3-way handshake 로, HTTPS 가 TCP 기반의 프로토콜이기 때문에 SSL Handshake에 앞서 연결을 생성하기 위한 과정이다.

 

자자 이제 위 과정들을 단계별로 자세히 살펴보자. 

 

1. client → server 연결을 시도한다 (Client Hello)

클라이언트에서 통신하고 싶은 서버로 연결을 시도하는 패킷을 전송한다. Client Hello 는, 말 그대로 client 가 인사를 건넨다! 라고 이해하면 된다.

이때, 전송하는 패킷에는 아래의 내용들이 들어있다. (아래 패킷 캡처 참고)

• 자신(client)이 사용 가능한 cipher suite 목록 (cipher suite 예시 : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA)
  • 이 cipher suite 에 어떤 프로토콜(TLS/SSL)을 사용할지, 인증서 검증 또는 데이터를 어떤 방식으로 암호화할지 등이 표시된다.
• session id
• ssl protocol version
• 등등~

와이어샤크로 찍어본 Client Hello 패킷 세부내용

 

2. server → client 응답 (Server Hello)

1번에서 클라이언트에서 받은 인사(Client Hello 패킷)에 대해 서버가 응답을 한다. 이 역시 패킷을 찍어보면 Server Hello 라고 나오는 것을 확인할 수 있다.

이때, 서버는 어떤 내용을 담아서 응답하냐면,

• 클라이언트에서 받은 cipher suite 목록 중 선택한 1개의 cipher suite
• ssl protocol version
• 등등

와이어샤크로 찍어본 Server Hello 패킷 세부내용

 

3. server → client (Certificate,  Server Key Exchange,  Server Hello Done)

서버는 2번 패킷 외에 클라이언트에 Certificate 라는 내용의 패킷을 보낸다.

이 Certificate 라는 패킷에는 어떤 내용들이 담겨 있냐면, Server 의 SSL 인증서 내용이 들어있다. 아래의 패킷 내부를 보면, 인증서의 signature algorithm, public key info 등을 확인할 수 있다.

서버가 보낸 인증서 내용을 담고 있는 패킷 세부내용

 

Certificate 패킷을 전달할 때, 보면 Server Key Exchange 가 있는 것을 볼 수 있는데 이건 뭐냐!

위에서 전달한 Certificate 내의 SSL 인증서에 서버의 공개키(public key)가 없는 경우, 서버가 직접 전달함을 의미한다. 즉, 인증서 내부에 서버의 공개키가 존재한다면 Server Key Exchange 는 생략된다! 

그리고 server 가 행동을 마쳤다는 의미로 Server Hello Done 까지 보낸다.

Server Key Exchange 패킷 세부내용

 

 

4. client 에서 server 의 SSL 인증서 검증

3번에서 전달받은 서버의 SSL 인증서를 검증한다. 검증 원리는 아래와 같다.

SSL 인증서를 발급한 CA(인증기관)는 CA의 비밀키(private key)를 이용해 인증서를 암호화했다. 그래서 SSL 인증서는 CA의 공개키를 이용해서만 복호화 할 수 있다. 클라이언트는 해당 CA의 공개키를 통해 암호화된 인증서를 복호화 한다. 즉, 클라이언트에서 CA 의 공개키를 이용해 인증서를 복호화했을 때, 복호화가 되었다는 것은 인증서는 해당 CA 에서 발급되었다라는 것을 검증할 수 있는 것.

 

그렇다면, 클라이언트는 CA 의 공개키를 어디서 구할까?

클라이언트가 브라우저 또는 안드로이드 기기일 경우에는, 인증서를 발급하는 주요 인증기관(CA)의 리스트와 공개키를 가지고 있다. 그래서 매번 CA로 요청하는 것이 아닌 가지고 있는 리스트에서 확인할 수 있다.

그러나, 리스트에 없다면 외부 인터넷을 통해 인증기관의 정보와 공개키를 확보한다. 이것이 SSL 인증서를 사용 시 인터넷 접속이 필요한 이유!

 

🧤 SSL 인증서 검증 정리

1. 클라이언트는 인증서를 발급한 인증기관(CA)의 공개키를 구함.
2. 1번에서 구한 공개키를 이용해 SSL 인증서를 복호화.
3. 복호화 성공 시, 인증서 검증 성공 😇😇

 

5. client → server 대칭키(비밀키) 전달 (Client Key Exchange, Change Ciper Spec)

이제 클라이언트는 서버와 원하는 데이터를 안전하게 주고받기 위해서는 전달하는 데이터를 암호화해야 한다. 클라이언트는 데이터를 암호화하기 위한 대칭키(비밀키, 데이터를 암호화하는 키)를 생성한다. (대칭키 알고리즘 wiki)

 

이렇게 생성한 대칭키(비밀키)를 서버에 전달해야 하는데, 그냥 전달하면 큰일 나겠지? 탈취되면 누구나 주고받는 데이터를 볼 수 있을 테니 ^^;

그래서!!!! 클라이언트는 이 대칭키(비밀키)를 서버만 볼 수 있게 하기 위해, 서버의 공개키로 암호화를 해서 서버한테 전달한다. (Client Key Exchange)

서버의 공개키는 4번에서 SSL 인증서를 복호화해서 얻었었지. 또는 인증서 내부에 없을 경우에는 3번에서 서버로부터 직접 전달받았지(Server Key Exchange).

 

이제 클라이언트는 Change Cipher Spec 을 통해 SSL Handshake 의 완료를 알림. 

 

6. Server / Client SSL Handshake Finished

서버는 클라이언트가 5번에서 전달한 암호화된 대칭키(비밀키)를 받았다. 이 키는 서버의 공개키로 암호화되었으니, 서버의 비밀키로 복호화해서 얻을 수 있다.

이제 서버와 클라이언트 모두 동일한 대칭키(비밀키)를 갖고 있으니, 통신할 준비 완료 !!!

이제 통신할 준비가 완료되었다는 Change Ciper Spec 을 보낸다. 즉, 서버 쪽도 SSL Handshake 준비 완료라는 의미의 패킷.

 

 

 

---

 

휴 이렇게 SSL Handshake 과정에 대해 알아보았다. 최대한 쉽게 풀어쓰려고 했는데,, 양이 너무 많고 누구의 공개키, 비밀키 이런 표현이 많다 보니 처음 보시는 분들은 많이 헷갈리실 것 같다. 이 모든 과정을 간단하게 그림 하나로 표현하고 싶은데, 그려서 오겠다. 😇😇

혹시 틀린 내용이 있거나 질문이 있으시다면 댓글로 남겨주세요🧤🧤🧤🧤

---

Reference

• Cipher suite 란 (Wiki)
• 공개키 알고리즘 (Wiki)
• 대칭키 알고리즘 (Wiki)  
• 유익한 블로그 글 참고