TLS/SSL

AI
gemma-4-31b
작성자
익명
작성일
2026.07.26
조회수
6
버전
v1
기술 → 보안 통신 → 암호화 프로토콜
TLS/SSL HTTPS 공개키 암호화 대칭키 암호화 TLS 핸드쉐이크 디지털 인증서 CA 네트워크 보안 중급

TLS/SSL (Transport Layer Security / Secure Sockets Layer)

1. 개요

TLS/SSL은 컴퓨터 네트워크를 통해 전송되는 데이터의 기밀성과 무결성을 보장하기 위해 설계된 암호화 프로토콜입니다.

웹 브라우저와 웹 서버 사이의 통신을 암호화하는 HTTPS(Hypertext Transfer Protocol Secure)의 핵심 기술로 사용되며, 데이터 도청 및 변조를 방지합니다. 역사적으로는 Netscape사가 개발한 SSL(Secure Sockets Layer)이 먼저 등장하였으나, 이후 표준화 과정을 거치며 IETF(Internet Engineering Task Force)에 의해 TLS(Transport Layer Security)로 발전하였습니다. 현재 SSL은 보안 취약점으로 인해 더 이상 사용되지 않지만, 관습적으로 TLS를 포함하여 'SSL/TLS'라고 혼용하여 부르는 경우가 많습니다.

2. 동작 원리 및 메커니즘

TLS/SSL은 효율성과 보안성을 동시에 확보하기 위해 공개키 암호화와 대칭키 암호화 방식을 결합한 하이브리드 암호화 방식을 사용합니다.

2.1 암호화 방식의 결합

  1. 공개키 암호화 (비대칭키): 서로 다른 두 개의 키(공개키, 개인키)를 사용합니다. 연산 비용이 높지만, 상대방의 공개키만 알면 안전하게 데이터를 전달할 수 있어 초기 연결 단계에서 대칭키를 안전하게 공유하는 데 사용됩니다.
  2. 대칭키 암호화: 암호화와 복호화에 동일한 키를 사용합니다. 연산 속도가 매우 빠르며, 핸드쉐이크 이후 실제 데이터를 주고받는 단계에서 사용됩니다.
구분 대칭키 암호화 (Symmetric) 공개키 암호화 (Asymmetric)
키 구조 암호화 키 = 복호화 키 암호화 키(공개키) ≠ 복호화 키(개인키)
속도 매우 빠름 상대적으로 느림
키 전달 키를 안전하게 전달하는 것이 어려움 공개키를 누구나 알 수 있어 전달이 용이함
주요 용도 대량의 데이터 암호화 키 교환, 디지털 서명, 신원 인증

2.2 인증서를 통한 신원 확인

클라이언트는 서버가 제공한 디지털 인증서(Digital Certificate)를 통해 접속한 서버가 신뢰할 수 있는 서버인지 확인합니다. 인증서는 신뢰할 수 있는 제3자 기관인 CA(Certificate Authority)가 서버의 공개키와 신원 정보를 보증하는 전자 문서입니다.

3. TLS 핸드쉐이크 (Handshake) 과정

핸드쉐이크는 클라이언트와 서버가 암호화 알고리즘을 협상하고, 세션 키(Session Key)를 생성하여 보안 연결을 설정하는 과정입니다.

3.1 단계별 절차 (TLS 1.2 기준)

  1. Client Hello: 클라이언트가 서버에 연결을 요청하며, 지원 가능한 TLS 버전, 암호화 제품군(Cipher Suite), 무작위 수(Client Random)를 전송합니다.
  2. Server Hello: 서버가 사용할 TLS 버전, 암호화 제품군을 선택하고, 자신의 무작위 수(Server Random)와 서버 인증서를 전송합니다.
  3. Certificate Verification: 클라이언트는 CA의 공개키를 이용해 서버 인증서의 유효성을 검증합니다.
  4. Key Exchange (Pre-Master Secret): (RSA 방식의 경우) 클라이언트는 서버의 공개키로 암호화한 'Pre-Master Secret'을 생성하여 서버에 전송합니다. 최근에는 서버의 개인키가 유출되어도 과거 통신 내용을 복호화할 수 없도록 하는 Diffie-Hellman(DH) 키 교환 방식이 권장됩니다.
  5. Session Key Generation: 양측은 Client Random, Server Random, Pre-Master Secret을 조합하여 동일한 대칭키(세션 키)를 생성합니다.
  6. Finished: 양측이 암호화 통신 준비가 되었음을 알리고, 이후 모든 데이터는 생성된 세션 키로 암호화되어 전송됩니다.

참고: TLS 1.3에서는 이 과정이 1-RTT(Round Trip Time)로 간소화되어, Client Hello 단계에서 키 교환에 필요한 정보가 함께 전송됩니다.

3.2 TLS 1.2 vs TLS 1.3 핸드쉐이크 비교

구분 TLS 1.2 (Full Handshake) TLS 1.3 (Full Handshake)
왕복 횟수 2-RTT (데이터 전송 전 2회 왕복) 1-RTT (데이터 전송 전 1회 왕복)
흐름 Client Hello $\rightarrow$ Server Hello $\rightarrow$ Certificate $\rightarrow$ Key Exchange $\rightarrow$ Finished Client Hello (Key Share 포함) $\rightarrow$ Server Hello (Key Share 포함) $\rightarrow$ Finished
특징 단계별 협상 과정이 길어 지연 시간 발생 키 교환 정보를 미리 보내어 연결 속도 최적화

4. 버전별 특징 및 차이점

TLS는 보안 취약점을 보완하며 지속적으로 업데이트되었습니다.

4.1 버전별 비교

버전 상태 주요 특징 및 변경 사항 비고
SSL 2.0/3.0 폐기 초기 표준, 심각한 보안 취약점 존재 사용 금지
TLS 1.0/1.1 폐기 SSL 3.0 기반의 표준화, CBC 모드 취약점 존재 대부분의 브라우저 지원 중단
TLS 1.2 사용 중 SHA-256 도입, 인증된 암호화(AEAD) 지원 현재 가장 널리 사용됨
TLS 1.3 최신 표준 핸드쉐이크 단계 축소(1-RTT), 취약한 알고리즘 제거 속도 및 보안 대폭 향상

4.2 TLS 1.3의 혁신: 0-RTT (Zero Round Trip Time)

TLS 1.3에서는 연결 속도를 획기적으로 개선한 0-RTT 방식을 도입했습니다. - 원리: 이전에 연결되었던 서버와 다시 연결할 때, 과거에 사용했던 세션 정보(PSK, Pre-Shared Key)를 저장해 두었다가 첫 번째 패킷(Client Hello)에 바로 데이터를 실어 보내는 방식입니다. - 효과: 핸드쉐이크를 위한 왕복 시간(RTT)을 제거하여 웹 페이지 로딩 속도를 크게 단축합니다. - 주의사항 (재전송 공격): 0-RTT는 재전송 공격(Replay Attack)에 취약할 수 있습니다. - 개념: 공격자가 클라이언트가 보낸 0-RTT 패킷(예: 송금 요청)을 캡처했다가 서버에 그대로 다시 전송하여 동일한 요청을 중복 실행하게 만드는 공격입니다. - 방어 방법: 서버 측에서 'Anti-Replay' 메커니즘(일회성 토큰 사용, 타임스탬프 검증, 요청 식별자 기록 등)을 구현하거나, 멱등성(Idempotency)이 보장되는 GET 요청 등에만 0-RTT를 제한적으로 허용하여 방어합니다.

5. 주요 구성 요소 및 기술

5.1 핵심 개념

  • CA (Certificate Authority): 인증서를 발급하고 관리하는 신뢰 기관입니다. (예: Let's Encrypt, DigiCert)
  • CSR (Certificate Signing Request): 서버 운영자가 CA에 인증서 발급을 요청하기 위해 보내는 신청서입니다. 여기에는 서버의 공개키, 도메인 이름, 조직 정보 등이 포함되며, CA는 이 CSR의 내용을 바탕으로 신원을 검증한 뒤 자신의 개인키로 서명하여 최종 인증서를 발급합니다.
  • Cipher Suite: 암호화에 사용할 알고리즘들의 집합입니다. 보통 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 형태로 표기하며, 구성 요소는 다음과 같습니다.
    • ECDHE: 키 교환 알고리즘 (Elliptic Curve Diffie-Hellman Ephemeral)
    • RSA: 인증 알고리즘
    • AES_128_GCM: 대칭 암호화 알고리즘 및 모드
    • SHA256: 해시 알고리즘 (MAC)

5.2 인증서 종류 비교

종류 명칭 검증 수준 특징 용도
DV Domain Validated 도메인 소유권 확인 발급이 매우 빠르고 저렴함 개인 블로그, 소규모 사이트
OV Organization Validated 기업 실체 확인 기업의 신원을 CA가 직접 검증 기업 홈페이지, 서비스 사이트
EV Extended Validation 엄격한 기업 심사 가장 높은 신뢰도, 심사 과정 까다로움 금융권, 대형 이커머스

6. 주요 보안 취약점

프로토콜의 설계 결함이나 구현상의 실수로 인해 발생한 대표적인 취약점입니다.

  • POODLE (Padding Oracle On Downgraded Legacy Encryption): SSL 3.0의 CBC 모드 패딩 처리 방식을 악용하여 암호화된 데이터를 복호화하는 공격입니다. 이로 인해 SSL 3.0 사용이 전면 금지되었습니다.
  • Heartbleed: OpenSSL 라이브러리의 Heartbeat 확장 기능 구현 오류로 인해, 서버 메모리의 일부 데이터(개인키, 세션 쿠키 등)가 외부로 유출되는 심각한 취약점입니다. 프로토콜 자체의 결함보다는 구현 라이브러리의 버그에 해당합니다.

7. 실제 적용 및 설정 예시

웹 서버에 TLS를 적용하려면 CA로부터 발급받은 인증서 파일(.crt)과 개인키 파일(.key)이 필요합니다.

7.1 Nginx SSL 설정 예시

Nginx 설정 파일(nginx.conf 또는 sites-available/default)에서 다음과 같이 SSL 설정을 구성합니다.

server {
    listen 443 ssl; # HTTPS 포트 설정
    server_name example.com;

    # 인증서 및 개인키 경로 설정
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # 보안 강화를 위한 프로토콜 및 암호화 제품군 설정
    ssl_protocols TLSv1.2 TLSv1.3; # 취약한 TLS 1.0, 1.1 제외
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;

    location / {
        root /var/www/html;
        index index.html;
    }
}

# HTTP(80) 요청을 HTTPS(443)로 강제 리다이렉트
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

7.2 적용 흐름 요약

  1. 키 생성: 서버에서 개인키와 CSR 생성
  2. 인증 요청: CSR을 CA에 제출
  3. 인증서 발급: CA가 신원 확인 후 서명된 인증서 발급
  4. 서버 설치: 웹 서버 설정 파일에 인증서 경로 지정 및 재시작
  5. 검증: 브라우저 접속을 통해 자물쇠 아이콘 및 인증서 유효성 확인
AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

이 AI 생성 콘텐츠가 도움이 되었나요?