GiYeong
HTTP / HTTPS 본문
HTTP(Hyper Text Transfer Protocol)
HTTP란 서로 다른 시스템들 사이에서 통신을 주고받게 해주는 가장 기초적인 프로토콜이다.
HTTP는 어플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다.
HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜로서 Method, Path, Version, Headers, Body 등으로 구성된다.
HTTP는 암호화가 되지 않은 데이터를 전송하는 프로토콜이라 네트워크 상에서 중간에 타인이 데이터를 훔칠 수 있다. 해당 문제를 해결하기 위해 HTTPS가 등장했다.
HTTPS(Hyper Text Transfer Protocol Secure)
HTTP 프로토콜에 SSL(Secure Sockets Layer, 보안 소켓 계층)을 사용함으로서 보안 기능을 추가한 것이다.
HTTP 프로토콜은 전송 계층의 TCP 위에서 동작한다. 여기서 SSL이라는 보안 계층이 전송 계층 위에 올라간다.
즉, HTTPS는 SSL 위에 HTTP를 얹어서 보안이 보장된 통신을 하는 프로토콜이다. 해당 통신 방식을 'SSL 암호화 통신'이라고도 부르며, 이는 '대칭 키 암호화' 방식과 '비대칭 키 암호화' 방식을 섞어서 사용한다.
대칭 키(비밀 키) 암호화 방식
하나의 키로 데이터를 암호화하고 복호화하는 방식이다.
암호화 및 복호화에 드는 비용이 적다는 장점이 있지만, 키가 노출되면 보안 상 치명적인 문제가 발생한다는 단점이 있다.
비대칭 키(공개 키) 암호화 방식
공개 키 암호화 방식에는 공개 키와 개인 키(비밀 키) 두 종류의 키가 존재한다.
한쪽 키로 데이터를 암호화했다면, 오직 다른쪽 키로만 복호화를 진행할 수 있다.
즉, 공개 키로 데이터를 암호화하면 반드시 개인 키로만 복호화가 가능하고, 개인 키로 데이터를 암호화하면 공개 키로만 복호화가 가능하다.
보안성이 좋지만, 구현이 어렵고 암호화 및 복호화의 속도가 느리다는 단점이 있다.
1. 암호화에 공개 키, 복호화에 개인 키
진짜 데이터를 암호화하여 보호하기 위한 목적이다.
2. 암호화에 개인 키, 복호화에 공개 키
인증을 위한 목적이다. 즉, 서버에서 개인 키로 데이터를 암호화해서 보내고 클라이언트에서 공개 키로 복호화가 가능하다면 해당 서버는 클라이언트 입장에서 신뢰할 수 있다고 판단할 수 있다.
SSL에서 대칭 키와 비대칭 키를 혼합해서 사용하는 방식
A가 B로 접속 요청을 보내면 B는 A에게 자신의 공개 키를 전송한다.
A는 자신의 대칭 키를 B로부터 받은 공개 키로 암호화하고, 암호화한 자신의 대칭 키를 B에게 전달한다.
B는 자신의 개인 키로 암호화된 A의 대칭 키를 복호화하여 A의 대칭 키를 얻는다.
이렇게 얻은 대칭 키를 활용해서 A와 B가 안전하게 통신한다.
즉, 처음 연결을 성립하여 안전하게 세션 키를 공유하는 과정에서 비대칭 키가 사용되고, 이후 데이터를 교환하는 과정에서는 빠른 연산 속도를 위해 대칭 키가 사용된다.
SSL Handshake의 동작 과정
파란색 칸과 노란색 칸은 네트워크 상에서 전달되는 IP 패킷이다. 파란색 칸에 해당하는 SYN, SYN ACK, ACK는 TCP Layer의 3-way handshake로서, HTTPS가 TCP 기반의 프로토콜이므로, SSL Handshake에 앞서 연결을 생성하는 과정이다.
노란색 칸에 해당하는 패킷들이 SSL Handshake이다.
CA(Certificate Authority)
인증서의 역할은 클라이언트가 접속한 서버가 의도한 서버가 맞는지 보장하는 것이다. 이 역할을 하는 민간 기업들을 CA라고 부른다. CA는 신뢰성이 엄격하게 공인된 기업들만 참여할 수 있다.
개발자 입장에서 HTTPS를 적용하려면 신뢰할 수 있는 CA 기업의 인증서를 구입해야 한다. 이 인증서를 구입하게 되면 CA 기업의 개인 키를 이용하여 암호화 한 인증서를 준다.
SSL 인증서
SSL 인증서에는 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등)와 서버의 공개 키가 들어있다.
ClientHello
클라이언트가 서버에 연결을 시도하며 전송하는 패킷.
자신이 사용가능한 Cipher Suite 목록, Session ID, SSL 프로토콜 버전, Random Byte 등을 전달한다.
Cipher Suite
SSL 프로토콜 버전, 인증서 검증, 데이터 암호화 프로토콜, Hash 방식 등의 정보를 담고있으며, 선택된 Cipher Suite의 알고리즘에 따라 데이터를 암호화하게 된다.
ServerHello
클라이언트가 보낸 ClientHello 패킷을 받아 Cipher Suite 중 하나를 선택하여 클라이언트에게 이를 알린다.
Certificate
서버가 자신의 SSL 인증서를 클라이언트에게 전달한다. 인증서 내부에는 Server가 발행한 공개 키가 들어있다.
클라이언트는 서버가 보낸 CA(Certificate Authority, 인증 기관)의 개인 키로 암호화된 해당 SSL 인증서를 이미 모두에게 공개된 CA의 공개 키를 사용하여 복호화한다. 복호화에 성공한다면, 해당 인증서는 CA가 서명한 것이 맞으므로 진짜임을 검증할 수 있다.
Server Key Exchange / ServerHello Done
서버의 공개 키가 SSL 인증서 내부에 없는 경우, 서버가 직접 전달한다는 뜻이다.
공개 키가 SSL 인증서 내부에 있을 경우, ServerKey Exchange 과정은 생략되고, 클라이언트가 CA의 공개 키를 통해 인증서를 복호화하여 서버의 공개 키를 확보할 수 있다. 그리고 서버가 행동을 마쳤음을 전달한다.
Client Key Exchange
클라이언트는 데이터 암호화에 사용할 대칭 키를 생성한 후, SSL 인증서 내부에서 추출한 서버의 공개 키를 이용해 암호화하여 서버에게 이를 전달한다.
여기서 전달되는 대칭 키가 SSL Handshake의 목적이자 가장 중요한 수단인 '데이터를 실제로 암호화할 대칭 키'가 된다.
ChangeCipherSpec/Finished
ChangeCipherSpec 패킷은 클라이언트와 서버 모두가 서로에게 보내는 패킷으로, 교환할 정보를 모두 교환한 뒤 통신할 준비가 되었음을 알리는 패킷이다.
그리고 Finished 패킷을 보내 SSL HandShake를 종료한다.
정리
- 서버는 CA에 사이트 정보와 공개 키를 전달하여 인증서를 받음
- 클라이언트는 브라우저에 CA 공개 키가 내장되어 있다고 가정
- ClientHello(암호화 알고리즘 나열 및 전달)
- ServerHello(암호화 알고리즘 선택)
- Server Certificate(인증서 전달)
- Client Key Exchange(데이터를 암호화 할 대칭 키 전달)
- Client / ServerHello done (정보 전달 완료)
- Finished(SSL Handshake 종료)
참고
'CS > 네트워크' 카테고리의 다른 글
| TCP/IP 4 계층 (0) | 2022.06.27 |
|---|---|
| OSI 7 계층 (0) | 2022.06.27 |
| REST (0) | 2022.06.25 |
| GET / POST (0) | 2022.06.24 |
| TCP/UDP (0) | 2022.06.22 |
