HTTP는 HyperText Transfer Protocol 의 약자로 인터넷 상에서 데이터를 주고 받을 수 있는 프로토콜이다. HTTP는 따로 암호화 과정을 거치지 않아 중간에 패킷을 탈취당할 수 있다. 이를 보완하기 위한 것이 HTTPS이고, 쉽게 말해 HTTP에 보안 계층을 추가한 것이다.
SSL/TLS
SSL
Secure Socket Layer 의 약자로 클라이언트와 서버 간 보안을 위한 프로토콜이다. 1.0은 대중에게 공개되지 않고 2.0부터 공개됐는데 몇 가지 취약점 때문에 1년 만에 SSL 3.0으로 대체되었다고 한다.
TLS
SSL 3.0을 표준화한 프로토콜이 TLS (Transport Layer Security)이다. SSL 3.0과 극적인 차이가 있는 것은 아니지만 둘은 서로 상호 운용되지 않는다.
SSL 통신 과정
SSL/TLS는 보통 SSL 인증서를 이용한다. SSL 인증서는 클라이언트와 서버 사이의 통신을 공인된 제 3자가 보증해주는 문서로 공개키, 발급자, 유효 기간 등의 정보가 담겨 있다. 보증해주는 제 3자를 CA (Certificate Authority)라고 한다. 인증서는 통신 내용이 노출이나 변경되는 것을 방지하고 해당 서버가 신뢰할 수 있는 서버임을 보장해준다.
(사진 출처 - 티스토리)
HTTPS도 TCP 기반의 프로토콜이기 때문에 위 사진에서 파란색으로 표시된 것처럼 3-way handshake 과정을 통해 가상 연결을 확립한 후 SSL handshake 과정이 이루어진다.
(사진 출처 - 블로그)
- 클라이언트 → 서버로 랜덤 데이터와 사용 가능한 암호화 방식을 보낸다.
- 서버 → 클라이언트로 랜덤 데이터, 사용할 암호화 방식과 SSL 인증서를 보낸다.
- 클라이언트는 서버에게 받은 인증서의 CA가 자신이 들고 있는 CA 리스트에 있는지 확인하고, 있다면 CA의 공개키로 복호화한다. 이는 곧 CA 비밀키에 의해 암호화됐다는 것이므로 인증서의 신원을 보증해준다. (공개키 암호화 방식)
클라이언트는 자기가 보낸 랜덤 데이터와 서버로부터 받은 랜덤 데이터를 조합하여 임시 키 (pre master secret key)를 만든다.
- 만들어진 임시 키를 인증서의 공개키로 암호화하여 서버에게 보낸다.
- 서버는 자신이 들고 있던 비밀키로 임시 키를 복호화한다.
- 이로써 클라이언트와 서버는 동일한 임시 키를 공유하게 되는데, 일련의 과정을 거쳐 master secret 값을 만들고 세션 키를 생성한다.
- 이렇게 만들어진 세션 키로 암호화된 데이터를 주고받는다. (대칭키 암호화 방식)
- 세션이 종료되면 클라이언트와 서버 모두 세션 키를 폐기한다.
이렇게 공개키 암호화 방식과 대칭키 암호화 방식을 조합해서 사용하는 이유는 아래와 같다.
- 공개키 방식은 컴퓨터 파워를 많이 사용한다. 그래서 요청이 쏠리는 경우 서버는 과금을 내야 한다.
- 대칭키 방식은 암호를 푸는 열쇠인 대칭키를 상대방에게 줘야 한다. 하지만 인터넷을 통해 키를 전송하는 것은 위험하다.
그래서 채널을 수립할 때에는 공개키 방식을 이용해 보다 안전한 채널을 수립하고, 이후 데이터를 주고받을 때 대칭키를 통해 암호화하여 주고 받는다.
