Day 5: HTTPS & SSL

1) 학습 요약표

학습 내용	설명
HTTPS와 SSL 인증서 개요	웹사이트와 사용자 간의 통신을 암호화하고 서버의 신원을 보장하기 위한 보안 프로토콜. 실제 사용은 TLS가 대부분이지만 SSL이라는 이름이 관행처럼 쓰임
대칭키 암호화	하나의 동일한 키로 암호화와 복호화를 처리하는 방식. 빠르지만 키 유출 시 보안에 취약하며 키 분배가 어려움
공개키 암호화	서로 다른 두 개의 키(공개키와 개인키)를 이용해 암호화/복호화. 대칭키 전달 문제 해결에 주로 사용
SSL 인증서	인증기관(CA)이 발급하는 서버 신원 확인용 디지털 문서. 루트/중간/서버 인증서 체계로 구성됨
인증서 작동 방식	인증서 교환, 검증, 세션 키 생성 및 전달 등 HTTPS 연결 과정에서의 흐름
SSL 통신 흐름	TCP 연결 이후 실제로 수행되는 핸드셰이크, 암호화 통신, 세션 복구 등 전체 통신 구조

 

2) 이론 설명

 

(1) HTTPS와 SSL 인증서

• HTTP는 정보를 암호화하지 않고 그대로 전송합니다. 이 때문에 공격자가 중간에서 내용을 가로채는 중간자 공격(Man-in-the-middle)이 발생할 수 있습니다.
• HTTPS는 이를 막기 위해 SSL/TLS 보안 계층을 사용하는 방식입니다. 하지만 현재는 SSL이 아니라 TLS(Transport Layer Security)가 사용됩니다.
• HTTPS는 기본적으로 443번 포트를 사용합니다. (HTTP는 80번 포트)
• 브라우저 주소창에 자물쇠 아이콘이 표시되면 현재 사이트가 인증서 기반으로 통신을 암호화하고 있다는 의미입니다.

(2) 대칭키 암호화 (Symmetric Key)

• 암호화는 데이터를 제3자가 읽을 수 없도록 바꾸는 과정이며, 복호화는 다시 원래 상태로 되돌리는 과정입니다.
• 대칭키 방식은 암호화와 복호화에 완전히 같은 키를 사용합니다.
• 예를 들어, 메신저에서 친구와 메시지를 주고받을 때 같은 암호(열쇠)를 공유하고 있어야 서로 해독이 가능합니다.
• 문제는 이 키를 어떻게 안전하게 전달할 수 있느냐입니다. 키가 유출되면 전체 보안이 무너집니다. 이걸 키 분배 문제(Key Distribution Problem)라고 합니다.
• 대칭키 암호는 크게 두 가지 방식으로 나뉩니다:
  • 블록 암호(Block Cipher): 데이터를 일정한 크기의 블록 단위로 나눠 암호화 (예: AES)
  • 스트림 암호(Stream Cipher): 데이터를 한 비트/한 바이트씩 순차적으로 암호화 (예: RC4)

(3) 공개키 암호화 (비대칭키, Public Key)

• 대칭키의 키 전달 문제를 해결하기 위해 비대칭키 암호화 방식이 등장했습니다.
• 비대칭 방식에서는 서로 다른 두 개의 키가 사용됩니다: 공개키(public key)와 개인키(private key)
  • 공개키: 누구에게나 공개. 데이터를 암호화하는 데 사용
  • 개인키: 본인만 알고 있는 비밀 키. 암호화된 데이터를 복호화하는 데 사용
• 서버는 공개키를 사용자에게 주고, 사용자는 이 공개키로 데이터를 암호화하여 서버에 전송합니다. 서버는 자신의 개인키로 복호화하여 내용을 확인합니다.
• 반대로 서버가 개인키로 전자서명(Digital Signature)을 하면, 사용자는 공개키로 이를 검증할 수 있습니다. 이로써 데이터 무결성과 신원 확인이 가능합니다.
• 공개키 방식은 처리 속도가 느리기 때문에 실질적인 데이터 암호화는 대칭키로 처리하고, 이 대칭키를 전달할 때만 공개키를 사용합니다.
• 공개키/개인키는 보통 RSA, ECC 등 알고리즘으로 생성되며, 이들을 하나의 키 쌍(Key Pair)이라 부릅니다.

(4) SSL 인증서란?

• SSL 인증서는 공인 인증기관(Certificate Authority, CA)이 발급한 디지털 서명 문서로, 서버의 신원을 증명합니다.
• 브라우저는 루트 인증서부터 서버 인증서까지의 인증서 체인(Certificate Chain)을 확인하면서, 서버가 정말 신뢰할 수 있는 사이트인지 확인합니다.
• 체인은 보통 다음과 같이 구성됩니다:
  • 루트 인증서 (Root CA) → 중간 인증서 (Intermediate CA) → 서버 인증서
• SSL 인증서에는 다음과 같은 정보가 들어있습니다:
  • 도메인 이름
  • 서버의 공개키
  • 발급자 정보 (CA 이름)
  • 유효 기간
  • 전자서명
• 기업이 직접 발급하는 자체 서명 인증서(Self-Signed Certificate)는 내부 테스트용으로 사용되며, 브라우저에서 신뢰되지 않습니다.
• 인증서 포맷에는 PEM(.crt), DER(.der), PKCS12(.pfx) 등이 있으며, 운영 체제나 웹 서버 종류에 따라 다르게 사용됩니다.

확장자/형식	용도	설명
.csr (Certificate Signing Request)	인증서 요청용	인증서 발급을 위해 생성한 요청서. 서버의 공개키와 조직 정보가 들어 있음. CA에 제출
.crt (Certificate)	서버 인증서	CA에서 발급한 인증서 파일. 서버가 사용자에게 제시함 (보통 PEM 형식)
.key	개인키	서버가 소유한 비공개 키. 절대 외부에 유출되면 안 됨
.pem (Privacy Enhanced Mail)	범용 포맷	Base64로 인코딩된 인증서·키 포맷. .crt, .key 등이 이 형식을 사용
.der	이진 인증서	PEM과 달리 바이너리로 인코딩된 형식 (Windows 계열에서 주로 사용)
.pfx / .p12 (PKCS#12)	인증서 + 개인키	인증서와 개인키를 하나의 파일로 묶은 포맷. 주로 Windows 서버, IIS에서 사용
.ca-bundle	인증서 체인	중간 CA 인증서 모음. 루트까지 신뢰 연결을 완성하기 위해 함께 제공됨

 

(5) 인증서 작동 방식

• HTTPS 통신을 위해 SSL 인증서가 사용되는 절차는 다음과 같습니다:

사용자의 브라우저가 https://example.com에 접속 요청을 보냅니다.
서버는 자신의 SSL 인증서를 브라우저에게 보냅니다.
브라우저는 이 인증서를 확인합니다:
CA 서명이 있는지 (정상 루트 체인인지)
도메인 이름과 일치하는지
인증서가 만료되지 않았는지
인증서가 폐기되지 않았는지 (CRL 또는 OCSP로 확인)
브라우저는 임시로 사용할 세션 키(대칭키)를 생성합니다.
이 키를 서버의 공개키로 암호화하여 서버에 전송합니다.
서버는 개인키로 이를 복호화합니다.
이제 양쪽은 동일한 세션 키를 공유하며, 이 키로 데이터를 대칭 방식으로 암호화하여 통신합니다.

※ 추가 개념:
CRL / OCSP: 인증서가 폐기되었는지 확인하는 메커니즘 (보안 강화 목적)
PFS (Perfect Forward Secrecy): 세션 키가 유출돼도 과거의 통신 내용은 복호화할 수 없도록 만드는 기법 (Diffie-Hellman 계열 사용)

 

(6) SSL 통신 전체 흐름 정리

1) TCP 3-way 핸드셰이크로 연결을 맺음
2) SSL/TLS Handshake 단계:
   - 클라이언트: ClientHello (지원 암호화 알고리즘 목록 포함)
   - 서버: ServerHello + 인증서 + (선택적) 서버 키 교환 메시지
   - 클라이언트: 인증서 검증 → 세션 키 생성
   - 세션 키를 공개키로 암호화하여 전송
   - 서버: 복호화하여 세션 키 확보
3) Finished 메시지로 암호화 통신 시작

※ 암호화 알고리즘 종류, 키 길이, 해시 알고리즘 등을 협상하는 정보를 Cipher Suite라고 합니다.
※ 세션 재사용 시에는 전체 핸드셰이크를 생략하고 성능을 높이는 Session Resumption 기능도 사용됩니다.