개념
HyperText Transfer Protocol over Secure Socket Layer
HTTP에 S(Secure Socket)가 추가된 프로토콜
HTTP는 통신내용을 텍스트(아스키 코드)로 주고 받기 때문에 보안에 매우 취약하다.
HTTPS 는 암호화 프로토콜을 사용하여, 이를 암호화는 것이다.
HTTPS를 사용하면 모든 HTTP의 요청과 응답 데이터가 네트워크로 보내지기 전에 암호화된다.
TLS 이라는 프로토콜을 사용하여, 데이터를 암호화한다.
HTTP는 안전 소켓 계층(Secure Socket Layer, SSL)로 구현된 TLS(Transport Layer Security, TLS)을 이용하여 구현이 되고 TCP/IP 포트는 443을 사용한다.
TLS(Transport Layer Security) 란?
전송 계층 보안은 인터넷 상의 개인 정보와 데이터 보안을 용이하게 하기 위해 설계되어 널리 채택된 보안 프로토콜이다.
웹 브라우저와 서버 간의 커뮤니케이션을 암호화하는 것이 대표적으로 알려져있는데
이메일, 메시지, 보이스오버 IP 등 다른 커뮤니케이션을 암호화하기 위해 사용된다.
1994년 넷스케이프 사의 SSL 이 웹 브라우저 보안 프로토콜로 처음 고안되고, 1996년까지 버전 3.0이 발표되었는데 이를 표준화한 것이 TLS 이다.
디지털 암호화
TLS와 HTTPS에 설명하기 전에 암호화에 대해 약간의 배경지식이 필요하다.
-
암호화
- 데이터를 알아 볼 수 없도록 변경하여 감추는 것
-
복호화
- 암호화된 데이터를 해독이 가능한 평문 데이터로 되돌리는 것
-
키
- 암호화의 동작을 변경하는 매개변수
-
대칭키 암호 체계
-
인코딩과 디코딩에 같은 키를 사용하는 알고리즘
-
성능이 좋지만 키를 탈취당하면 답이 없다.
-
한 사람이 여러 사람과 대칭키 암호 체계를 사용해야 한다면, 키의 관리 개수가 계속적으로 증가하여 관리하기가 매우 힘들다.
-
대표 알고리즘으로는 DES, AES, SEED, ARIA 등이 있다.
-
-
비대칭키 암호 체계
- 인코딩과 디코딩에 다른 키를 사용하는 알고리즘
-
공개키 암호법
-
비대칭키 암호 체계를 이용
-
데이터를 인코딩하기 위한 키는 모두 공개되어 있는 공개키이다.
-
하지만 호스트만이 개인 디코딩 키를 알고 있다.
-
모든 사람이 X에게 보내는 메시지는 같은 키로 인코딩이 가능하지만 X를 제외한 그 누구도 그 메시지를 볼 수 없다.
-
대표 알고리즘으로는 RSA, DSA 가 있다.
-
-
디지털 서명
-
메시지가 위조 혹은 변조되지 않았음을 입증하는 체크섬
-
암호 체계는 메시지를 암호화하고 해독하는 것뿐 아니라, 누가 메시지를 썼는지 알려주고 그 메시지가 위조되지 않았음을 증명하기 위해 메시지에 서명을 하도록 하는데 이용될 수 있음
-
-
디지털 인증서
- 신뢰할 만한 인증 조직에 의해 서명되고, 검증된 신원 확인 정보
- 대상의 이름, 유효 기간, 인증서 발급자, 인증서 발급자의 디지털 서명 등을 담고 있음
- 대상과 사용된 서명 알고리즘에 대한 서술적인 정보 뿐만 아니라 보통 대상의 공개키도 담고 있음
HTTPS의 통신 과정
위의 배경지식을 기반으로 웹브라우저와 서버가 어떻게 인증서를 검증하고, 데이터를 암호화/복호화 하는지 살펴보자.
HTTPS는 공개키 암호법과 대칭키 암호체계를 이용한 하이브리드 방식이라 할 수 있다.
TLS Handshake
TLS Hanshake에 앞서 먼저 TCP Layer의 3-way handshake가 먼저 진행된다.
HTTPS가 TCP 기반의 프로토콜이기 때문이다.
그 후 TLS Handshake 가 진행이 되는데 핵심은 다음과 같다.
- 암호화 알고리즘(Cipher Suite) 전달
- 데이터를 암호화할 대칭키(비밀키) 전달
Client Hello
클라이언트가 Server에 연결을 시도하며 전송하는 패킷으로
다음의 목록을 전달한다.
- 사용 가능한 암호한 알고리즘(Cipher Suite) 목록
- Session ID
- TLS Protocol Version
- Random Byte
Server Hello
클라이언트가 보내온 패킷을 받아, 암호화 알고리즘 중 하나를 선택한 다음 클라이언트에게 이를 알린다. 이때 자신의 TLS Protocol Version 등도 같이 보낸다.
Certiciate
서버가 자신의 인증서를 클라이언트에게 전달하는데 인증서 내부에는 서버가 발행한 공개키가 들어가 있다.
클라이언트는 서버가 보낸 CA(Certificate Authority, 인증기관)의 개인키로 암호화된 이 인증서를 이미 모두에게 공개된 CA의 공개키를 사용하여 복호화한다.
복호화에 성공하면 이 인증서는 CA가 서명한 것이 맞으므로 인증이 완료된다.
클라이언트는 데이터 암호활에 사용할 대칭키를 생성한 후, 인증서 내부에 들어있던 공개키를 이용해 암호화하여 서버엑 전송한다.
Server Key Exchange / ServerHello Done
Server Key Exchange는 서버의 공개키가 인증서 내부에 없는 경우, 서버가 직접 전달하는 뜻이다. (공개키가 인증서 내부에 있을 경우에 이 과정은 생략된다.)
인증서 내부에 공개키가 있다면 클라이언트가 CA의 공개키를 통해 인증서를 복호화한 후, 서버의 공개키를 확보할 수 있다. 그리고 서버가 행동을 마쳤음을 전달한다.
Client Key Exchange
대칭키(데이터를 실제로 암호화하는 키)를 클라이언트가 생성하여,
인증서 내부에서 추출한 서버의 공개키를 이용해 암호화한 후, 서버에게 전달한다.
여기서 전달된 대칭키가 바로 TLS Handshake의 목적이자, 가장 중요한 수단이다.
ChangeCipherSpec / Finished
클라이언트, 서버 모두가 서로에게 보내는 패킷으로 교환할 정보를 모두 교환한 뒤,
통신할 준비가 다 되었음을 알리는 패킷이다.
'Finished' 패킷을 보내어 Handshake를 종료하게 된다.
위의 과정을 정리하면...
ClientHello (클라이언트에서 가능한 암호화 알고리즘 나열 및 전달)
ServerHello (암호화 알고리즘 선택)
Server Certificate (인증서 전달, 인증서에는 공개키가 포함되어 있음)
Client Key Exchange (인증서를 공인기관의 키로 복호화 한 후, 사이트 공개키로 대칭키를 암호화하여 전달)
Client / ServerHello Done (정보 전달 완료)
Finished (Handhsake 종료)
로 진행이 된다.
참조한 책 및 사이트
HTTP 완벽 가이드
https://aws-hyoh.tistory.com/39
https://www.cloudflare.com/ko-kr/learning/ssl/how-does-public-key-encryption-work/
https://rachel-kwak.github.io/2021/03/08/HTTPS.html
https://reakwon.tistory.com/106
https://raonctf.com/essential/study/web/asymmetric_key