1. HTTP(HyperText Transfer Protocol)의 문제점
HTTP는 OSI 7 계층의 애플리케이션 계층에서 사용되는 프로토콜이다. 따라서 애플리케이션 간에 데이터를 주고받기 위해 HTTP 프로토콜을 사용할 수 있다. HTTP는 클라이언트와 서버가 데이터를 주고받을 때 암호화되지 않은 평문을 전송하기 때문에, 네트워크 중간에서 스니핑을 통해 데이터를 가로챌 수 있다.
즉, HTTP는 통신 과정에서 평문을 주고받기 때문에 매우 취약하다는 문제점이 존재하다.
2. 그래서 등장한 것이 HTTPS
HTTPS는 HyperText Transfer Protocol Secure이다. 이름에서 알 수 있듯이 기존의 HTTP 프로토콜에 보안 기능이 추가된 것이다. HTTPS는 HTTP와 달리 평문을 주고받는 것이 아니라 평문을 암호화한 암호문을 주고받는다. 따라서 제3자가 클라이언트와 서버가 주고받는 데이터를 스니핑 한다고 한들, 이 데이터는 암호화되어 있기 때문에 무슨 말인지 이해할 수 없다.
3. HTTPS를 사용하기 위해서는 서버는 TLS 인증서를 발급받아야 한다.
서버는 CA(Certificate Authority)로부터 TLS 인증서를 발급받아야 클라이언트와 서버가 HTTPS 통신이 가능하다. TLS 인증서에는 CA의 서명이 포함되어 있기 때문에, 해당 웹 사이트가 신뢰할 수 있는 사이트임을 CA가 인증하게 된다.
TLS 인증서에 CA의 서명이 포함되어 있기 때문에, 브라우저는 이를 믿고 서버와 HTTPS 통신이 가능한 것이다.
참고로 과거에는 SSL을 사용했고, 현재는 TLS를 사용한다. TLS는 SSL을 계승한 것이라 생각하면 된다.
4. HTTPS에서 평문을 암호화하기 위해서는 대칭키를 사용한다.
HTTPS 통신을 하기 위해서 서버는 CA가 발급한 TLS 인증서가 필요함을 알았다. 그렇다면 TLS 인증서 가지고 어떻게 평문을 암호화하여 통신할 수 있는 것일까?
HTTPS 통신을 통해 암호화/복호화를 하기 위해서는 대칭키 또는 공개키가 필요하다. 왜냐하면 키가 있어야 클라이언트는 평문을 암호화할 수 있고, 서버는 복호화할 수 있기 때문이다. 따라서 클라이언트와 서버는 암호화/복호화에 사용할 키를 가지고 있어야 하는데, 이 키를 공유하기 위해서 하이브리드 방식을 사용한다. 하이브리드 방식을 사용하여 클라이언트와 서버가 사용할 대칭키를 공유할 수 있는 것이다.
5. 무슨 말인지 모르겠다면?
- 왜 하이브리드 방식으로 대칭키를 공유하는지에 대해서
- TLS 인증서에 대해서
- 공개키와 대칭키에 대해서
- CA에 대해서
- ...
사전 지식이 부족하기 때문에 본 글을 이해하기 어렵다면, https://server-technology.tistory.com/532 를 읽은 후, 다시 읽어보는 것을 추천한다. 그래도 이해되지 않는다면 구글링을 해서 이해하도록 한다.