루카쓰로그 v2.0
🧐TIL

[다시하는 백엔드 기초 공부] SSL / TLS

SSL과 TLS

앞선 포스팅에서 잠깐 설명했지만 HTTP에 SSL/TLS 프로토콜을 결합하여 보안을 강화한 것이 HTTPS 였다. 그렇다면 SSL/TLS 가 무엇을 하길래 보안을 강화시켜 줄 수 있는 것일까?

SSL은 Secure Sockets Layer의 약자로 1995년에 넷스케이프에 의해 탄생한 웹브라우저와 웹서버간 데이터 통신을 암호화하는 프로토콜이다. 그러나 1996년에 나온 SSL 3.0에서 설계 결함으로 인한 보안 취약점이 발견되었고 이를 보완하여 나온 것이 TLS 다.

TLS는 Transport Layer Security의 약자로 SSL을 계승하여 현재 웹에서 쓰이는 보안 통신은 대부분 TLS 기반이다. 즉, 흔히 “SSL 인증서”라고 부르는 것도 실제로는 TLS 인증서이며 SSL은 역사적인 이름일 뿐 TLS가 현재의 표준이라고 이해하면 된다.

SSL/TLS가 해결하는 문제

웹을 통해 데이터를 주고받을 때는 누군가 네트워크를 가로채서 내용을 훔쳐보는 도청(Eavesdropping), 데이터를 중간에서 바꾸는 변조(Modification), 가짜가 진짜 통신 대상인 척하는 위장(Spoofing) 등의 위험이 존재한다. 이를 방지하기 위해 SSL/TLS는 아래 세 가지를 보장한다.

  1. 기밀성(Confidentiality): 데이터를 암호화하여 도청을 방지
  2. 무결성(Integrity): 데이터가 중간에 변조되지 않았음을 보장
  3. 인증(Authentication): 서버(혹은 클라이언트)의 신원을 검증

SSL/TLS의 동작 방식

TLS는 기본적으로 TCP 위에서 동작한다. 그래서 TCP 연결과정부터 나열하면 시퀀스는 아래와 같다.

  1. TCP 3-way handshake
  2. TLS 핸드셰이크 — 통신 상대에 대한 검증 및 데이터를 주고 받기 위해 어떤 방법을 사용할 것인지 파악
  3. 전송 — 암호화 및 복호화 과정을 포함한 데이터 전송
  4. 세션 종료 (또는 재개) — 종료 시 세션 키는 폐기

TLS 핸드셰이크 과정

  1. Client Hello: 클라이언트가 서버에 접속
  2. Server Hello: 서버에서 클라이언트의 통신에 응답
  3. 인증서 검증: 클라이언트가 인증서의 유효성을 검증
  4. 클라이언트 키 교환: 클라이언트가 세션 키를 생성하기 위한 데이터를 서버에 전송
  5. 세션 키 생성: 클라이언트와 서버 각각에서 이번 통신 세션 동안 사용할 세션 키(Session Key)를 생성
  6. 클라이언트 완료(Client Finished): 클라이언트에서 핸드셰이크가 완료되었음을 알림
  7. 서버 완료 (Server Finished): 서버에서도 핸드셰이크가 완료되었음을 알림
  8. 암호화된 통신 시작: 이후의 모든 데이터는 세션 키로 암호화되어 전송

인증서와 인증기관 (CA, Client Authority)

  • **인증서(Certificate)**는 SSL/TLS의 핵심 요소 중 하나로 서버의 공개키 및 도메인 정보를 담고 있는 전자 문서다.
  • 인증서는 서버 측에서 CA를 통해 별도로 발급을 받아야 하며, HTTPS 프로토콜을 사용하더라도 CA를 통한 서명이 갖춰지지 않았거나 인증서가 만료되었을 경우 브라우저가 신뢰하지 않는다.