HTTPS는 TLS를 이용한 HTTP 통신이다.
TLS(Transport Layer Security)는 비대칭키 암호화(Public Key, Private Key) 방식을 이용한다.
간단히 말해,
Public Key로 데이터를 암호화하면 PrivateKey로 복호화하거나
PrivateKey로 서명하면 PublicKey로 검증하는 방식이다.
암호화나 검증에 사용되는 Key는 Public하게 공개해도 되지만
복호화나 서명에 사용되는 Key는 Private하게 관리되어야 한다.
이것은 TLS의 가장 중요한 원리이다.
그렇다면 비대칭키 암호화 방식이 클라이언트와 서버 간 통신에 필요한 이유는 무엇일까?
클라이언트(웹브라우저)는 서버(웹서버)에 '도메인'(ex. naver.com, google.com)으로 접근한다.
클라이언트는 도메인을 신뢰할 수 없는데, 예를들어 위 그림과 같이, 해커가 DNS 스푸핑으로 클라이언트에게 잘못된 ip를 반환하도록 조작하고 진짜 서버처럼 UI를 꾸미면 클라이언트는 해커서버에 접근한 줄도 모르고 민감한 데이터를 전송할 수 있다. 그러므로 클라이언트는 자신이 접근한 서버가 도메인과 일치하는지를 우선 검증해야하므로 서버에 자격증명을 요청한다.
너가 도메인의 당사자라는 것을 스스로 증명해봐!
서버는 클라이언트에 제공할 '공인된' 자격증명을 가지고 있어야 한다.
서버는 공인된 기관에서 발급된 자격증명을 얻기 위해, PrivateKey로 자격증명 요청서(CSR)를 생성한다. 자격증명요청서에는 PublicKey, 도메인, 요청할 CA기관 정보, 서버 서명 등이 들어간다.
서버가 CA기관에 CSR을 보내면 CA기관은 서버로부터 들어온 CSR을 검증한다.
CSR의 PublicKey로 서버가 PrivateKey로 한 서명을 검증하고 도메인의 소유자가 해당 서버가 맞는지 등의 검증작업을 진행한다. CSR 검증이 완료되면 CA 기관은 CA의 PrivateKey로 인증 서명을 하는데, 이렇게 생성된 인증서가 CRT 파일이다. CA는 서버에게 자신이 서명한 공인된 CRT 파일을 제공한다.
이제 서버는 '너가 도메인의 당사자라는 것을 스스로 증명해봐!' 라고 말하는 클라이언트에게 증명을 할 수 있다.
웹브라우저(클라이언트)는 이미 공인된 CA 기관의 인증서 사본을 내장하고 있다. 서버로부터 CRT 인증서가 날라오면 CA기관의 PrivateKey로 서명된 CRT의 인증 서명을 CA 인증서 사본에 포함된 PublicKey로 검증한다. 검증에 성공하면 클라이언트가 접근한 서버가 해당 도메인의 소유자가 맞음이 검증된 것이다.
검증이 끝나면 암호화의 시간이다.
클라이언트는 서버가 보낸 CRT 인증서 안의 PublicKey를 이용하여 데이터를 암호화하여 서버로 전송한다. 암호화된 데이터가 서버에 도착하면 서버는 PrivateKey로 암호화된 데이터를 복호화한다. 이로써, 클라이언트는 검증된 서버에 데이터를 안전하게 암호화하여 전송할 수 있게 된다.
이것이 Transport Layer Security를 이용한 HTTP 통신인 HTTPS의 개념이다.
'CS > NETWORK' 카테고리의 다른 글
GNS3로 간단한 네트워크망 구성 실습하기 (1) | 2025.07.16 |
---|---|
[Network] VLSM ( Variable Length Subnet Mask ) (0) | 2023.09.14 |
[Network] 서브넷 마스크 이해하기 ( Subnet Mask ) (0) | 2023.09.14 |
HDLC 프로토콜( High-Level Data Link Control ) (0) | 2021.06.24 |
프레임 구조 (0) | 2021.06.24 |