이번에 많이 사용하는 HTTPS의 동작 방식이 궁금하여 알아보게 되었다.
1. HTTP란?
HyperText Transfer Protocol의 약자로 컴퓨터와 인터넷 상에서 웹문서를 주고받기 위한 프로토콜이다.
클라이언트가 서버에 요청하면 응답이 오는 1:1 메시지 교환 방식이다.
2. HTTP의 보안 문제
HTTP의 보안 문제는 크게 3가지가 있다.
하나씩 알아보자.
1. 기밀성 없음
다른 문제 중에 가장 큰 문제로 네트워크 상에서 데이터를 전송할 때 암호화 없이 전송한다.
예를 들어 로그인 요청을 다음과 같이 보낼 때
Id : Admin1
password : 1234!평문으로 데이터가 전송되기 때문에 누군가가 패킷을 볼 수 있다면 위 정보를 전부 확인할 수 있다.
공유 와이파이를 사용할 때 특히 취약하다.
공격자가 네트워크를 감시하면서 평문으로 이동하는 데이터를 갈취하여 사용할 수 있다.
2. 무결성 없음
HTTP는 데이터가 변경되었는지 확인할 방법이 없다.
서버에 요청한 정보:
상품가격: 1000원공격자가 중간에서 수정:
상품가격: 10000원브라우저는 원래 서버가 보낸 정보인지 중간에 수정된 정보인지 알 수 없다.
과거 일부 ISP들은 사용자들이 보는 웹페이지에 광고 코드를 몰래 삽입하여 변조했던 사례도 있다.
3. 서버 인증 없음
HTTP는 내가 접속한 서버가 진짜인지 알 방법이 없다.
예를 들어서 은행 업무를 위해 bank.com에 접속했다고 가정해 보자.
이때 공격자가 중간에 서버를 가짜 bank.com 서버로 연결시켜도 브라우저는 구분할 수 없다.
여기서 은행 업무를 위해 여러 개인정보를 입력한다면, 진짜 서버로 이동되는 게 아닌 가짜 서버로 이동되기 때문에 보안에 취약하다.
이러한 공격을 Man-in-the-Middle Attack이라고 부른다.
3. HTTPS 등장 배경
앞서 말한 HTTP의 문제점을 해결하기 위해 HTTPS가 등장하게 되었다.
HTTPS는 HTTP의 문제점인 도청, 변조, 위조 서버 접속 등의 보안 문제를 해결하기 위해 TLS를 적용하여 암호화, 무결성 검증, 서버 인증 기능을 제공하여 안전한 웹 통신을 가능하게 한다.
4. SSL/TLS 소개
HTTP의 보안 취약점을 SSL/TLS를 추가하여 문제점을 해결한다.
HTTP + SSL/TLS = HTTPS
SSL과 TLS의 차이
SSL과 TLS는 별개의 기술이 아닌 발전 과정이다.
과거에 사용했던 SSL은 현재에 문제점이 발견되어 SSL은 사용하지 않고 TLS를 사용 중이다.
하지만 역할이 비슷하여 아직까지도 TLS를 SSL이라고 부르기도 한다.
| 버전 | 출시 | 상태 |
|---|---|---|
| SSL 2.0 | 1995 | 사용 금지 |
| SSL 3.0 | 1996 | 사용 금지 |
| TLS 1.0 / 1.1 | 1999 / 2006 | 사용 중단 권고 |
| TLS 1.2 | 2008 | 현재도 널리 사용 |
| TLS 1.3 | 2018 | 최신 권장 버전 |
SSL/TLS의 역할
SSL/TLS가 HTTP의 단점을 개선하기 위해 나온 만큼 HTTP의 단점들을 해결할 수 있는 역할이 제공된다.
1. 기밀성 (Confidentiality)
데이터를 암호화한다.
HTTP에서 평문으로 보내던 데이터를 암호화하여 전송함으로써 가로채도 데이터를 읽을 수 없다.
2. 무결성 (Integrity)
데이터가 변조되었는지 확인한다.
공격자가 중간에서 값을 변경하여 전송하여도, TLS가 이를 감지하여 통신을 중단한다.
3. 인증 (Authentication)
내가 접속한 서버가 진짜 서버인지 확인한다.
TLS 인증서를 이용하여 확인한다.
5. 공개키와 대칭키 암호화
TLS는 두 가지 암호화 방식을 함께 사용한다.
대칭키 암호화 (Symmetric Key)
암호화와 복호화에 같은 키를 사용하는 방식이다.
평문 --[키 A로 암호화]--> 암호문 --[키 A로 복호화]--> 평문- 장점: 속도가 빠르다.
- 단점: 키를 상대방에게 안전하게 전달하기가 어렵다. 전달 과정에서 키가 탈취되면 암호화가 무의미해진다.
공개키 암호화 (Public Key / 비대칭키)
암호화와 복호화에 서로 다른 키 한 쌍(공개키, 개인키)을 사용하는 방식이다.
평문 --[공개키로 암호화]--> 암호문 --[개인키로 복호화]--> 평문- 공개키(Public Key): 누구에게나 공개되는 키
- 개인키(Private Key): 서버만 비밀로 보관하는 키
- 장점: 공개키는 공개해도 되므로 키 전달 문제가 없다.
- 단점: 대칭키 방식보다 연산이 느리다.
TLS가 두 방식을 모두 사용하는 이유
두 방식의 장단점을 조합하여 보안과 성능을 동시에 확보한다.
| 단계 | 사용 방식 | 이유 |
|---|---|---|
| 연결 초기 (Handshake) | 공개키 암호화 | 대칭키(세션키)를 안전하게 교환하기 위해 |
| 실제 데이터 전송 | 대칭키 암호화 | 빠른 속도로 암호화된 통신을 하기 위해 |
즉, 공개키로 대칭키를 안전하게 주고받은 후, 이후 통신은 대칭키로 빠르게 처리하는 것이다.
6. TLS Handshake 과정
TLS Handshake는 클라이언트와 서버가 암호화 통신을 시작하기 전에 서로를 인증하고 세션키를 협상하는 과정이다.
TLS 1.2 Handshake (2-RTT)
Client Server
| |
|-------- 1. Client Hello ----------->| (지원 TLS 버전, 암호화 방식 목록, 난수 전송)
| |
|<------- 2. Server Hello ------------| (선택한 암호화 방식, 난수 전송)
|<------- 3. Certificate -------------| (서버 인증서 전송)
|<------- 4. Server Hello Done -------|
| |
|-- 5. Pre-Master Secret (암호화) --->| (공개키로 암호화하여 전송)
| |
| [양쪽에서 Master Secret → 세션키 생성]
| |
|-------- 6. Change Cipher Spec ----->| (이제부터 암호화 통신 시작)
|-------- 7. Finished (암호화) ------>|
|<------- 8. Change Cipher Spec ------|
|<------- 9. Finished (암호화) -------|
| |
|====== 암호화된 데이터 통신 시작 ====|단계별 설명
- Client Hello: 클라이언트가 지원하는 TLS 버전, 암호화 알고리즘 목록(Cipher Suite), 난수(Random)를 서버에 전송한다.
- Server Hello: 서버가 사용할 TLS 버전과 암호화 알고리즘을 선택하고 서버 난수를 전송한다.
- Certificate: 서버가 CA로부터 발급받은 인증서를 전송한다. 클라이언트는 이 인증서로 서버의 신원을 검증한다.
- Pre-Master Secret 교환: 클라이언트가 인증서의 공개키로 Pre-Master Secret을 암호화하여 전송한다. 서버는 개인키로 복호화한다. 양쪽 모두 이를 바탕으로 동일한 세션키(대칭키)를 생성한다.
- Finished: 이후 모든 통신은 세션키로 암호화된다.
TLS 1.3 Handshake (1-RTT)
TLS 1.3에서는 불필요한 단계를 제거하여 1-RTT로 단축되었다.
Client Server
| |
|--- Client Hello + Key Share ------->| (키 교환 정보 함께 전송)
| |
|<-- Server Hello + Key Share --------|
|<-- Certificate ----------------------|
|<-- Finished (암호화) ---------------|
| |
|--- Finished (암호화) -------------->|
| |
|====== 암호화된 데이터 통신 시작 ====|- Client Hello와 함께 키 교환 정보를 미리 보내기 때문에 왕복 횟수가 줄어든다.
- 취약한 암호화 알고리즘들이 제거되어 보안성도 향상되었다.
- 이전에 연결했던 서버라면 0-RTT로 더욱 빠른 연결도 가능하다.
7. 인증서와 CA
CA(Certificate Authority)란?
CA는 인증 기관(Certificate Authority)의 약자로, 서버의 신원을 검증하고 인증서를 발급해주는 공인된 제3자 기관이다.
대표적인 CA로는 DigiCert, Let's Encrypt, GlobalSign 등이 있다.
인증서 발급 과정
1. 서버 운영자가 CA에게 인증서 발급 요청 (도메인 소유권 증명 포함)
2. CA가 도메인 소유권 및 신원을 검증
3. CA가 자신의 개인키로 서버 인증서에 서명하여 발급
4. 서버 운영자가 인증서를 서버에 설치인증서 체인 (Certificate Chain)
CA는 단일 기관이 아닌 계층 구조로 이루어져 있다.
Root CA (최상위 CA)
└── 중간 CA (Intermediate CA)
└── 서버 인증서 (End-Entity Certificate)- Root CA: 최상위 인증 기관으로 브라우저/OS에 미리 내장되어 있다.
- 중간 CA: Root CA가 직접 서버 인증서를 발급하지 않고 중간 CA를 통해 발급한다. Root CA의 개인키 노출 위험을 줄이기 위함이다.
- 서버 인증서: 실제 도메인에 대한 인증서로 서버에 설치된다.
브라우저의 인증서 검증 과정
1. 서버에서 인증서를 수신
2. 인증서의 서명을 상위 CA의 공개키로 검증
3. 상위 CA의 인증서도 동일하게 검증 (체인 따라 올라감)
4. 최종적으로 브라우저에 내장된 Root CA까지 검증 완료
5. 인증서의 유효기간, 도메인 일치 여부 확인
6. 검증 성공 → 브라우저 주소창에 자물쇠 아이콘 표시자체 서명 인증서 (Self-Signed Certificate)
CA의 서명 없이 서버 운영자가 직접 서명한 인증서이다.
- 개발 환경이나 사내 내부망에서 주로 사용한다.
- 브라우저가 신뢰할 수 있는 CA의 서명이 없으므로 "안전하지 않은 연결" 경고가 표시된다.
- 공개 서비스에는 공인 CA로부터 발급받은 인증서를 사용해야 한다.
마무리
HTTP의 보안 취약점(기밀성, 무결성, 인증 없음)을 해결하기 위해 TLS가 등장했고, 이를 적용한 것이 HTTPS이다.
TLS는 공개키 암호화로 세션키를 안전하게 교환하고, 이후 빠른 대칭키 암호화로 실제 데이터를 전송한다.
CA와 인증서 체인을 통해 서버의 신원도 보증된다.
현재 대부분의 웹 서비스가 HTTPS를 기본으로 사용하고 있으며, HTTP/2와 HTTP/3는 HTTPS를 전제로 동작한다.
브라우저 주소창의 자물쇠 아이콘 하나 뒤에 이런 복잡한 과정이 숨어 있다.
