멘토님께서 HTTPS와 SSL을 꼭 다뤄주셨으면 하셨고, 마침 HTTP 통신 과정에서 웹 브라우저 요청 흐름을 공부하던 중에 이 글을 발견했다.

"웹 브라우저가 인터넷에서 서버를 찾으면 웹 서버와 TCP 연결을 설정하고, HTTP를 통해 평문 통신을 시작합니다. 그러나, HTTPS를 사용하는 경우 주고 받는 데이터의 암호화를 위한 TLS (Transport Layer Security) 핸드셰이크라는 추가 과정을 수행합니다. 이는 암호화를 할 상호 대상을 확인하는 것으로 TLS 핸드쉐이크는 데이터 보안 통신에 있어 매우 중요한 주제이므로 더 자세한 것은 직접 학습하시길 권장합니다."

그리하여 오늘 HTTPS와 SSL, TLS에 대해 공부 및 정리해보려한다.

---

HTTPS

HTTPS (HTTP Secure)는 HTTP 프로토콜의 암호화된 버전이다. 클라이언트와 서버 간에 네트워크로 데이터를 전송하기 전에 안전하고 암호화된 연결을 설정한다. HTTPS는 HTTP 요청 및 응답을 SSL 및 TLS 기술에 결합한다.

• HTTPS는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데, 이 보안 계층은 안전 소켓 계층(Secure Sockets Layer, SSL) 혹은 그를 계승한 전송 계층 보안(Transport Sockets Layer, TLS)을 이용하여 구현된다.
  • 그냥 보안 전송 계층을 통해 전송되는 HTTP이다. 암호화되지 않은 HTTP 메시지를 TCP를 통해 전 세계의 인터넷 곳곳으로 보내는 대신에 암호화하는 보안 계층을 하나 더 거치는 것이다.
• 기본 TCP/IP 포트는 443이다.
• 보호의 수준은 웹 브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다.
• URI는https://로 시작한다.

HTTPS 프로세스

1. 서버는 한 쌍의 공개키와 개인키를 생성하고 서버 내 사이트의 각종 정보와 자신의 공개키를 CA에 전달하여 SSL 인증서 생성을 요청함.
2. 인증기관(CA)에서 SSL 인증서를 발급함. 이 인증서에는 서버의 도메인을 비롯하여 서버임을 인증하는 각종 정보를 담고 있음. CA는 한 쌍의 공개키와 개인키를 생성하고 SSL 인증서를 개인키로 암호화하여 서버에게 전달하고 서버는 이 SSL 인증서를 게시함.
3. 웹 브라우저는 CA의 개인키로 암호화된 SSL 인증서를 서버로부터 전달받음. CA의 공개키를 가져와 이 SSL 인증서를 복호화해봄. 복호화되어 서버의 정보와 발급 대상이 CA임을 확인. 웹 브라우저는 이렇게 서버의 공개키를 확보함.
4. 웹 브라우저가 서버를 신뢰하고 있음. 방금 전달받은 서버의 공개키로 실제 데이터 암호화에 사용할 대칭키를 암호화하여 서버에게 전송함.
5. 서버는 웹 브라우저가 자신의 공개키로 암호화하여 전달한 대칭키를 자신의 개인키로 복호화함. 웹브라우저와 서버는 동일한 대칭키를 보유하게 됨.

암호화 Encryption
데이터를 알아볼 수 없는 모습으로 변경하여 감추는 것. HTTPS에서는 후술할 'Key'들을 이용하여 데이터를 암호화함.

복호화 Decryption
암호화된 데이터를 해독이 가능한 평문 데이터로 되돌리는 것을 복호화라고 함. HTTPS에서는 후술할 'Key'들을 이용하여 데이터를 복호화함.

Key
HTTPS에서는 Key가 없으면 데이터 암호화, 복호화가 불가능함.

• 공개키 Public Key : 공개 가능한 키. 암호화 과정에 참여하는 브라우저, 서버 같은 Key 발행자 뿐만 아니라 누구든 알아도 상관없는 존재. 개인키와 쌍을 이루어 존재함 보통 데이터를 암호화하는데 사용. 개인키로 암호화된 데이터는 공개키로 복호화할 수 있음, 공개키로 암호화를 하면 데이터 보안에 중점을 두는 것이다.

• 개인키 Private Key : 오로지 Key 발행자만이 갖는 키. 공개키와 쌍을 이루어 존재. 보통 데이터를 복호화하는데에 사용. 암호화도 가능함. 개인키로 암호화를 하면 인증 과정에 중점을 두는 것이다.

• 대칭키 Symmetric Key : 위의 공개키/개인키처럼 암호화/복호화에 각기 다른 키를 사용하는 것이 아닌 암호화/복호화에 동일한 하나의 키를 사용.

SSL/TLS

TLS Handshake의 과정을 그린 그림. 파란색과 노란색은 네트워크 상에서 전달되는 IP Packet을 표현한 것이다, 맨 윗줄의 SYN, SYN ACK, ACK는 TCP Layer의 3-way handshake로 HTTP가 TCP/IP 기반의 프로토콜이기 때문에 암호화 협상(SSL Handshake)에 앞서 연결을 생성하기 위해 실시하는 과정이고 아래 노란색 상자의 패킷들이 TLS Handshake임.

• TLS는 안전한 인터넷 통신을 위한 암호화 및 인증 프로토콜이다.
• TLS 핸드셰이크는 TLS 암호화를 사용하는 통신 세션을 실행하는 프로세스임.
• TLS 핸드셰이크 중에 통신하는 양측에서는 메시지를 교환하여 서로를 인식하고 서로를 검증하며 사용할 암호화 알고리즘을 구성하고 세션 키(1회용 대칭키)에 합의한다.
• TLS 핸드셰이크는 HTTPS 작동 원리의 근간을 이룬다.

SSL은 원래 HTTP용으로 개발된 암호화 프로토콜이었다. SSL은 오래 전에 전송 계층 보안(TLS)으로 대체되었음. SSL이라는 이름이 아직도 널리 사용되지만 이제는 TLS 핸드셰이크라고 불림.

When?

TLS 핸드셰이크는 사용자가 HTTPS를 통해 웹을 탐색하고 브라우저가 처음 해당 웹 사이트의 원본 서버를 요청하기 시작할 때마다 발생한다. 다른 통신이 API 호출 및 HTTPS를 통한 DNS 요청을 포함하는 HTTPS를 사용할 때에도 발생한다.

TLS 핸드셰이크는 TCP 연결로 TCP 핸드셰이크를 통해 열린 후에 발생함.

TLS Handshake 과정 상세

1. 서버는 CA에 사이트 정보와 공개 키를 전달하여 인증서를 받음
2. 클라이언트는 브라우저에 CA 공개 키가 내장되어 있다고 가정
3. ClientHello(암호화 알고리즘 나열 및 전달)
4. ServerHello(암호화 알고리즘 선택)
5. Server Certificate(인증서 전달)
6. Client Key Exchange(데이터를 암호화 할 대칭 키 전달)
7. Client / ServerHello done (정보 전달 완료)
8. Finished(SSL Handshake 종료)

ClientHello

클라이언트가 서버로 Hello! 메세지를 전송하면서 핸드셰이크를 개시함.

클라이언트가 서버에 연결을 시도하며 전송하는 패킷이다. 자신이 사용 가능한 Cipher Suite 목록, Session ID, SSL 프로토콜 버전, Random Byte 등을 전달한다. Cipher Suite는 SSL 프로토콜 버전, 인증서 검정, 데이터 암호화 프로토콜, Hash 방식 등의 정보를 담고 있는 존재로, 선택된 Cipher Suite의 알고리즘에 따라 데이터를 암호화하게 된다.

클라이언트가 사용 가능한 Cipher Suite를 서버에 제공하는 것을 알 수 있다.

Ciper Suite 구성

암호화 협상을 위한 알고리즘을 모아둔것.

ServerHello

서버는 클라이언트가 보내온 ClientHello 패킷을 받아 CipherSuite 중 하나를 선택한 다음 클라이언트에게 이를 알린다. 또한 자신의 SSL 프로토콜 버전 등도 같이 보낸다.

Certificate

서버가 자신의 SSL 인증서를 클라이언트에게 전달한다. 인증서 내부에는 서버가 발행한 공개키가 들어있다. 클라이언트는 서버가 보낸 CA(Certificate Authority, 인증 기관)의 개인키로 암호화된 SSL 인증서를 공개키를 사용하여 복호화한다.

아래 처럼 암호화 알고리즘을 확인할 수 있음.

Server Key Exchange/ ServerHello Done

서버의 공개키가 SSL 인증서 내부에 없는 경우, 서버가 직접 전달한다는 뜻. 공개키가 SSL 인증서 내부에 있을 경우 Server Key Exchange는 생략.

인증서 내부에 서버의 공개키가 있다면, 클라이언트가 CA의 공개키를 통해 인증서를 복호화한 후 서버의 공개키를 확보할 수 있다. 이후 서버가 행동을 마쳤음을 전달한다.

Client Key Exchange

클라이언트는 데이터 암호화에 사용할 대칭키를 생성한 후 SSL 인증서 내부에서 추출한 서버의 공개키를 이용해 암호화한 후 서버에게 전달한다. 여기서 전달된 대칭키가 TLS Handshake의 목적이자 가장 중요한 수단인 데이터를 실제로 암호화할 키임. 이제 키를 통해 클라이언트와 서버가 실제로 교환하고자 하는 데이터를 암호화한다.

ChangeCipherSpec / Finished

ChangeCiperSpec 패킷은 클라이언트와 서버 모두가 서로에게 보내는 패킷으로, 교환할 정보를 모두 교화한 뒤 통신할 준비가 다 되었음을 알리는 패킷이다. 그리고 Finished 패킷을 보내어 TLS Handshake를 종료하게 된다.

---

🤔💭

HTTP에서 암호화가 추가된 HTTPS에 대해 알아보았고 TCP/IP 핸드셰이크 이후에 발생하는 TLS(SSL) Handshake 과정에 대해서도 알아보았다. 암호화 복호화에 대한 것과 개인키, 공개키, 대칭키, 비대칭 암호화, 대칭 암호화 등에 대해 알아보다보니 시간이 오래 걸렸고 스스로 과정을 그려볼 수 있을 때까지 다시 복습해봐야겠다. SSL이 이제는 TLS로 통용된다는 것도 처음 알았고 워드프레스나 사이트 제작시 SSL 인증키 발급이 어떤 의미였는지에 대해서도 이젠 알 것 같다! http://로 시작되는 사이트에서 크롬은 경고 팝업을 띄우는 것도 보안 및 해킹 우려 때문이라고 깨달았다.
내일 조금 더 내용을 추가할 계획이다.

---

참조 ✅

• 📚 『HTTP 완벽 가이드』
  • 3부 식별, 인가, 보안. 14장. 보안 HTTP
• HTTPS - MDN
• HTTP와 HTTPS의 차이점은 무엇인가요?
• HTTPS 통신과정 쉽게 이해하기
• 대칭키와 비대칭키에 대하여
• TLS 핸드셰이크란?
• TLS&SSL Handshake