Back to Blog
SSLTLSHTTPSTCP/IP핸드셰이크

0x06. SSL/TLS - 인터넷 보안 프로토콜

웹 브라우저와 서버 간 안전한 통신을 책임지는 SSL/TLS 프로토콜의 동작 원리를 알아본다

인터넷 보안의 필요성

웹은 기업, 정부, 개인 모두가 사용하는 필수 인프라가 되었다. 하지만 인터넷과 웹은 본질적으로 취약한 환경이다.

대표적인 위협 요소는 다음과 같다:

  • 무결성(Integrity): 데이터가 전송 중 변조될 수 있다
  • 기밀성(Confidentiality): 제3자가 데이터를 도청할 수 있다
  • 서비스 거부(DoS): 서비스를 마비시킬 수 있다
  • 인증(Authentication): 상대방이 진짜인지 확인할 수 없다

이러한 위협에 대응하기 위해 추가적인 보안 메커니즘이 필요하다.


TCP/IP 프로토콜 스택

TCP/IP(Transmission Control Protocol/Internet Protocol) 는 인터넷 통신의 표준 규약이다. 총 5개의 계층으로 구성되어 있다.

물리 계층을 제외한 모든 계층은 같은 컴퓨터의 인접 계층과 통신한다. 실제로 두 컴퓨터 간 전송이 이루어지는 곳은 물리 계층뿐이다.

TCP/IP 5계층 구조

TCP/IP 통신 과정

TCP/IP 통신 흐름

계층별 데이터 교환

TCP/IP 계층별 데이터 교환

웹 트래픽 보안 방식

보안을 어느 계층에서 적용할 것인지에 따라 여러 접근 방식이 존재한다.

웹 트래픽 보안 접근 방식

SSL 기초

SSL(Secure Socket Layer)이란?

SSL은 전송 계층(Transport Layer)에서 보안 서비스를 제공하는 프로토콜이다.

  • Netscape에서 최초 개발
  • Version 3은 공개적인 검토를 거쳐 설계됨
  • 이후 TLS(Transport Layer Security) 로 표준화됨 (IETF에서 SSL을 표준화한 것이 TLS)

SSL은 두 개의 프로토콜 계층으로 구성된다:

SSL 프로토콜 계층 구조

송신 측의 SSL 계층은 애플리케이션 계층에서 받은 데이터를 암호화하고 자체 헤더(SH)를 추가한다. 수신 측의 SSL 계층은 SH를 제거하고 데이터를 복호화하여 애플리케이션 계층에 전달한다.

SSL 암호화/복호화 흐름

SSL의 주요 특징

  • 대부분의 웹사이트에서 보안 연결과 금융 거래에 사용된다
  • 정보를 암호화할 뿐만 아니라, 연결된 사이트가 실제로 해당 사이트인지 인증한다
  • 대칭키 암호화, 비대칭키 암호화, 디지털 서명을 모두 활용한다

SSL 동작 원리

금융 거래를 위해 웹사이트에 접속한다고 가정하면:

  1. 웹사이트가 인증서(Certificate) 를 보낸다. 인증서에는 해당 조직의 정보와 공개키가 포함되어 있다.
  2. 브라우저는 신뢰 체인(Chain of Trust) 을 따라 신뢰할 수 있는 인증 기관을 찾고, 해당 인증서의 정확성을 검증한다.
  3. 이제 접속한 사이트가 진짜임을 확인했다.
  4. 비대칭키 암호화를 사용해 안전하게 통신할 수 있지만, 속도가 느리다.
  5. 그래서 공유 비밀키(Shared Secret Key) 를 전송한다.
  6. 양쪽 모두 공유 비밀키를 갖게 되면, 이후 통신은 대칭키 암호화로 수행한다. 대칭키 암호화가 비대칭키보다 훨씬 빠르기 때문이다.

SSL Session과 Connection

SSL Connection:

  • 일시적인 P2P 통신 링크
  • 하나의 SSL Session에 연결됨

SSL Session:

  • 클라이언트와 서버 간의 연결
  • Handshake Protocol에 의해 생성됨
  • 암호화 파라미터 집합을 정의
  • 여러 SSL Connection이 공유할 수 있음

세션에서는 한쪽이 클라이언트, 다른 쪽이 서버 역할을 한다. 커넥션에서는 양쪽이 동등한 피어(Peer) 관계다.

SSL Session과 Connection 관계

네 가지 SSL 프로토콜

SSL 프로토콜 구성

SSL Handshake Protocol

SSL에서 가장 복잡한 부분이다. 다음 역할을 수행한다:

  • 서버와 클라이언트가 상호 인증
  • 암호화 알고리즘, MAC 알고리즘 협상
  • 사용할 암호화 키 결정
  • 애플리케이션 데이터 전송 이전에 수행됨
SSL Handshake 개요 SSL Handshake 전체 흐름

Handshake 프로토콜의 동작:

Handshake 프로토콜 동작 1 Handshake 프로토콜 동작 2

Phase 1: 보안 능력 설정

Phase 1 구조

Client_hello 메시지:

  • Version: 클라이언트가 지원하는 최고 SSL 버전
  • Random: 32비트 타임스탬프 + 28바이트 난수
  • SessionID: 0이면 새 세션, 0이 아니면 기존 세션 파라미터 업데이트
  • Cipher suite: 선호도 순서로 나열된 암호화 알고리즘 목록
  • Compression methods: 압축 방법 목록

Server_hello 메시지:

  • 클라이언트 메시지에 대한 확인 응답
  • 양쪽이 지원하는 최고 버전, 새 난수, 선택된 cipher suite와 압축 방식을 포함

키 교환 방식:

  • RSA: 비밀키를 수신자의 RSA 공개키로 암호화
  • Fixed Diffie-Hellman
  • Ephemeral Diffie-Hellman
  • Anonymous Diffie-Hellman
  • Fortezza

CipherSpec 구성 요소:

  • Cipher algorithm (암호화 알고리즘)
  • MAC algorithm
  • CipherType: block 또는 stream
  • Hash size: 0, 16(MD5), 20(SHA-1) 바이트
  • Key material: 키 생성에 사용되는 바이트 시퀀스
  • IV size: CBC 모드를 위한 초기값 크기

암호화/복호화 알고리즘:

암호화 알고리즘 목록

메시지 무결성을 위한 해시 알고리즘:

해시 알고리즘 1 해시 알고리즘 2

Phase 1 완료 후 양측이 아는 정보:

  • SSL 버전
  • 키 교환, 메시지 인증, 암호화 알고리즘
  • 압축 방식
  • 키 생성을 위한 두 개의 난수

Phase 2: 서버 인증 및 키 교환

Phase 2 구조

서버가 전송하는 메시지:

  1. Certificate: X.509 인증서 체인
    • Anonymous Diffie-Hellman에서는 불필요
  2. Server_key_exchange: pre-master secret에 대한 서버의 기여분
    • RSA나 Fixed DH에서는 불필요
  3. Certificate_request: 인증서 타입과 인증 기관 정보
  4. Server_hello_done: 서버 응답 완료, 클라이언트 응답 대기

Phase 2의 네 가지 경우:

Phase 2 네 가지 케이스

Phase 3: 클라이언트 인증 및 키 교환

Phase 3 구조

클라이언트는 서버의 인증서가 유효한지 검증하고, server hello 파라미터가 수용 가능한지 확인한다.

클라이언트가 전송하는 메시지:

  1. Certificate (선택): 서버가 요청하면 클라이언트 인증서 전송. 없으면 "no certificate" 메시지 전송
  2. Client_key_exchange: 48바이트 pre-master secret을 생성하고 서버의 공개키로 암호화하여 전송
  3. Certificate_verify: 클라이언트 인증서의 명시적 검증. "올바른 개인키를 가지고 있다"는 증명

Phase 3의 네 가지 경우:

Phase 3 네 가지 케이스

Phase 3 완료 후:

  • 클라이언트가 서버에게 인증됨
  • 양측 모두 pre-master secret을 알게 됨

Phase 4: 완료

Phase 4 구조

이 단계부터 암호화가 시작된다. 이전까지는 평문(Plaintext)으로 통신했다.

클라이언트 전송:

  1. Change_cipher_spec 메시지
  2. Finished 메시지 (새로운 알고리즘과 키 적용)

서버 응답:

  1. Change_cipher_spec 메시지
  2. Finished 메시지 (새로운 알고리즘과 키 적용)

Phase 4 완료 후, 클라이언트와 서버는 데이터 교환 준비 완료 상태가 된다.

암호화 연산

Master Secret 생성:

  • 일회성 48바이트 값
  • 안전한 키 교환(RSA/Diffie-Hellman)과 해싱을 통해 생성

암호화 파라미터 생성:

  • client write MAC secret
  • server write MAC secret
  • client write key
  • server write key
  • client write IV
  • server write IV
  • master secret을 해싱하여 생성

클라이언트가 48바이트 pre-master-secret(sp)을 생성한다.

Master secret 계산:

Master secret 생성 공식

세션 키는 동일한 방식으로 생성되지만, pre-master-secret 대신 master secret을 사용한다.

세션 키 생성

pre-master secret에서 master secret 계산:

Master secret 계산 과정

master secret에서 key material 계산:

Key material 계산 1 Key material 계산 2

SSL Record Protocol

제공하는 서비스

기밀성(Confidentiality):

  • Handshake Protocol에서 정의된 공유 비밀키를 사용한 대칭 암호화
  • 지원 알고리즘: AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128
  • 암호화 전 메시지 압축

메시지 무결성(Message Integrity):

  • 공유 비밀키를 사용한 MAC
  • HMAC과 유사하지만 다른 패딩 방식 사용

Record Protocol 동작

SSL Record Protocol 동작

1. Fragmentation (단편화):

  • 애플리케이션 메시지를 블록으로 분할
  • 블록 크기 ≤ 2^14 바이트 (16,384 바이트)

2. Compression (압축):

  • 선택적 단계
  • 무손실 압축이어야 함

3. MAC 추가:

  • 공유 키를 사용하여 각 블록의 MAC 계산
  • hash(MAC_write_secret, pads, seq_num, etc)
  • HMAC과 유사하지만, 두 패드가 XOR 대신 연결(concatenate)

4. Encryption (암호화):

  • 대칭 암호화 적용
  • 압축 단계와 합쳐서 크기 증가는 최대 1024바이트
  • 블록 암호화의 경우 암호화 전 MAC 뒤에 패딩 추가 가능
  • 패딩의 총량은 암호화할 데이터의 총 크기가 암호 블록 길이의 배수가 되는 최소량

5. Header 추가:

  • Content type: handshake, alert, change cipher
  • Major version: 버전이 3.1이면 3
  • Minor version: 버전이 3.1이면 1
  • Compression length
SSL Record 포맷

SSL Change Cipher Spec Protocol과 Alert Protocol

Change Cipher Spec Protocol

SSL Record Protocol을 사용하는 3개의 SSL 전용 프로토콜 중 하나다.

  • 단일 메시지로 구성
  • pending 상태를 current 상태로 전환
  • 사용 중인 cipher suite를 업데이트
Change Cipher Spec 메시지

Handshake Protocol 동안 cipher 상태 협상과 암호화 비밀 생성이 점진적으로 이루어진다. 그렇다면 양측은 언제 이 파라미터와 비밀을 사용할 수 있는가?

SSL은 양측이 ChangeCipherSpec 메시지를 송신하거나 수신하기 전까지는 이 파라미터나 비밀을 사용할 수 없다고 명시한다. 이 메시지는 Handshake Protocol 중에 교환되며 ChangeCipherSpec Protocol에서 정의된다.

파라미터가 pending 상태에서 active 상태로 이동:

상태 전환 과정

Alert Protocol

SSL 관련 경고를 상대 엔티티에 전달한다.

심각도(Severity):

  • warning (경고)
  • fatal (치명적)

구체적인 경고 유형:

심각도경고 유형
fatalunexpected message, bad record mac, decompression failure, handshake failure, illegal parameter
warningclose notify, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown

모든 SSL 데이터처럼 압축 및 암호화된다.

Alert Protocol 구조 1 Alert Protocol 구조 2

HGU 전산전자공학부 고윤민 교수님의 24-2 컴퓨터 보안 수업을 듣고 작성한 포스트이며, 첨부한 모든 사진은 교수님 수업 PPT의 사진 원본에 필기를 한 수정본입니다.