SSL과 TLS는 어떤 역할을 할까?

앞에서 HTTPS가 HTTP보다 안전한 이유를 살펴봤다.

HTTPS는 단순히 HTTP 자체가 더 안전하게 만들어진 프로토콜이 아니라, HTTP 통신에 TLS라는 보안 계층을 적용한 것이라고 정리할 수 있다.

그렇다면 여기서 하나 궁금해진다.

HTTPS에서 이야기하는 SSL과 TLS는 도대체 무슨 역할을 하는 걸까?

인터넷을 조금만 공부해도 SSL 인증서, SSL 보안, TLS 1.2, TLS 1.3 같은 용어가 계속 등장한다. 그런데 현재는 TLS를 사용하는데도 사람들이 여전히 “SSL 인증서”라는 표현을 많이 사용한다.

이번 글에서는 SSL과 TLS가 무엇인지, 둘은 어떤 관계인지, 그리고 HTTPS 연결 과정에서 실제로 어떤 일을 하는지 정리해보려고 한다.

SSL과 TLS는 같은 것일까?

먼저 가장 헷갈리는 부분부터 정리하자.

SSL과 TLS는 서로 완전히 다른 목적의 기술이 아니다.

TLS는 SSL의 후속 버전이라고 생각하면 이해하기 쉽다.

초기의 웹 보안을 위해 SSL(Secure Sockets Layer)이 사용되었지만 여러 보안 문제가 발견되면서 새로운 프로토콜이 개발되었고, 이것이 TLS(Transport Layer Security)다.

간단하게 흐름을 보면 다음과 같다.

SSL 1.0
   ↓
SSL 2.0
   ↓
SSL 3.0
   ↓
TLS 1.0
   ↓
TLS 1.1
   ↓
TLS 1.2
   ↓
TLS 1.3

실제로 SSL 2.0과 SSL 3.0은 더 이상 안전한 프로토콜로 사용하지 않는다.

현재 웹에서 주로 사용되는 것은 TLS 1.2와 TLS 1.3이다.

따라서 오늘날 HTTPS의 보안 기술을 정확하게 표현하면 SSL보다는 TLS라고 하는 것이 맞다.

그런데 왜 아직도 “SSL 인증서”라는 말을 사용할까?

인증서 자체는 TLS에서도 사용되기 때문에, 과거부터 사용해오던 표현이 관습적으로 남아 있는 경우가 많다.

그래서

SSL 인증서

라는 말을 보더라도 실제 HTTPS 연결에서는 TLS가 사용될 수 있다고 이해하면 된다.

TLS는 무엇을 보호할까?

TLS의 가장 중요한 역할은 네트워크를 통해 주고받는 데이터를 안전하게 보호하는 것이다.

앞에서 HTTP는 데이터가 암호화되지 않은 상태로 전송될 수 있기 때문에 문제가 있다고 설명했다.

TLS를 적용하면 구조가 달라진다.

HTTP

브라우저 ─── HTTP 데이터 ───→ 서버


HTTPS

브라우저 ── TLS로 보호된 데이터 ──→ 서버

TLS는 크게 다음과 같은 보안 기능을 제공한다.

• 통신 내용의 기밀성 보호
• 전송 데이터의 무결성 보호
• 서버 인증
• 통신에 사용할 암호화 키 설정

결국 TLS는 브라우저와 서버 사이에 신뢰할 수 있는 보안 통신 통로를 만드는 역할을 한다고 볼 수 있다.

TLS 연결은 어떻게 만들어질까?

TLS를 이해하려면 HTTPS 접속 과정에서 TLS가 어디에 들어가는지를 보는 것이 좋다.

사용자가 다음 주소에 접속한다고 생각해보자.

https://example.com

TCP 기반 HTTPS라면 대략 다음 순서로 진행된다.

1. DNS 조회
      ↓
2. TCP 연결
      ↓
3. TLS 연결 설정
      ↓
4. HTTP 요청/응답

여기서 TLS는 TCP 연결이 만들어진 뒤 HTTP 데이터를 본격적으로 주고받기 전에 보안 연결을 설정한다.

즉,

TCP
 ↓
TLS
 ↓
HTTP

라는 계층적인 구조로 생각할 수 있다.

다만 HTTP/3는 QUIC을 사용하기 때문에 전통적인 TCP → TLS 구조와는 조금 다르다. 그래도 TLS가 제공하는 암호화와 인증이라는 핵심 역할 자체는 그대로 중요하다.

TLS Handshake란 무엇일까?

TLS 연결을 처음 만들 때 브라우저와 서버가 여러 정보를 주고받는다.

이 과정을 TLS Handshake라고 한다.

앞에서 TCP의 3-Way Handshake를 공부했다면 이름이 비슷해서 헷갈릴 수 있다.

하지만 둘은 목적이 다르다.

TCP 3-Way Handshake
→ TCP 연결을 만들기 위한 과정

TLS Handshake
→ 안전한 통신을 설정하기 위한 과정

TLS Handshake에서는 브라우저와 서버가 사용할 TLS 버전, 암호화 방식 등을 협상하고 서버의 인증서를 확인하며 이후 데이터를 보호할 키를 설정한다.

개념적으로 단순화하면 다음과 같다.

브라우저                         서버
   │                              │
   │ ── TLS 연결 시작 ──────────→ │
   │                              │
   │ ←─ TLS 설정 정보/인증서 ──── │
   │                              │
   │ ── 키 교환 관련 메시지 ────→ │
   │                              │
   │ ←─ 보안 연결 설정 완료 ───── │
   │                              │
   │ ===== 암호화된 HTTP =======  │

실제 TLS 1.3의 메시지 흐름은 이보다 더 구체적이고 복잡하지만, 처음 공부할 때는 Handshake를 통해 보안 연결에 필요한 설정을 완료한다고 이해하면 충분하다.

서버 인증서는 왜 필요한가?

TLS에서 중요한 역할을 하는 것이 바로 디지털 인증서다.

예를 들어 사용자가

https://example.com

에 접속했다고 하자.

브라우저가 서버에 연결했는데 서버가 그냥

“나는 example.com 서버입니다.”

라고 말한다고 해서 그것을 믿을 수는 없다.

그래서 서버는 자신의 신원을 증명하기 위한 인증서를 제시한다.

인증서에는 도메인 이름과 공개키 등의 정보가 포함되어 있고, 인증기관(CA)의 전자서명을 통해 신뢰 여부를 판단할 수 있도록 구성되어 있다.

브라우저는 인증서를 확인하면서 서버의 신원을 검증한다.

서버
 │
 │ 인증서 제공
 ▼
브라우저
 │
 ├─ 인증서 유효기간 확인
 ├─ 도메인 정보 확인
 ├─ 인증서 서명 검증
 └─ 신뢰할 수 있는 CA인지 확인

문제가 발견되면 브라우저에서 인증서 관련 경고가 나타날 수 있다.

공개키와 개인키는 여기서 어떤 역할을 할까?

TLS를 공부하다 보면 공개키와 개인키가 등장한다.

이 부분에서 흔히 생기는 오해가 있다.

“HTTPS에서는 공개키로 모든 데이터를 암호화해서 주고받는 것 아닌가?”

그렇지는 않다.

TLS에서는 공개키 암호 기술과 대칭키 암호 기술이 서로 다른 역할을 담당한다.

공개키와 개인키는 서버 인증이나 키 교환을 보호하는 데 중요한 역할을 하고, 실제 웹 데이터를 계속 주고받는 과정에서는 효율적인 대칭키 암호화가 사용된다.

개념적으로 보면

TLS Handshake
      │
      ├─ 서버 인증
      ├─ 키 교환
      └─ 보안 파라미터 설정
             ↓
       공유된 세션 키
             ↓
     대칭키 암호화 통신
             ↓
        HTTP 데이터

이런 구조다.

대칭키 방식은 암호화와 복호화에 같은 비밀키를 사용하기 때문에 많은 데이터를 처리할 때 효율적이다.

그래서 실제 웹 통신에서는 이런 방식이 적합하다.

TLS는 데이터가 변조되지 않았는지도 확인한다

TLS의 역할은 데이터를 숨기는 것에서 끝나지 않는다.

통신 중 데이터가 몰래 변경되는 것도 확인할 수 있어야 한다.

예를 들어 서버가 다음 데이터를 전송했다고 해보자.

amount=100000

중간에서 누군가 이것을

amount=900000

으로 바꿀 수 있다면 문제가 된다.

TLS는 암호학적 검증 기능을 이용해 통신 데이터가 변조되지 않았는지를 확인한다.

따라서 TLS의 보안 목적을 단순하게 정리하면 다음과 같다.

기밀성
→ 다른 사람이 통신 내용을 보기 어렵게 함

무결성
→ 통신 중 데이터가 변조되었는지 확인

인증
→ 연결한 서버가 누구인지 확인

이 세 가지가 TLS를 이해할 때 가장 중요한 부분이다.

TLS 1.2와 TLS 1.3의 차이는?

현재 웹에서 많이 접하게 되는 TLS 버전이 TLS 1.2와 TLS 1.3이다.

TLS 1.3은 TLS 1.2보다 보안 설정을 단순화하고 불필요하거나 오래된 암호화 옵션을 제거했으며, 연결 설정 과정에서 필요한 왕복 횟수를 줄였다.

쉽게 표현하면

TLS 1.2
보안 연결 설정
→ 비교적 많은 협상 과정

TLS 1.3
보안 연결 설정
→ 더 단순하고 빠른 Handshake

라고 볼 수 있다.

특히 네트워크 지연시간이 중요한 환경에서는 Handshake 과정에서 발생하는 왕복 횟수를 줄이는 것이 의미가 있다.

다만 TLS 1.3이라고 해서 웹사이트의 모든 문제가 자동으로 해결되는 것은 아니다.

TLS 버전뿐만 아니라 서버 설정, 인증서 구성, 암호화 알고리즘, 애플리케이션 자체의 보안 등도 함께 중요하다.

SSL 인증서라고 부르는 이유

실무나 인터넷에서 다음과 같은 표현을 자주 볼 수 있다.

SSL 인증서 구매
SSL 인증서 갱신
SSL 인증서 설치

그런데 실제로는 TLS가 사용되고 있다.

이것은 과거 SSL이라는 용어가 워낙 널리 사용되었기 때문이다.

그래서 현재의 웹 환경을 이해할 때는 다음처럼 구분하는 것이 가장 편하다.

SSL
→ 과거에 사용되던 보안 프로토콜

TLS
→ SSL의 후속 기술
→ 현재 HTTPS에서 사용하는 표준적인 보안 프로토콜

그리고

SSL 인증서

라는 표현은 여전히 많이 사용되지만, 엄밀하게는 TLS에서 사용하는 서버 인증서라고 생각하는 편이 정확하다.

HTTPS와 TLS의 관계를 다시 정리해보자

앞에서 HTTPS를 공부했다면 이 둘의 관계를 정확하게 연결해두는 것이 중요하다.

HTTPS 자체가 별도의 완전히 새로운 웹 데이터 형식인 것은 아니다.

기본적인 HTTP 통신에 TLS를 적용해서 데이터를 보호하는 방식이다.

HTTP
  │
  │ TLS 적용
  ▼
HTTPS

조금 더 네트워크 계층 관점에서 표현하면

웹 애플리케이션
       │
      HTTP
       │
      TLS
       │
      TCP
       │
      IP
       │
   Ethernet

같은 형태로 이해할 수 있다.

HTTP는 웹 요청과 응답을 정의하고, TLS는 그 통신을 보호한다.

TCP는 데이터를 안정적으로 전달하는 연결을 제공하고, IP는 목적지까지 패킷을 전달하는 역할을 한다.

각각 맡은 역할이 다르기 때문에 HTTPS를 이해하려면 앞에서 공부했던 HTTP와 TCP 개념도 자연스럽게 연결된다.

실제 웹사이트에 접속하면 어떻게 될까?

전체 과정을 하나로 합쳐보자.

사용자가 브라우저 주소창에

https://example.com

을 입력한다.

먼저 DNS를 통해 서버의 IP 주소를 확인한다.

그다음 TCP 기반 연결이라면 TCP 연결을 설정한다.

그리고 TLS Handshake를 진행한다.

DNS
 ↓
TCP 3-Way Handshake
 ↓
TLS Handshake
 ↓
인증서 검증
 ↓
암호화 통신 준비
 ↓
HTTP Request
 ↓
HTTP Response

여기서부터 HTTP 요청과 응답은 TLS를 통해 보호된다.

그래서 네트워크에서 패킷이 이동하더라도 중간에서 통신 내용을 그대로 읽거나 변조하기 어렵게 된다.

이렇게 보면 HTTPS는 단순히 “주소 앞에 S 하나 붙은 HTTP”가 아니라 여러 네트워크 기술이 연결되어 만들어진 결과라는 것을 알 수 있다.

마무리

SSL과 TLS를 처음 접하면 둘을 완전히 별개의 기술처럼 생각하기 쉽다.

하지만 관계를 정리하면 간단하다.

SSL은 과거에 사용되던 보안 프로토콜이고, TLS는 그 후속 기술이다.

현재 HTTPS 통신에서는 TLS가 사용되며, TLS는 브라우저와 서버 사이에서 안전한 통신 환경을 만드는 역할을 한다.

특히 중요한 기능은 다음 세 가지다.

기밀성
무결성
인증

그리고 TLS Handshake 과정에서 서버 인증서를 확인하고, 암호화에 필요한 키와 보안 설정을 협상한 뒤 실제 HTTP 데이터를 보호한다.

결국 웹 브라우저에서

HTTPS

라고 표시된다는 것은 단순히 HTTP를 사용한다는 의미가 아니라 HTTP 통신이 TLS로 보호되고 있다는 의미에 가깝다.

여기까지 이해했다면 다음에는 웹에서 사용자의 로그인 상태를 유지할 때 자주 등장하는 쿠키와 세션을 살펴보면 좋다. HTTPS가 통신 자체를 보호한다면 쿠키와 세션은 그 통신을 이용하는 웹 애플리케이션에서 사용자를 어떻게 구분하고 상태를 유지하는지 이해하는 데 필요한 개념이다.