TLS handshake 과정

TLS handshake 과정

TLS (Transport Layer Security) 핸드셰이크 과정은 클라이언트와 서버 간에 안전한 통신을 설정하기 위한 중요한 절차입니다. 이 과정은 클라이언트와 서버가 서로 인증하고, 암호화 키를 교환한 후, 안전한 연결을 설정하는 일련의 단계로 이루어집니다.

TLS 핸드셰이크는 여러 단계로 나뉘며, 주로 네 가지 핵심 목표를 달성합니다:

1. 암호화 알고리즘 협상 (암호 스위트 결정)
2. 서버 인증 (인증서 확인)
3. 세션 키 생성 (대칭키 생성)
4. 데이터 암호화 시작 (보안 채널 생성)

TLS 핸드셰이크 과정은 보통 아래와 같은 단계로 진행됩니다:

---

1. ClientHello

• 목적: 클라이언트가 서버에 연결을 시작하고, 사용할 수 있는 암호화 설정을 제안.
• 내용:
  • TLS 버전: 클라이언트가 지원하는 TLS 버전 (예: TLS 1.2, TLS 1.3).
  • 암호 스위트 목록: 클라이언트가 지원하는 암호화 알고리즘 목록 (예: AES, RSA, ECDHE 등).
  • 랜덤 데이터 (Client Random): 나중에 세션 키 생성을 위한 랜덤한 데이터.
  • 세션 ID: 이전 세션이 있다면 재사용을 위한 세션 ID 제공.
  • 확장 필드: 서버 이름 표시(SNI), ALPN, PFS(완전한 순방향 기밀성) 등.

브라우저가 이 메시지를 보내면, 서버는 이 정보를 토대로 보안 설정을 결정합니다.

2. ServerHello

• 목적: 서버가 클라이언트의 제안을 받아들이고, 사용할 보안 매개변수를 결정.
• 내용:
  • TLS 버전: 서버가 선택한 TLS 버전.
  • 암호 스위트: 서버가 선택한 암호화 알고리즘 (예: ECDHE-RSA-AES128-GCM-SHA256).
  • 랜덤 데이터 (Server Random): 세션 키 생성을 위한 서버 측 랜덤 데이터.
  • 세션 ID: 세션이 재사용될 경우 사용되는 ID.

이 메시지를 통해 서버는 클라이언트와 어떤 암호화를 사용할지 확정합니다.

3. 서버 인증 및 키 교환

• 서버는 클라이언트에게 서버 인증서를 전송합니다. 이 인증서는 서버의 신원을 증명하기 위해 사용됩니다.
  • 서버 인증서: 서버의 공개 키와 서버의 신원을 증명하는 인증서 (대개 X.509 형식). 이 인증서는 신뢰할 수 있는 CA(Certificate Authority, 인증 기관)에 의해 서명되어야 합니다.
  • 인증서는 도메인과 일치해야 하며, 유효기간과 발급자도 검증됩니다.

클라이언트는 이 인증서를 받고 다음을 확인합니다:

1. 서버 인증서의 신뢰성: 인증서가 신뢰할 수 있는 CA에 의해 서명되었는지.
2. 도메인 일치 여부: 클라이언트가 접속하려는 도메인과 인증서의 도메인 정보가 일치하는지.
3. 유효성: 인증서가 만료되지 않았는지.

또한, 서버는 선택적으로 서버 키 교환 메시지를 보낼 수 있습니다. 이 메시지는 서버가 선택한 키 교환 방식에 따라 달라집니다 (RSA, DH, ECDHE 등).

4. 클라이언트 키 교환 (Client Key Exchange)

• 목적: 클라이언트가 세션 키(대칭 키)를 생성하기 위한 데이터를 서버에 전송.
• 과정: 클라이언트는 서버로부터 받은 공개 키를 사용하여 Pre-Master Secret이라는 임시 데이터를 암호화하여 서버에 보냅니다.

Pre-Master Secret은 클라이언트와 서버가 공유하는 비밀로, 이를 통해 최종적으로 대칭 암호화를 위한 마스터 시크릿(Master Secret)이 생성됩니다. Pre-Master Secret은 서버의 공개 키로 암호화되어 전송되므로, 중간에 가로채더라도 해독할 수 없습니다.

5. 세션 키 생성

• 클라이언트와 서버는 서로 주고받은 랜덤 데이터 (Client Random, Server Random)와 Pre-Master Secret을 사용하여 마스터 시크릿을 생성합니다.
• 마스터 시크릿은 다시 대칭 암호화에 사용할 세션 키로 변환됩니다. 이 세션 키는 이후의 데이터 통신을 암호화하는 데 사용됩니다.
• 이 과정은 대칭키 기반 암호화가 되므로, 성능이 우수하고 데이터 전송이 효율적입니다.

6. 클라이언트 완료 (Client Finished)

• 클라이언트는 "Finished" 메시지를 서버에 전송하여 핸드셰이크가 완료되었음을 알립니다. 이 메시지는 클라이언트가 생성한 세션 키로 암호화됩니다.
• 이 메시지는 핸드셰이크 중 발생한 모든 데이터의 무결성을 검증하는 역할을 합니다.

7. 서버 완료 (Server Finished)

• 서버도 "Finished" 메시지를 클라이언트에 전송하여 TLS 핸드셰이크의 완료를 알립니다.
• 이때부터 클라이언트와 서버는 대칭 암호화 방식으로 안전하게 데이터를 주고받습니다.

---

요약

TLS 핸드셰이크는 다음과 같은 목표를 달성합니다:

1. 서버와 클라이언트 간의 인증: 클라이언트는 서버의 신원을 확인하고, 서버는 선택적으로 클라이언트를 인증할 수 있습니다.
2. 암호화 매개변수 협상: 클라이언트와 서버가 사용할 암호화 알고리즘과 프로토콜 버전을 협상합니다.
3. 세션 키 교환: 양측은 안전하게 대칭 키를 생성하여 이후의 통신을 암호화합니다.

TLS 1.2 vs. TLS 1.3 차이점

• TLS 1.2에서는 클라이언트 키 교환, 서버 키 교환 등의 여러 핸드셰이크 단계가 있었지만, TLS 1.3에서는 이 과정이 단순화되었습니다.
  • TLS 1.3에서는 핸드셰이크 과정에서 암호화되지 않은 데이터가 최소화되며, 보안성 및 성능이 향상되었습니다.
  • 특히, TLS 1.3에서는 **1-RTT(One Round Trip Time)**로 연결이 성립되어 더 빠른 연결 성립이 가능해졌습니다.

---

이 모든 과정이 완료되면 클라이언트와 서버는 안전한 통신이 가능한 암호화된 세션을 형성하게 됩니다.