HTTPS – 안전한 인터넷 통신의 절차(핸드셰이크)

인터넷에서 https://로 시작하는 웹사이트를 접속할 때, 단순히 페이지를 불러오는 것이 아니라 데이터가 안전하게 암호화되어 전달된다. HTTPS는 SSL/TLS 프로토콜을 기반으로, 클라이언트와 서버 간에 신뢰할 수 있는 보안 통신 채널을 구축한다.

 

이때 HTTPS 통신의 핵심 과정 중 하나가 핸드셰이크(Handshake)이다. 핸드셰이크란 클라이언트와 서버가 보안 세션(Security Session)을 생성하고, 사용할 암호화 방식과 키를 안전하게 합의하는 과정을 말한다. 즉, 안전하게 통신하기 위한 “서로 인사하고, 통신 규칙과 비밀 키를 정하는 단계”라고 이해하면 쉽다.

 

아래에서는 HTTPS 통신을 핸드셰이크 단계와 실제 데이터 전송 단계로 나누어, 데이터를 안전하게 보호하는 원리와 공개키/개인키 역할을 단계별로 자세히 살펴본다.

 

1. 핸드셰이크 단계

1. 클라이언트 접속 요청 (Client Hello)

브라우저가 “어떤 암호화 방법을 지원하는지” 서버에게 알려주는 단계

• 사용자가 브라우저에 https:// 주소를 입력하면, 브라우저가 서버에 접속 요청을 보낸다.
• 단순 HTTP 요청이 아니라 TLS/SSL 설정을 위한 초기 메시지(Client Hello) 를 포함한다.
• Client Hello 메시지 내용:
  • 지원 TLS 버전: 예) TLS 1.2, TLS 1.3
  • Cipher Suite(암호화 알고리즘 모음)
    • Key Exchange 알고리즘 (예: RSA, DH, ECDH) → 세션 키 교환
    • 대칭키 암호화 알고리즘 (예: AES, ChaCha20) → 실제 데이터 암호화
    • *해싱(Hash) 알고리즘 (예: SHA-256, SHA-384) → 데이터 무결성 검증

*해싱 알고리즘

데이터를 추정하기 힘든 더 작고, 섞여 있는 조각으로 만드는 알고리즘이다. SSL/TLS는 해싱 알고리즘으로 **SHA-256 알고리즘과 SHA-384 알고리즘을 쓴다.

 

**SHA-256 알고리즘

SHA-256 알고리즘은 해시 함수의 결과값이 256비트인 알고리즘이며 비트 코인을 비롯한 많은 블록체인 시스템에서도 쓴다. SHA-256 알고리즘은 해싱을 해야 할 메시지에 1을 추가하는 등 전처리를 하고 전처리된 메시지를 기반으로 해시를 반환한다.

 

2. 서버 응답 (Server Hello)

서버와 클라이언트가 사용할 TLS 버전과 암호화 방법을 합의한다.

• 서버는 Client Hello를 확인하고, 서버가 선택한 TLS 버전과 Cipher Suite를 응답한다.
• 이때 서버는 랜덤 값(Random)도 함께 보내, 이후 세션 키 생성에 사용된다.

3. 서버 인증서와 공개키 제공

“이 서버가 진짜임을 신뢰”할 수 있는 단계

• 서버는 *SSL/TLS 인증서를 클라이언트에게 전송한다.
• SSL/TLS 인증서 내용:
  • 서버 정보 (도메인, 발급 기관 등)
  • 공개키(Public Key) - 공개키는 이후 세션 키 교환 시 안전한 암호화에 사용된다.
  • CA(Certificate Authority) 서명
• 클라이언트는 인증서를 검증하여 서버가 신뢰할 수 있는지 확인한다.

 

*SSL/TLS 인증서 발급받는 과정

1. 서버는 SSL/TLS 인증서를 발급받기 위해 CA에 요청
   • 서버는 자신의 도메인, 조직 정보, 공개키(Public Key) 등을 CA에 제출한다.
   • 이 과정을 CSR(Certificate Signing Request) 제출이라고 한다.
2. CA는 서버 정보를 검증하고 인증서 발급
   • CA는 제출된 정보가 신뢰할 수 있는지 확인 (도메인 소유권 확인 등)
   • 이후 서버의 공개키와 정보를 기반으로 서버 인증서(Server Certificate) = SSL/TLS 인증서 를 생성한다.
   • CA는 이 서버 인증서에 자신(CA)의 비밀키로 디지털 서명을 한다.
     • 클라이언트는 CA의 공개키를 이용해 이 서명을 검증하고, 서버 인증서가 진짜임을 확인할 수 있다.
3. Finger Print(지문)
   • Fingerprint는 인증서 자체의 무결성을 검증하기 위한 해시값으로, 인증서 발급 과정에서 CA가 사용하는 것은 아니다.
   • 클라이언트가 서버 인증서를 비교하거나 확인할 때 유용하게 쓰인다.

 

4. 클라이언트 Pre-Master Key 암호화

공개키/개인키 기반으로 세션 키를 안전하게 공유하는 단계. 이 과정까지가 핸드셰이크의 핵심이다.

• 클라이언트는 서버 공개키를 사용해 *pre-master key를 암호화하고 서버로 전송한다.
• 서버만 자신의 개인키(Private Key)로 복호화할 수 있다.

*pre-master key

SSL/TLS 핸드셰이크 과정에서 클라이언트와 서버가 공유하는 임시 비밀값으로, 이 값을 기반으로 클라이언트와 서버가 실제 통신에 사용할 대칭키(Session Key) 를 안전하게 만들어낸다. 즉, pre-master key 자체가 데이터를 암호화하는 키는 아니고, 대칭키를 생성하는 재료 역할을 한다.

5. 서버 개인키 복호화 → 세션 키 생성

핸드셰이크 종료 → 보안 세션(Security Session) 시작

• 서버는 개인키로 pre-master key를 복호화한다.
• 클라이언트와 서버는 이를 기반으로 대칭 세션 키(Session Key) 를 생성한다.
• 대칭키는 이후 데이터 암호화/복호화에 사용되며, 속도가 빠르고 효율적이다.

 

2. 실제 데이터 통신 단계 (핸드셰이크 후)

1. 데이터 암호화/복호화 (대칭키)

• 실제 애플리케이션 데이터 전송 단계에서는 대칭키 암호화를 사용한다.
• 서버와 클라이언트는 공유된 세션 키로 데이터를 빠르게 암호화/복호화하며 안전하게 전달한다.

 

2. 데이터 무결성 확인 (해싱)

“전송 중 데이터가 변조되지 않았음을 확인”하는 단계

• SSL/TLS는 해싱(Hashing)으로 데이터가 변조되지 않았는지 확인한다.
• 사용 알고리즘: SHA-256, SHA-384 등
• 클라이언트와 서버가 동일한 해시 값을 얻으면, 데이터가 안전하게 전달되었음을 검증한다.

 

3. 전체 HTTPS 통신 흐름 요약

1. 클라이언트 접속 요청 (Client Hello) → TLS 버전과 Cipher Suite 전송
2. 서버 응답 (Server Hello) → TLS 버전과 암호화 방식 합의, 랜덤 값 교환
3. 서버 인증서 + 공개키 제공 → 서버 신뢰 확인
4. 클라이언트 Pre-Master Key 암호화 전송 → 세션 키 교환
5. 서버 개인키 복호화 → 세션 키 생성 → 핸드셰이크 종료
6. 대칭키 암호화 통신 → 실제 데이터 전송
7. 데이터 무결성 검증 (해싱) → 안전한 통신 완료