TLS/SSL Reference

TLS 버전, 암호 스위트, 키 교환 알고리즘 레퍼런스

16개 결과

TLS/SSL Reference 소개

TLS/SSL Reference는 인터넷 통신을 보호하는 데 사용되는 Transport Layer Security 프로토콜 버전, 암호 스위트, 키 교환 알고리즘, 핸드셰이크 메커니즘을 다루는 검색 가능한 치트 시트입니다. TLS 1.0과 1.1(POODLE, BEAST 취약점으로 2021년 폐기), TLS 1.2(AEAD 암호와 SHA-256+를 지원하는 현재 기준선), TLS 1.3(간소화된 1-RTT 핸드셰이크와 모든 불안전한 레거시 암호 제거가 적용된 최신 버전) 등 4개 TLS 버전을 모두 문서화합니다.

세 가지 TLS 1.3 암호 스위트를 상세히 다룹니다: TLS_AES_128_GCM_SHA256(가장 널리 배포됨), TLS_AES_256_GCM_SHA384(높은 보안 요구사항용), TLS_CHACHA20_POLY1305_SHA256(AES 하드웨어 가속 없는 모바일 기기에 최적화). 키 교환은 P-256 및 X25519 커브의 ECDHE(TLS 1.3 기본, 순방향 비밀성), DHE(순방향 비밀성 지원하나 느림), RSA 키 교환(순방향 비밀성 부재로 TLS 1.3에서 제거)을 다룹니다.

핸드셰이크 섹션은 Client Hello(지원 버전, 암호 목록, SNI 호스트명, TLS 1.3 key_share 확장), Server Hello(선택된 암호와 key_share), X.509 체인을 통한 인증서 검증, 리플레이 공격 위험이 있는 TLS 1.3 0-RTT 조기 데이터를 단계별로 설명합니다. 프로토콜 협상(h2/http1.1)을 위한 ALPN과 공유 IP에서 가상 호스팅을 위한 SNI, 평문 SNI에 대한 프라이버시 솔루션인 ECH(Encrypted Client Hello)도 다룹니다. 모든 콘텐츠는 서버 처리 없이 클라이언트 사이드에서 제공됩니다.

주요 기능

완전한 TLS 버전 비교: 1.0(폐기), 1.1(폐기), 1.2, 1.3의 주요 차이점
TLS 1.3 암호 스위트 3종 문서화: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305
키 교환 알고리즘 비교: ECDHE(P-256, X25519), DHE, RSA와 순방향 비밀성 분석
단계별 TLS 핸드셰이크 설명: Client Hello, Server Hello, Certificate, 키 교환
리플레이 공격 트레이드오프와 함께 TLS 1.3 0-RTT 조기 데이터 설명
TLS 확장: 가상 호스팅을 위한 SNI, 프로토콜 협상(HTTP/2, HTTP/1.1)을 위한 ALPN
카테고리별 검색 및 필터링: 버전, 암호, 키 교환, 핸드셰이크, 확장
100% 클라이언트 사이드 — 데이터가 서버에 전송되거나 원격 저장되지 않음

자주 묻는 질문

TLS 1.2와 TLS 1.3의 차이는 무엇인가요?

TLS 1.3(2018)은 TLS 1.2(2008) 대비 여러 주요 개선을 제공합니다. 핸드셰이크가 2 라운드 트립에서 1 라운드 트립으로 줄었고, 0-RTT 세션 재개를 지원합니다. 모든 불안전한 알고리즘이 제거되었습니다 — RSA 키 교환, CBC 모드, RC4, SHA-1, 정적 DH가 없습니다. AEAD 암호(AES-GCM, ChaCha20-Poly1305)와 임시 키 교환(ECDHE)만 허용되어 모든 연결에 순방향 비밀성이 보장됩니다.

TLS 1.0과 1.1이 폐기된 이유는?

TLS 1.0과 1.1은 2021년(RFC 8996) 폐기되었습니다. POODLE(SSL 3.0/TLS 1.0의 CBC 패딩 악용), BEAST(TLS 1.0의 CBC 모드 초기화 벡터 공격) 등 잘 알려진 공격에 취약하고 최신 AEAD 암호를 지원하지 않기 때문입니다. 모든 주요 브라우저가 이 버전 지원을 제거했습니다. AEAD 암호를 사용하는 TLS 1.2가 현재 최소 허용 버전입니다.

어떤 TLS 1.3 암호 스위트를 사용해야 하나요?

TLS_AES_128_GCM_SHA256이 가장 널리 배포되어 있으며 권장 기본값입니다. TLS_AES_256_GCM_SHA384는 256비트 암호화가 필요한 환경(정부 규정 준수 등)에 더 큰 키 크기를 제공합니다. TLS_CHACHA20_POLY1305_SHA256은 AES 하드웨어 가속(AES-NI)이 없는 모바일 클라이언트와 ARM 기기에 권장되며, ChaCha20이 소프트웨어 전용 구현에서 더 나은 성능을 달성합니다.

순방향 비밀성이란 무엇이고 왜 중요한가요?

순방향 비밀성(완전 순방향 비밀성)은 서버의 장기 개인 키가 유출되더라도 과거 기록된 트래픽을 복호화할 수 없다는 의미입니다. 각 연결마다 고유한 세션 키를 생성하고 사용 후 폐기하는 임시 키 교환(ECDHE 또는 DHE)으로 달성됩니다. RSA 키 교환은 이 속성이 없어 RSA 개인 키가 나중에 유출되면 이전에 캡처된 모든 트래픽을 복호화할 수 있습니다. TLS 1.3은 임시 키 교환만 허용하여 순방향 비밀성을 의무화합니다.

SNI란 무엇이고 왜 평문으로 전송되나요?

SNI(Server Name Indication)는 Client Hello 메시지에 대상 호스트명을 포함하는 TLS 확장으로, 단일 IP 주소의 서버가 요청된 도메인에 맞는 올바른 인증서를 제시할 수 있게 합니다. Client Hello가 암호화 설정 전에 전송되므로 SNI 호스트명은 네트워크 관찰자에게 노출됩니다. Encrypted Client Hello(ECH)가 해결책으로, DNS에 게시된 공개 키로 SNI를 암호화하여 클라이언트가 어느 사이트에 연결하는지 수동적 관찰을 방지합니다.

TLS 1.3 0-RTT는 어떻게 작동하나요?

0-RTT(제로 라운드 트립 타임)는 이전에 서버에 연결한 적 있는 클라이언트가 이전 세션의 PSK(Pre-Shared Key)를 사용하여 세션 재개 시 첫 번째 메시지에서 암호화된 애플리케이션 데이터를 전송할 수 있게 합니다. 재방문 연결의 핸드셰이크 지연을 완전히 제거합니다. 트레이드오프는 0-RTT 데이터가 리플레이 공격에 취약하다는 것입니다 — 공격자가 0-RTT 메시지를 캡처하여 서버에 재전송할 수 있습니다. 서버는 비멱등 작업에 대해 애플리케이션 계층 리플레이 보호를 구현해야 합니다.

ALPN은 무엇에 사용되나요?

ALPN(Application-Layer Protocol Negotiation)은 TLS 핸드셰이크 중에 클라이언트와 서버가 사용할 애플리케이션 프로토콜(HTTP/2용 h2 또는 HTTP/1.1용 http/1.1)에 합의할 수 있는 TLS 확장입니다. TLS 연결 설정 후 프로토콜 협상이 이루어지면 필요한 추가 라운드 트립을 피할 수 있습니다. ALPN은 HTTP/2에 필수적입니다 — 브라우저는 ALPN을 통해 h2를 성공적으로 협상한 TLS 연결에서만 HTTP/2를 사용합니다.

이 레퍼런스가 보안 감사와 컴플라이언스에 유용한가요?

네. TLS 구성을 PCI DSS(TLS 1.2 이상 필수), NIST SP 800-52(TLS 1.3 및 특정 암호 스위트 권장), 일반 보안 모범 사례에 대해 평가하는 데 필요한 기술적 세부 정보를 제공합니다. 어떤 암호 스위트가 안전한지, 어떤 키 교환 알고리즘이 순방향 비밀성을 제공하는지, 어떤 TLS 버전이 폐기되었는지를 빠르게 확인할 수 있으며, 이는 보안 감사와 컴플라이언스 평가에 핵심적인 정보입니다.