ScholarGate
어시스턴트

TLS 및 보안 채널

전송 계층 보안(TLS)은 대부분의 인터넷 통신을 보호하는 프로토콜로, 인증된 키 교환과 인증된 암호화를 결합하여 두 종단점 간에 기밀성, 무결성이 보호되는 채널을 생성합니다.

PaperMind(으)로 주제 찾기곧 제공Find papers & topics
Tools & resources
슬라이드 다운로드
Learn & explore
동영상곧 제공

Definition

TLS와 같은 보안 채널 프로토콜은 두 당사자 간에 인증된 키 교환을 수행한 후 트래픽의 인증된 암호화를 통해 교환되는 모든 데이터의 기밀성, 무결성 및 인증을 보장하는 세션을 설정합니다.

Scope

이 주제는 TLS를 핵심 예시로 하는 보안 채널 프로토콜을 다룹니다. 여기에는 서버(선택적으로 클라이언트)를 인증하고 세션 키를 설정하는 핸드셰이크, 인증된 암호화, 순방향 비밀성 및 다운그레이드 보호를 제공하는 레코드 계층, 그리고 과거 공격으로부터 얻은 교훈이 포함됩니다. 암호화 구성 요소가 배포된 프로토콜로 어떻게 조립되는지 설명합니다. 인증서 인프라(PKI)와 개별 프리미티브는 관련 주제에서 다루므로 여기서는 제외합니다.

Core questions

  • TLS 핸드셰이크는 어떻게 서버를 인증하고 세션 키에 동의합니까?
  • 레코드 계층은 어떻게 인증된 암호화를 통해 각 메시지를 보호합니까?
  • 순방향 비밀성은 어떻게 달성되며, 기록된 트래픽에 왜 중요합니까?
  • 다운그레이드 및 재협상 공격은 어떻게 방지됩니까?
  • 과거 공격(BEAST, POODLE, Heartbleed)은 프로토콜 및 구현 설계에 대해 무엇을 가르쳐 주었습니까?

Key concepts

  • TLS 핸드셰이크
  • 레코드 계층
  • 인증된 암호화 (AEAD)
  • 임시 키 교환 (ECDHE)
  • 순방향 비밀성
  • 서버 및 클라이언트 인증
  • 다운그레이드 및 재협상 공격
  • 세션 재개
  • 암호 스위트 협상

Key theories

핸드셰이크와 레코드 프로토콜
TLS는 인증서로 신원을 확인하고 세션 키를 유도하는 인증된 키 교환 핸드셰이크와, 해당 키로 애플리케이션 데이터를 암호화하고 인증하는 레코드 계층을 분리하여 인증, 키 합의 및 대량 보호를 깔끔하게 구성합니다.
순방향 비밀성 및 다운그레이드 보호
TLS 1.3은 순방향 비밀성을 위해 임시(타원 곡선) 디피-헬만을 의무화하고, 핸드셰이크 트랜스크립트를 키 스케줄에 바인딩하여 능동적인 공격자가 약한 매개변수로 다운그레이드를 강제하더라도 탐지되지 않게 할 수 없도록 합니다.

Mechanisms

TLS 1.3에서 클라이언트는 키 교환 공유와 지원되는 매개변수를 전송합니다. 서버는 자체 임시 디피-헬만 공유, 인증서, 핸드셰이크 트랜스크립트에 대한 서명으로 응답하며, 양측은 키 유도 함수(HKDF)를 통해 세션 키를 유도합니다. 레코드 계층은 이후 모든 데이터를 AEAD 암호(예: AES-GCM 또는 ChaCha20-Poly1305)로 보호합니다. 트랜스크립트는 변조 또는 다운그레이드를 방지하기 위해 인증되며, 핸드셰이크는 단일 왕복으로 완료되고, 선택적으로 제로 왕복 재개가 가능합니다.

Clinical relevance

TLS는 인터넷 트래픽의 압도적인 대부분을 보호합니다. 웹용 HTTPS, 보안 이메일 전송, API, VPN 및 메시징은 모두 TLS를 통해 실행됩니다. TLS의 정확성은 암호, 결제 및 개인 데이터가 네트워크 공격자로부터 보호되는지 여부를 직접적으로 결정합니다. 결함이 있는 SSL/초기 TLS에서 TLS 1.3으로의 마이그레이션과 이에 수반된 분석은 실제 압력 하에서 프로토콜이 어떻게 발전하는지를 보여주는 모델입니다.

Evidence & guidelines

TLS 1.3은 RFC 8446에 의해 표준화되었으며 권장됩니다. SSL 3.0, TLS 1.0 및 TLS 1.1은 더 이상 사용되지 않습니다(RFC 8996). NIST SP 800-52는 구성 지침을 제공합니다. TLS 1.3은 광범위한 형식 분석을 통해 개발되었으며, BEAST, POODLE 및 구현 결함인 Heartbleed와 같은 초기 공격을 가능하게 했던 기존의 약점(정적 RSA 키 교환, CBC 모드, 재협상)을 제거했습니다.

History

넷스케이프는 1994-1995년에 SSL을 만들었습니다. SSL 3.0은 IETF에 의해 TLS 1.0(1999)으로 재설계되었고 TLS 1.2(2008)를 통해 개선되었습니다. BEAST, CRIME, POODLE, Heartbleed 구현 버그, Logjam, FREAK 등 10년간의 공격은 기존 모드와 다운그레이드 처리의 약점을 드러냈습니다. TLS 1.3(RFC 8446, 2018)은 필수적인 순방향 비밀성, 더 빠른 핸드셰이크, 형식 보안 분석을 포함하는 주요 재설계였습니다.

Key figures

  • Eric Rescorla
  • Hugo Krawczyk
  • Kenny Paterson
  • Taher ElGamal

Related topics

Seminal works

  • rfc8446
  • stallings2017
  • katz2020

Frequently asked questions

SSL과 TLS의 차이점은 무엇입니까?
TLS는 SSL의 후속 기술입니다. SSL(버전 2.0 및 3.0)은 구식이며 안전하지 않습니다. 'SSL'은 구어체 용어로 남아 있지만, 모든 현재 보안 웹 연결은 TLS를 사용하며, TLS 1.3이 최신 버전입니다.
TLS가 악성 웹사이트로부터 저를 보호해 줍니까?
TLS는 인증서에 명시된 서버와 기밀하고 인증된 채널을 가지고 있음을 보장할 뿐입니다. 즉, 해당 도메인과 통신하고 있음을 확인하지만, 해당 도메인이 신뢰할 수 있다는 것을 보장하지는 않습니다. 피싱 사이트는 자체 (유사한) 도메인에 대한 유효한 인증서를 제공할 수 있으므로, TLS는 사이트의 정직성을 보증하지 않습니다.

Methods for this concept

Related concepts