웹 보안 지식(3) - HTTPS와 SSL/TLS의 동작 원리

안녕하세요. 벌써 금요일이네요.어제 비가 와서 그런지 오늘은 바람이 많이 부네요. 소리만 들으면 태풍 오는 것 같아요ㅋㅋ

저번 시간에는 해시 알고리즘과 함께 bcrypt와 scrypt에 대해 학습했습니다. 이번에는 웹 보안 지식에서 자주 언급되는 HTTPS와 SSL/TLS에 대해서 자세히 알아보도록 합시다.

---

HTTP와 HTTP의 차이

HTTP는 브라우저와 서버가 데이터를 주고받기 위한 프로토콜입니다.

사용자가 웹 페이지를 요청하면 브라우저는 서버에 HTTP 요청을 보내고, 서버는 HTML, JSON, 이미지 같은 응답 데이터를 반환합니다. 하지만 HTTP는 기본적으로 데이터를 암호화하지 않습니다. 

 

즉, 요청과 응답 내용이 평문으로 전달될 수 있습니다.

 

HTTPS는 HTTP에 보안 계층을 추가한 방식입니다. HTTP 요청과 응답을 그대로 주고받는 것이 아니라, TLS를 통해 통신 내용을 암호화한 뒤 데이터를 주고받습니다.

구분	HTTP	HTTPS
기본 포트	80	443
데이터 전송	평문 전송	암호화 전송
보안 계층	없음	TLS사용
주소 표시	http://	https://
주요 목적	데이터 요청/응답	안전한 데이터 요청/응답

즉, HTTPS는 HTTP의 요청/응답 구조를 유지하면서 통신 과정에 암호화와 인증 과정을 추가한 방식이라고 볼 수 있습니다.

 

HTTP만 사용할 때 발생할 수 있는 문제

HTTP만 사용할 경우 요청과 응답 데이터가 평문으로 오갈 수 있기 때문에 네트워크 중간에서 데이터를 들여다보거나 변조하는 공격에 취약할 수 있습니다.

 

1. 도청

도청은 제 3자가 브라우저와 서버 사이의 통신 내용을 몰래 확인하는 상황입니다. 로그인 요청, 개인정보, 결제 정보 등이 평문으로 전달된다면 중간에서 민감한 정보가  노출될 수 있습니다.

 

2. 변조

변조는 통신 중간에서 요청이나 응답 내용을 바꾸는 상황입니다. 예를 들어 사용자가 받은 응답 페이지나 API 응답이 중간에서 변경되면 사용자는 서버가 의도하지 않은 데이터를 받게 될 수 있습니다.

 

3. 위장

위장은 사용자가 접속한 서버가 실제 서버인지 확신할 수 없는 문제입니다. 공격자가 가짜 서버를 준비하고 사용자를 유도하면 사용자는 정상 서비스라고 생각하고 민감한 정보를 입력할 수 있습니다.

 

따라서 웹 서비스에서는 단순히 데이터를 주고받는 것 뿐만 아니라 통신 상대가 신뢰할 수 있는지, 데이터가 중간에 노출되거나 변경되지 않았는지 확인하는 과정이 필요합니다.

 

HTTPS

HTTPS(HyperText Transfer Protocol Secure)는 HTTP 통신을 TLS를 통해 암호화한 프로토콜입니다. 즉, HTTP 통신을 안전하게 보호하기 위해 TLS와 함께 사용하는 방식입니다.

 

브라우저와 서버가 HTTPS로 통신할 때는 먼저 TLS 연결을 설정합니다. 이후 HTTP 요청과 응답은 이 TLS 연결 위에서 암호화된 상태로 전달됩니다.

 

그렇다면 TLS는 무엇일까요?

SSL과 TLS의 관계

SSL(Secure Sockets Layer)은 과거에 사용되던 암호화 프로토콜입니다.

TLS(Transport Layer Security)는 SSL을 계승한 더 안전한 표준 프로토콜로 데이터를 암호화하고, 변조를 확인하고, 상대가 진짜 서버인지 검증하는 보안 계층입니다.

 

현재 HTTPS에서 실제로 사용되는 것은 SSL이 아니라 TLS입니다. 하지만 과거 표현이 남아 있어 SSL 인증서, SSL 설정, SSL 적용이라는 말을 여전히 많이 사용합니다.

구분	SSL	TLS
의미	Secure Sockets Layer	Transport Layer Security
관계	과거 보안 프로토콜	SSL을 계승하 현재 표준
현재 사용 여부	보안상 사용 권장 X	HTTPS에서 사용
흔한 표현	SSL 인증서	실제로는 TLS 인증서에 가까움

따라서 정확히 말하면 HTTPS는 HTTP over SSL이 아닌 HTTP over TTLS라고 볼 수 있습니다.

 

HTTPS가 제공하는 보안 요소

HTTPS는 크게 기밀성, 무결성, 인증이라는 보안 요소를 제공합니다.

보안 요소	의미	예시
기밀성	제 3자가 내용을 볼 수 없도록 보호	로그인 정보 암호화
무결성	데이터가 중간에 변경되지 않았는지 확인	응답 데이터 변조 방지
인증	접속한 서버가 신뢰할 수 있는 서버인지 확인	인증서 검증

 

대칭키와 비대칭키 암호화

대칭키

대칭키 암호화는 암호화와 복호화 같은 키를 사용하는 방식입니다.

암호화 키 = 복호화 키

대칭키 암호화는 속도가 빠르다는 장점이 있습니다. 하지만 브라우저와 서버가 같은 키를 안전하게 공유해야 한다는 문제가 있습니다.

 

비대칭키

비대칭키 암호화는 공개키와 개인키 한 쌍을 사용하는 방식입니다. 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있습니다.

공개키 : 외부에 공개 가능

개인키(비밀키) : 서버가 안전하게 보관

비대칭키 암호화는 키 교환 문제를 해결하는데 유용하지만, 대팅키 암호화보다 연산 비용이 큽니다.

 

대칭키 + 비대칭키 = TLS

TLS는 대칭키와 비대칭키 방식을 함께 사용합니다. 처음 연결을 설정할 때는 비대칭키 방식을 활용해 안전하게 키를 교환하고, 이후 실제 데이터 통신은 속도가 빠른 대칭키 방식으로 암호화 합니다.

 

즉, 비대칭키는 안전한 키 교환을 위해 사용하고, 대칭키는 실제 데이터 전송을 빠르게 처리하기 위해 사용됩니다.

 

그렇다면 서버는 어떻게 믿을 수 있을까요?

인증서와 CA

HTTPS에서 브라우저는 서버가 제공한 인증서를 확인합니다. 인증서는 이 서버가 특정 도메인의 소유자임을 증명하기 위한 전자 문서입니다.

 

인증서에는 도메인 정보, 공개키, 인증서 발급자, 유효 기간, 서명 정보 등이 포함됩니다.

 

CA(Certificate Authority)는 인증서를 발급하고 신뢰성을 보증하는 기관입니다. 브라우저는 신뢰할 수 있는 CA 목록을 가지고 있고, 서버가 보낸 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 확인합니다.

 

 

즉, 인증서는 단순히 암호화를 위한 도구가 아닌 사용자가 접속한 서버가 신뢰할 수 있는 대상인지 확인하는 기준이 됩니다.

 

TLS Handshake 

TLS Handshake는 브라우저와 서버가 안전하게 통신하기 위해 통신 방식과 암호화 키를 합의하는 과정입니다.

동작 과정

1. TCP 연결 수립

TCP Handshake가 시작되기 전에 먼저 브라우저와 서버 사이에 TCP 연결이 만들어져야합니다. 그 과정에서 TCP 3-way handshake 과정이 발생합니다.

 

TCP 3-way handshake

1. Client → Server : SYN
2. Server → Client : SYN + ACK
3. Client → Server : ACK

TCP 연결이 수립되면 그 위에서 TLS Handshake가 진행됩니다.

 

2. ClientHello

TCP 연결이 수립되면 클라이언트는 서버에게 ClientHello 메시지를 보냅니다.

Client → Server : ClientHello

ClientHello에는 클라이언트가 지원하는 TLS 관련 정보가 포함되어있으며 다음과 같은 정보가 전달됩니다.

• 클라이언트가 지원하는 TLS 버전
• 사용 가능한 암호화 방식 목록
• 랜덤 값
• 세션 재사용 관련 정보

 

3. ServerHello, Certificate, ServerHelloDone

서버는 클라이언트의 요청을 받고, 사용할 TLS 버전과 암호화 방식을 선택해 응답합니다.

Server → Client : ServerHello

ServerHello에는 서버가 선택한 TLS 버전, 암호화 방식, 서버 랜덤 값 등이 포함됩니다.

 

이후 서버는 자신의 인증서를 클라이언트에게 전달합니다.

Server →Client : Ceertificate

인증서는 클라이언트가 접속한 서버가 신뢰할 수 있는 서버인지 확인하기 위해 사용됩니다.

브라우저는 이 인증서를 보고 다음과 같은 내용을 검증합니다.

• 인증서가 신뢰할 수 있는 CA에서 발급되었는가?
• 인증서의 유효 기간이 지나지 않았는가?
• 접속한 도메인과 인증서의 도메인이 일치하는가?
• 인증서가 위조되거나 변조되지 않았는가?

검증이 끝나면 서버는 ServerHelloDone 메시지를 통해 서버 측 초기 응답이 끝났음을 알립니다.

Sercer → Client : ServerHelloDone

 

즉, 클라이언트가 사용할 수 있는 암호화 방식을 제안하고, 서버는 그 중 하나를 선택한 뒤, 자신의 인증서를 전달해 신뢰성을 증명하는 흐름입니다.

 

4. ClientKeyExchange

서버 인증서 검증이 완료되면 클라이언트는 이후 통신에 사용할 키를 만들기 위한 정보를 서버에 전달합니다.

Client → Server : ClientKeyExchange

이 단계는 TLS Handshake 과정에서 매우 중요한 부분입니다.

브라우저와 서버는 이 과정에서 이후 실제 데이터 암호화에 사용할 세션 키를 만들 준비를 합니다.

 

여기서 중요한 점은 실제 HTTP 데이터를 계속 비대칭키로 암호화하지 않는 것입니다.

 

비대칭키 암호화는 안전하지만 연산 비용이 크기에 실제 데이터 통신 전체에 사용하기에는 부담이 큽니다. 그래서 TLS는 초기에만 비대칭키 방식을 활용하여 안전하게 키 정보를 교환하고, 이후 실제 통신은 더 빠른 대칭키 암호화 방식을 사용합니다.

 

비대칭키 암호화 → 세션 키를 안전하게 만들기 위해 사용

대칭키 암호화 → 실제 HTTP 요청/응답 데이터를 빠르게 암호화하기 위해 사용

 

5. ChangeCipherSpec

이후 클라이언트는 ChangeCipherSpec 메시지를 보냅니다.

Client → Server : ChangeCipherSpec

이 메시지는 앞으로의 통신에서 지금까지 합의한 암호화 방식을 사용하겠다는 의미입니다.

 

서버도 마찬가지로 ChangeCipherSpec 메시지를 보냅니다.

Server → Client : ChangeCipherSpec

이를 통해 양쪽 모두 암호화 통신을 시작할 준비가 끝났음을 알립니다.

 

6. Finished

Finished 메시지는 TLS Handshake가 정상적으로 완료되었는지 확인하는 단계입니다

Client → Server : Finished

Server → Client : Finished

클라이언트와 서버는 지금까지 주고받은 Handshake 메시지가 중간에서 변조되지 않았는지 확인합니다.

 

이 단계까지 성공하면 TLS Handshake 과정이 완료됩니다.

 

7. Application Data 전송

TLS Handshake가 끝나면 이제 실제 HTTP 요청과 응답이 암호화 되어 전달됩니다.

Client ↔ Server : Application Data

여기서 Application Data는 실제 웹 서비스에서 주고받는 데이터입니다.

예를 들면 

• 로그인 요청
• 회원가입 요청
• 게시글 조회 요청
• JSON 응답 데이터
• HTML, CSS, JavaScript 파일

이 데이터들은 TLS  Handshake 과정에서 만들어진 세션 키를 사용해 암호화됩니다.

 

즉, HTTPS 통신에서 실제 HTTP 요청과 응답은 TLS 연결 위에서 암호화된 상태로 오가게 됩니다.

 

TLS Handshake의 목적은 브라우저와 서버가 서로 신뢰할 수 있는지 확인하고, 이후 통신에 사용할 안전한 세션 키를 만드는 것 입니다.

---

오늘은 HTTPS와 SSL/TLS에 대해 학습해보았습니다.

현재 HTTPS에서 실제로 사용되는 표준은 SSL이 아니라 TLS입니다. 다만 SSL 인증서, SSL 설정이라는 표현이 여전히 관습적으로 사용되기 때문에 이번 글에서는 SSL/TLS라고 함께 표현했습니다. 따라서 이번 글에서 자세히 다룬 TLS의 동작 과정이 SSL/TLS의 핵심이라고 볼 수 있습니다. 다음 시간에는 CORS에 대해 알아보도록 하겠습니다. 수고하셨습니다.

 

+ HTTPS 설정과 SSL/TLS 설정에 관해서 도움이 될 것 같아 추가합니다.

IP 접속에서 도메인 접속으로(2) - HTTPS 설정하기