HTTPS와 TLS - TLS 핸드세이크

SSL(Secure Socket Layer)

• 인터넷 상에서 데이터를 안전하게 전소하기 위해 넷스케이프(Netscape)에 의해 개발된 보안 프로토콜
• SSL은 클라이언트(예 : 웹브라우저)와 서버 간에 전송되는 데이터를 암호화하여 제3자가 데이터를 도청하거나 조작하지 못하도록 보호함

기능

• 암호화 : 데이터를 암호화하여 전송 도중의 도청을 방지
• 무결성 : 데이터의 무결성을 보장하여 전송 도중 데이터가 변조되지 않도록 함
• 인증 : 서버(선택적 클라이언트)를 인증하여 통신이 신뢰할 수 있는 대상과 이루어지고 있음을 보장

TLS(Transport Layer Security)

• SSL의 후속 프로토콜로 SSL의 문제점을 보완하고 보안을 더욱 강화한 표준 프로토콜
• TLS는 인터넷 엔지니어링 테스크 포스(IETF)에 의해 표준화되었으며 SSL과 유사한 보안 기능을 제공

기능

• 암호화 : 클라이언트와 서버 간의 모든 데이터를 암호화하여 보호
• 무결성 : 데이터의 변조를 방지하는 메시지 인증 코드를 사용하여 데이터 무결성을 보장
• 인증 : 서버 인증을 필수적으로 하고 클라이언트 인증을 선택저긍로 함

SSL과 TLS의 변천사

버전	출시 및 개발	특징	문제점
SSL 1.0	1994년, 넷스케이프에 의해 개발	실제로 배포되지 않음	보안 결함으로 인해 폐기됨
SSL 2.0	1995년 출시	SSL의 첫 상용 버전	몇 가지 심각한 보안 취약점 발견, 메시지 무결성 보장 안됨, 중간자 공격에 취약
SSL 3.0	1996년 출시	이전 버전의 보안 문제 해결, 개선된 암호화 메커니즘 제공	몇 가지 보안 문제(예: POODLE 공격) 존재
TLS 1.0	1999년 출시	SSL 3.0의 개선된 버전, IETF에서 표준화	메시지 인증 코드(MAC) 계산 방식 변경, 보안 강화
TLS 1.1	2006년 출시	TLS 1.0의 여러 문제 해결	초기화 벡터(IV) 재사용 문제 해결, CBC 모드에서의 보안 강화
TLS 1.2	2008년 출시	성능과 보안 모두 개선	새로운 해시 함수 사용(SHA-256), 인증, 키 교환, 암호화에 더 유연한 구조
TLS 1.3	2018년 출시	보안 강화 및 성능 최적화	핸드세이크 과정 단축: 더 빠른 연결 설정, 많은 취약한 기능 제거(RSA 키 교환 제거), 보다 강력한 암호화 알고리즘 사용, 0-RTT(Zero Round Trip Time) 모드 도입: 재연결 시 지연 시간 감소

TLS 핸드세이크 (TLS 1.3 기준)

1. Client Hello

• 클라이언트가 서버에 메시지 전송
  • 클라이언트는 핸드세이크를 시작하면서 Client Hello 메시지를 서버에 전송
  • 이 메시지에는 다음 정보가 포함됨
    • 지원하는 TLS 버전(TLS 1.3)
    • 지원하는 암호 스위트 목록
    • 클라이언트의 랜덤 값(nonce)
    • 세션 복원 및 O-RTT 데이터를 위한 옵션
    • 공개 키 교환을 위한 키 공유 값(임시 DH 매개변수)

2. Server Hello

• 서버가 클라이언트에 메시지 전송
  • 서버는 클라이언트의 Client Hello 메시지를 수신하고 이에 대한 응답으로 Server Hello 메시지를 클라이언트에 전송
  • 이 메시지에는 다음 정보가 포함됨
    • 선택한 TLS 버전 (TLS 1.3)
    • 선택한 암호 스위트
    • 서버의 랜덤 값(nonce)
    • 공개 키 교환을 위한 키 공유 값(임시 DH 매개변수)

3. Server’s Encrypted Extensions

• 서버가 추가 설정 정보 전송
  • 서버는 선택적으로 Encrypted Extensions 메시지를 전송하여 추가 확장 정보를 제공
  • 이 메시지는 이미 설정된 세션 키로 암호화되어 있음

4. Server Certificate (Optional)

• 서버 인증서 전송
  • 서버는 클라이언트에게 자신의 인증서를 전송
    • 이 인증서는 서버의 공개 키를 포함하고 있으며 클라이언트는 이를 통해 서버의 신원을 확인
  • 이 단계는 서버 인증서가 필요한 경우에만 수행

5. Certificate Verify (Optional)

• 서버가 인증서 검증 메시지 전송
  • 서버는 Certificate Verify 메시지를 전송하여 인증서의 유효성을 증명
    • 이 메시지에는 서버의 개인 키로 서명된 값이 포함
  • 클라이언트는 이 서명을 확인하여 서버 인증서의 진위를 검증

6. Server Finished

• 서버가 핸드세이크 완료 알림
  • 서버는 Finished 메시지를 전송하여 자신의 핸드세이크 단계가 완료되었음을 클라이언트에게 알림
  • 이 메시지는 세션 키로 암호화된 해시 값을 포함하여 핸드세이크 과정의 무결성을 검증

7. Client Finished

• 클라이언트가 핸드세이크 완료 알림
  • 클라이언트는 Finished 메시지를 전송하여 자신의 핸드세이크 단계가 완료되었음을 서버에게 알림
  • 이 메시지도 세션 키로 암호화된 해시 값을 포함하여 핸드세이크 과정의 무결성을 검증

8. 데이터 전송 시작

• 암호화된 데이터 전송
  • 핸드세이크 과정이 완료되면 클라이언트와 서버는 상호간에 암호화된 데이터를 안전하게 주고받을 수 있음

키 교환 알고리즘

• TLS 1.3에서는 RSA 키 교환을 지원하지 않으며 타원 곡선 디피-헬만(ECDH) 키 교환을 기본적으로 사용 (이는 보안 강화를 위한 결정)

디피-헬만(DH) 알고리즘

• 디피-헬만 키 교환은 두 당사자가 안전하지 않은 통신 채널을 통해 비밀 키를 공유할 수 있도록 함
• 비대칭 암호화 기법으로 두 당사자가 서로의 공개값을 공유하고, 이를 각자의 비밀값과 혼합하여 안전한 방식으로 공유 비밀 키를 생성하는 암호화 알고리즘
• 이 알고리즘은 안전한 통신을 위한 대칭 키를 생성하는데 사용

타원 곡선 키 교환

• 두 당사자가 타원 곡선 상의 점을 사용하여 공유 비밀 키를 생성하는 암호화 방법
  

사이퍼슈트

• 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약
• 암호제품군이라고도 함
• TLS1.3 버전에는 다섯 개가 있음

   TLS_AES_128_GCM_SHA256
   TLS_AES_256_GCM_SHA384
   TLS_CHACHA20_POLY1305_SHA256
   TLS_AES_128_CCM_SHA256
   TLS_AES_128_CCM_8_SHA256

예를들어, TLS_AES_128_GCM-SHA256에는 세 가지 규약이 들어 있음을 뜻함

• TLS는 프로토콜
• AES_128_GCM은 AEAD 사이퍼 모드
• SHA256 해싱 알고리즘

AEAD(Authenticated Encryption with Associated Data) 사이퍼 모드

• 데이터의 기밀성과 무결성을 동시에 보장하는 암호화 방식
• 데이터를 암호화하면서 인증을 통해 데이터의 변경 여부를 확인할 수 있음
• AEAD 사이퍼 모드는 주로 네트워크 보안, 데이터 전송 보안, 파일 보안 등에 사용

대표적인 AEAD 모드

모드	설명
GCM (Galois/Counter Mode)	AES-GCM은 널리 사용되는 AEAD 모드로, 효율적인 성능과 강력한 보안을 제공합니다. GCM 모드는 카운터 모드와 Galois 메시지 인증 코드를 결합하여 데이터의 암호화와 인증을 동시에 수행합니다.
CCM (Counter with CBC-MAC)	CCM은 AES-CTR(카운터 모드)과 CBC-MAC를 결합한 방식입니다. CCM 모드는 무결성 검사를 위한 메시지 인증 코드(MAC)를 생성하면서 데이터를 암호화합니다.
ChaCha20-Poly1305	ChaCha20 스트림 사이퍼와 Poly1305 메시지 인증 코드를 결합한 AEAD 모드입니다. 이 모드는 경량화된 암호화 알고리즘으로, 성능이 중요한 모바일 및 임베디드 시스템에서 자주 사용됩니다.

해싱 알고리즘(Hashing Algorithm)

• 임의의 길이를 가진 입력 데이터를 고정된 길이의 해시 값(hash value)으로 변환하는 수학적 함수
• 해싱 알고리즘의 주요 목적은 데이터의 무결성을 검증하고 빠른 데이터 검색 및 비교를 가능하게 하는 것

대표적인 해싱 알고리즘

알고리즘	설명
MD5 (Message Digest Algorithm 5)	128비트 해시 값을 생성하며, 과거에 널리 사용되었으나 현재는 보안 취약점 때문에 사용이 권장되지 않습니다.
SHA-1 (Secure Hash Algorithm 1)	160비트 해시 값을 생성하며, MD5보다 강력하지만 현재는 보안 문제로 인해 사용이 줄어들고 있습니다.
SHA-2 (Secure Hash Algorithm 2)	SHA-224, SHA-256, SHA-384, SHA-512 등의 여러 변종을 포함하며, 현재 널리 사용되는 안전한 해시 알고리즘입니다.
SHA-3	가장 최신의 표준 해시 알고리즘으로, 기존 SHA-2에 비해 다양한 보안 강화를 제공합니다.

Q. 해싱 알고리즘은 TLS에서 어떻게 쓰이는가?

• 인증서가 올바른 인증서인지 확인할 때 전자서명을 이용하는데 이 때 해싱 알고리즘이 사용됨

1. 인증 생성 작업 : 전자 서명을 만드는데 사명되는 메시지를 해싱
2. 인증 확인 작업 : 메시지를 복호화해서 해시를 서로 비교해 올바른 메시지인지 확인

인증서(Digital Certificate)

• 데이터 파일로 주체의 신원을 확인하고 데이터를 암호화하는데 사용
• 주로 SSL/TLS 프로토콜에서 웹사이트와 사용자 간의 안전한 통신을 보장하는데 사용

구성요소
1. 주체

• 인증서 발급한 CA(Certificate Authority) : 인증서를 발급한 기관
  • 이 기관은 인증서를 검증하고 신뢰할 수 있는지를 확인하는 역할을 담당
• 도메인 : 인증서가 보화하는 도메인 이름
• 웹사이트 소유자 : 도메인을 소유하고 있는 개인이나 조직
• 인증서 소유자 : 인증서를 실제로 사용하는 주체로 일반적으로 웹사이트의 소유자와 동일

2. 공개키

• 공개키(Public Key) : 암호화와 인증을 위한 키로 인증서에 포함
• 공개키 암호화 방법 : 공개키를 사용하는 암호화 알고리즘(예: RSA, ECDSA)

인증서의 유형

• SSL 인증서는 다양한 요구에 맞추어 여러 유형으로 제공됨

1. 단일 도메인 인증서(Single Domain Certificate)

• 특정 도메인 하나에 대해서만 유효한 인증서
• 예시 : www.example.com에 대해 발급된 단일 도메인 인증서는 www.example.com만 보호
• 사용 사례 : 하나의 웹사이트를 운영하는 경우 적합

2. 와일드카드 인증서(Wildcard Certificate)

• 특정 도메인과 그 하위 도메인 전체를 보호할 수 있는 인증서
  • *기호를 사용하여 하위 도메인을 표시
• 예시 : *.example.com에 대해 발급된 와일드카드 인증서는 www.example.com, mail.example.com, blog.example.com 등 모든 하위 도메인을 보호함
• 사용 사례 : 여러 하위 도메인을 운영하는 경우 적합

3. 멀티 도메인 인증서(Multi-Domain Certificate)

• 여러 도메인 이름을 하나의 인증서로 보호할 수 있는 인증서
  • SANs(Subject Alternative Names)필드르 사용하여 여러 도메인을 지정할 수 있음
• 예시 : example.com, example.net, example.org를 하나의 멀티 도메인 인증서로 보호할 수 있음
• 사용 사례 : 여러 도메인을 운영하는 기업이나 웹사이트 그룹에 적합

RSA의 취약점

• RSA에서 클라이언트가 생성한 임시 암호값(Pre-master Secret)을 서버로 전송하는데, 이 값이 탈취되면 전체 통신이 해독될 위험이 있음
• 이는 단일 실패 지점(single point of failure)을 형성하여 공격자가 임시 암호값을 확보하면 세션 키를 복구하고 통신 내용을 해독할 수 있음
• RSA 키의 길이가 길어질수록 보안은 강화되지만, 연산 속도가 느려짐
• 충분히 긴 키를 사용하지 않으면 RSA는 소인수 분해 공격에 취약할 수 있음