SSL/TLS 통신의 인증서·세션키·핸드셰이크 구조

SSL/TLS의 인증 방식, 프로토콜 구성, 핸드셰이크와 인증서 관리 관점을 정리한 보안 통신 기술 가이드

2026-08-14 · 최초 발행 2025-05-23

SSL이라는 이름으로 남은 TLS 보안 통신

SSL은 TCP/IP 프로토콜 스택에서 동작하는 암호화 통신 프로토콜이다. 웹 브라우저와 웹 서버가 데이터를 안전하게 주고받도록 설계됐으며, 현재의 기술 계보는 TLS(Transport Layer Security)로 이어진다. 다만 현장에서는 TLS를 포함해 SSL이라는 이름으로 부르는 경우가 여전히 많다.

HTTPS URL 스킴은 https://를 사용하며 기본 포트는 443이다. 이는 HTTP의 기본 포트 80과 구별된다. 연결을 시작할 때는 클라이언트와 서버가 핸드셰이크를 수행해 인증과 암호화 조건을 합의한다.

SSL은 RHCA(Red Hat Certified Architect) 자격에서도 중요한 보안 요소로 다뤄진다.

인증 방식과 연결에 필요한 정보

SSL은 X.509 V3 인증서를 사용하고, 비대칭 암호화를 통해 안전한 키 교환을 제공한다. 연결 대상의 신뢰 수준에 따라 인증 방식도 달라진다.

  • 익명(Anonymous) 인증에서는 클라이언트와 서버가 모두 인증되지 않는다.
  • 서버 인증(Server Authentication)은 서버만 인증한다.
  • 상호 인증(Mutual Authentication)은 클라이언트와 서버 모두를 인증한다.

통신을 구성하는 핵심 정보는 서버 디지털 ID, 선택적으로 쓰이는 클라이언트 디지털 ID, 그리고 실제 데이터 암호화에 사용할 세션키다. 서버 인증서는 신뢰할 수 있는 인증 기관(CA)이 발급하며 서버의 공개키와 신원 정보를 담는다. 상호 인증이 필요한 환경에서는 클라이언트 디지털 ID로 클라이언트 신원을 확인할 수 있다.

세션키는 실제 데이터 암호화에 쓰이는 대칭키다. 매 세션마다 새로 생성되므로 보안성을 강화한다.

전송부터 오류 알림까지 맡는 프로토콜

SSL은 4개의 주요 프로토콜로 구성된다.

SSL 프로토콜Record ProtocolHandshake ProtocolChange Cipher SpecProtocolAlert Protocol데이터 암호화, 압축비밀정보, 세션정보 공유SSL 메시지 형식 정의경고 오류 전달

Record Protocol은 SSL의 기본 전송 계층 역할을 한다. 상위 프로토콜에서 받은 데이터를 분할하고 MAC(Message Authentication Code)을 적용하며, 데이터 암호화와 압축을 담당한다.

Handshake Protocol은 통신 시작 시점에 양측이 비밀정보와 세션정보를 공유하도록 한다. 사용할 암호화 알고리즘을 협상하고 서버 및 클라이언트 인증을 수행해 안전한 연결의 기반을 만든다.

Change Cipher Spec Protocol은 SSL이 주고받는 메시지 형식을 정의하고, 암호화 매개변수가 바뀌는 시점을 알린다. 구성은 매우 간단한 1바이트 메시지다.

Alert Protocol은 2바이트 구성의 경고 메시지를 전달한다. 경고 수준은 Warning(경고)과 Fatal(치명적)로 나뉘며, 보안 관련 오류가 생기면 통신 당사자에게 이를 알린다.

인증서 확인 후 암호화 세션을 수립하는 흐름

핸드셰이크에서는 클라이언트와 서버가 지원 범위를 맞추고, 서버 인증서를 전달하며, 키 교환을 거쳐 암호화 통신을 시작한다.

서버클라이언트서버클라이언트서버 인증 단계키 교환 단계Premaster Secret 복호화 및Master Key 생성Master Key 생성세션 수립 완료Client Hello (SSL 버전, 암호화 설정)Server Hello (SSL 버전, 암호화 설정, 서버 인증서)Premaster Secret (서버 공개키로 암호화)Change Cipher Spec (암호화 시작 신호)Finished (암호화된 메시지)Change Cipher Spec (암호화 시작 신호)Finished (암호화된 메시지)

클라이언트는 Client Hello로 자신이 지원하는 SSL 버전과 암호화 알고리즘 목록을 전송하고, 이후 키 생성에 사용할 랜덤 데이터도 함께 보낸다.

서버는 Server Hello에서 선택한 SSL 버전과 암호화 알고리즘을 응답한다. 이때 서버 인증서와 서버 랜덤 데이터도 전송한다.

키 교환 단계에서는 클라이언트가 Premaster Secret을 생성한 뒤 서버 공개키로 암호화해 전달한다. 양측은 클라이언트 랜덤, 서버 랜덤, Premaster Secret을 조합해 Master Key를 생성한다.

이후 Change Cipher Spec 메시지로 암호화 통신의 시작을 알리고, Finished 메시지로 핸드셰이크 성공을 확인한다. 이후 데이터는 협상된 대칭키로 암호화되어 전송된다.

적용되는 환경과 TLS의 변화

전자상거래 사이트는 결제 정보와 개인정보를 보호하기 위해 HTTPS를 적용한다. 아마존과 이베이 같은 대형 쇼핑몰이 그 예다.

인터넷 뱅킹에서는 금융 거래 정보를 보호하며, 2-way SSL(상호 인증)을 적용해 보안을 강화할 수 있다. 기업 내부망에서는 VPN과 연계한 원격 접속 보안, 내부 웹 서비스 보호에 활용된다. 스마트홈과 산업용 IoT 장비도 통신 보안이 필요하며, 자원 제약 환경에서는 경량화된 TLS 구현을 적용할 수 있다.

SSL은 SSL 2.0과 3.0을 거쳐 TLS 1.0, 1.1, 1.2, 1.3으로 발전했다. 2018년 표준화된 TLS 1.3은 핸드셰이크 과정을 간소화해 성능을 향상했다. QUIC 프로토콜과 통합된 HTTP/3에서는 보안이 기본으로 내장된다.

운영에서 확인할 보안 설정

인증서는 만료 기간을 모니터링해야 하며, 적절한 키 길이와 암호화 알고리즘을 선택하고 프라이빗 키를 안전하게 관리해야 한다.

POODLE, BEAST, Heartbleed처럼 알려진 취약점에는 최신 패치로 대응한다. SSL 3.0과 TLS 1.0 같은 구 버전 프로토콜은 비활성화 대상이다.

암호 스위트는 강력한 구성을 선택하고, 퍼펙트 포워드 시크리시(Perfect Forward Secrecy)를 활성화한다. HSTS(HTTP Strict Transport Security) 구현도 HTTPS 환경의 보안 설정에 포함된다.

SSL/TLS는 웹뿐 아니라 여러 네트워크 애플리케이션에서 데이터의 기밀성과 무결성을 보장하는 기반이다. 인증서, 키 교환, 프로토콜 설정을 이해하고 보안 업데이트와 모니터링을 지속해야 이 기반이 실제 운영 환경에서도 유지된다.

SSLTLSHTTPS인증서네트워크 보안