1. HTTPS란?
- Hypertext Transfer Protocol Secure
- 인터넷에서 데이터를 전달하는 TCP 프로토콜의 일종인 HTTP에 Secure 기능을 더한 것.
- TLS(Transport Layer Security) or SSL(Secure Socket Layer)를 사용하여 암호화된 프로토콜.
TLS? SSL?
- TLS는 SSL의 개선된 버전으로, 최신 인증서는 대부분 TLS를 사용하지만, 편의상 SSL 인증서라고 말함.
- TCP, UDP와 같은 일반적인 인터넷 통신에 안전한 계층(layer)를 추가하는 방식.
- 이 기술을 구현하기 위해 웹 서버에 설치하는 것이 SSL/TLS 인증서.
HTTPS가 필요한 이유
- 브라우저와 웹 서버 간 데이터를 암호화.
- 접속한 웹 사이트가 믿을만한지 검증.
2. HTTPS에 필요한 것들
- 웹 브라우저는 공신력 있는 CA(Certificate Authority, 인증 기관)의 정보와 CA의 공개키를 브라우저 내부에 보관함.
- 웹 서버는 CA(Certificate Authority)에서 SSL/TLS 인증서를 발급받아야 함.
- 서버에서 공개키와 개인키를 생성함.
- 인증서를 발급받기 위해서 서버는 서버의 공개키와 각종 정보를 CA로 전송함.
- CA는 서버의 공개키와 정보를 담아 SSL 인증서를 발급함.
- CA에도 개인키와 공개키가 존재함. CA는 해당 SSL 인증서를 CA의 비밀키로 암호화함.
- CA는 CA의 비밀키로 암호화된 SSL 인증서를 서버로 전송함.
2. SSL Handshake 과정
- handshake를 통해 서버와 클라이언트는 통신을 위한 정보를 주고 받음.
- 신뢰할 수 있는 서버인지 검증하고, 암호화 알고리즘을 결정함.
- SSH처럼, 서버와 클라이언트가 주고 받을 데이터의 암호화를 위한 대칭키를 얻음.
2-1. Client -> Server (Client Hello)
- 브라우저가 웹 서버에 요청
- 브라우저는 다음 정보를 Client Hello 단계에서 서버로 전송함
- 브라우저가 사용하는 SSL/TLS 버전 정보
- 브라우저가 지원하는 암호화 방식 모음(cipher suite들)
- 브라우저가 생성한 임의 난수(client random)
- 이전에 SSL handshake가 완료된 상태라면, 그 때 생성된 세션 아이디
- 기타 정보
2-2. Server -> Client (Server Hello)
- 웹 서버가 브라우저로 응답
- 웹 서버는 다음 정보를 Server Hello 단계에서 서버로 전송함
- 브라우저의 암호화 방식 정보(cipher suite)들 중에서 서버가 지원하고 선택한 1개의 암호화 방식
- 서버가 생성한 임의 난수(server random)
- 기타 정보
2-3. Server -> Client (Certificate, Server Key Exchange, Server Hello Done)
- 서버는 클라이언트에 Certificate(SSL 인증서)라는 패킷을 보냄.
- 클라이언트는 서버의 공개키를 알아야 한다.
- 만약 Certificate 내부 SSL 인증서에 서버의 공개키가 없는 경우, Server Key Exchange를 통해 서버의 공개키를 직접 전달함.
- SSL 인증서 내부에 서버의 공개키가 존재한다면 Server Key Exchange는 생략됨.
- 서버가 행동을 마쳤다는 의미로 Server Hello Done 응답을 마지막으로 보냄.
2-4. Client에서 Server의 SSL 인증서 검증
- 클라이언트 브라우저는 SSL 인증서를 발급하는 주요 인증기관(CA)의 리스트와 공개키를 가지고 있음.
- 서버에게서 받은 SSL 인증서를 해당 인증서를 암호화했던 CA의 공개키를 찾아 복호화함.
여기까지 과정을 통해서 해당 웹사이트가 믿을만한지 검증할 수 있음.
브라우저와 웹 서버 간 전송되는 데이터를 대칭키(비밀키, SSH에서 세션키와 같은 역할)를 통해 암호화해야 함.
2-5. Client -> Server 대칭키 전달 (Client Key Exchange, Change Ciper Spec)
- 클라이언트는 임의의 숫자 pre-master secret를 생성함.
- 이를 서버의 공개키로 암호화하여 서버에 전달함. (Client Key Exchange)
- 서버에서는 암호화된 pre-master secret을 서버의 개인키로 복호화함.
- Client와 Server에서는 client random, server random, pre-master secret을 통해 대칭키를 유도함.
- 이 과정을 통해 서버와 클라이언트는 안전하게 같은 대칭키를 생성할 수 있음.
- 모든 준비가 끝남. 따라서 클라이언트는 Change Cipher Spec을 통해 SSL Handshake의 완료를 알림.
2-6. Server / Client SSL Handshake Finished
- 서버는 서버의 개인키를 통해 복호화된 대칭키를 얻을 수 있음.
- 서버와 클라이언트가 서로 동일한 대칭키를 가지고 있기 때문에, 암호화된 통신이 가능해짐.
- 서버 측에서도 통신할 준비가 완료되었다는 Change Ciper Spec을 보냄.
3. 굳이 대칭키를 쓰는 이유?
- 비대칭키를 사용하여 암호화 복호화하는 것에 컴퓨팅 자원이 더 많이 소모되기 때문.
- 따라서 SSL Handshake 단계까지는 비대칭키 방식을 사용하고, 그 이후 HTTPS 통신은 대칭키 방식을 사용함.
출처
https://yozm.wishket.com/magazine/detail/1852/
https://jaeseongdev.github.io/development/2021/07/02/HTTPS,SSL,TLS/
https://nuritech.tistory.com/25
https://inuplace.tistory.com/1086#cf.-ssl-vs-tls
https://dokydoky.tistory.com/463
https://www.youtube.com/watch?v=tQaxITImKys
https://www.youtube.com/watch?v=H6lpFRpyl14
handsome