전송 계층 보안

Transport Layer Security

TLS(Transport Layer Security)는 컴퓨터 네트워크를 통해 통신 보안을 제공하도록 설계된 암호화 프로토콜입니다.프로토콜이메일, 인스턴트 메시징, Voice over IP와 같은 응용 프로그램에서 널리 사용되지만 HTTPS 보안에 사용되는 경우가 가장 일반적으로 눈에 띕니다.

TLS 프로토콜은 주로 둘 이상의 통신 컴퓨터 응용 프로그램 간에 인증서 사용과 같은 암호학의 사용을 통해 프라이버시(비밀성), 무결성 및 진정성을 포함한 보안을 제공하는 것을 목표로 합니다.프레젠테이션 계층에서 실행되며 TLS 레코드와 TLS 핸드셰이크 프로토콜이라는 두 개의 계층으로 구성됩니다.

밀접하게 관련된 데이터그램 전송 계층 보안(DTLS)은 데이터그램 기반 응용 프로그램에 보안을 제공하는 통신 프로토콜입니다.기술 문서에서 "(D)TLS"에 대한 참조는 두 버전 모두에 적용될 때 종종 볼 수 있습니다.[1]

TLS는 제안된 IETF(Internet Engineering Task Force) 표준으로 1999년에 처음 정의되었으며 현재 버전은 2018년 8월에 정의된 TLS 1.3입니다.TLS는 Netscape Communications가 HTTPS 프로토콜을 Navigator 웹 브라우저에 추가하기 위해 개발한 현재는 사용되지 않는 SSL(Secure Sockets Layer) 사양(1994, 1995, 1996)을 기반으로 합니다.

묘사

클라이언트-서버 응용프로그램은 TLS 프로토콜을 사용하여 도청변조를 방지하도록 설계된 방식으로 네트워크를 통해 통신합니다.

응용프로그램은 TLS(또는 SSL)를 사용하거나 사용하지 않고 통신할 수 있으므로 클라이언트서버에 TLS 연결을 설정하도록 요청해야 합니다.[2]이를 달성하는 주요 방법 중 하나는 TLS 연결에 다른 포트 번호를 사용하는 것입니다.포트 80은 일반적으로 암호화되지 않은 HTTP 트래픽에 사용되는 반면 포트 443은 암호화된 HTTPS 트래픽에 사용되는 일반 포트입니다.또 다른 메커니즘은 서버에 프로토콜별 STARTTLS 요청을 하여 연결을 TLS로 전환하는 것입니다. 예를 들어 메일 및 뉴스 프로토콜을 사용하는 경우입니다.

클라이언트와 서버가 TLS 사용에 동의하면 핸드셰이크 절차를 사용하여 상태 저장 연결을 협상합니다( § TLS 핸드셰이크 참조).프로토콜은 비대칭 암호와의 핸드셰이크를 사용하여 암호 설정뿐만 아니라 대칭 암호를 사용하여 추가적인 통신이 암호화되는 세션별 공유 키를 설정합니다.이 핸드셰이크 동안 클라이언트와 서버는 연결의 보안을 설정하는 데 사용되는 다양한 매개변수에 동의합니다.

  • 핸드셰이크는 클라이언트가 보안 연결을 요청하는 TLS 지원 서버에 연결하고 클라이언트가 지원되는 암호 모음(암호해시 함수)의 목록을 제시할 때 시작됩니다.
  • 이 목록에서 서버는 지원하는 암호 및 해시 함수를 선택하고 클라이언트에게 결정을 알립니다.
  • 그러면 일반적으로 서버는 디지털 인증서 형태로 신분증을 제공합니다.인증서에는 서버 이름, 인증서의 진위 여부를 보증하는 신뢰할 수 있는 CA(인증 기관) 및 서버의 공용 암호화 키가 들어 있습니다.
  • 클라이언트는 진행하기 전에 인증서의 유효성을 확인합니다.
  • 보안 연결에 사용되는 세션 키를 생성하려면 클라이언트는 다음 중 하나를 수행합니다.
    • 서버의 공개 키로 난수(PreMasterSecret)를 암호화한 후 서버(서버만이 개인 키로 암호를 해독할 수 있어야 함)로 결과를 보냅니다. 그런 다음 두 당사자 모두 난수를 사용하여 세션 중에 데이터의 후속 암호화 및 복호화를 위한 고유한 세션 키를 생성하거나,
    • Diffie를 사용합니다.암호화 복호화를 위한 임의의 고유 세션 를 안전하게 생성하기 위한 헬만 키 교환(또는 그 변형 타원 곡선 DH): 서버의 개인 키가 향후 공개될 경우 현재 세션을 복호화하는 데 사용할 수 없습니다.세션이 제3자에 의해 가로채어 기록되는 경우에도.

그러면 핸드셰이크가 마무리되고 연결이 닫힐 때까지 세션 키로 암호화되고 해독되는 보안 연결이 시작됩니다.위 단계 중 하나라도 실패하면 TLS 핸드셰이크가 실패하고 연결이 생성되지 않습니다.

TLS 및 SSL은 OSI 모델 또는 TCP/IP 모델의 어떤 단일 계층에도 깔끔하게 맞지 않습니다.[4][5]TLS는 "신뢰할 수 있는 전송 프로토콜(예: TCP) 위에" 실행되며,[6]: §1 이는 전송 계층 위에 있음을 의미합니다.일반적으로 프리젠테이션 계층의 기능인 상위 계층에 암호화 기능을 제공합니다.그러나 TLS를 사용하는 응용 프로그램은 TLS 핸드셰이크 시작 및 교환된 인증 인증서의 처리를 적극적으로 제어해야 함에도 불구하고 응용 프로그램은 일반적으로 전송 계층인 것처럼 TLS를 사용합니다.[4][5][6]: §1

TLS로 보안이 설정되면 클라이언트(예: 웹 브라우저)와 서버(예: wikipedia.org ) 간의 연결은 다음 속성을 모두 갖습니다.

  • 전송된 데이터를 암호화하기 위해 대칭알고리즘이 사용되므로 연결은 비공개(또는 기밀성)입니다.이 대칭 암호화에 대한 키는 각 연결마다 고유하게 생성되며 세션 시작 시 협상된 공유 암호를 기반으로 합니다.서버와 클라이언트는 첫 번째 바이트의 데이터가 전송되기 전에 사용할 암호화 알고리즘과 암호화 키에 대한 세부 정보를 협상합니다(아래 참조).공유 비밀의 협상은 보안(협상된 비밀은 도청자가 사용할 수 없으며 자신을 연결 중간에 두는 공격자도 얻을 수 없음)과 신뢰성(어떤 공격자도 탐지되지 않고 협상 중에 통신을 수정할 수 없음)을 모두 보장합니다.
  • 통신 당사자의 신원은 공개암호를 사용하여 인증될 수 있습니다.이 인증확인은 서버에 필요하고 클라이언트에는 선택사항입니다.
  • 전송되는 각 메시지에는 메시지 인증 코드를 사용한 메시지 무결성 검사가 포함되어 전송 중에 데이터가 감지되지 않거나 변경되는 것을 방지할 수 있으므로 연결이 신뢰할 수 있습니다(또는 무결성이 있음).

TLS는 키 교환, 데이터 암호화 및 메시지 무결성 인증을 위한 다양한 방법을 지원합니다.따라서 TLS의 보안 구성에는 구성 가능한 많은 매개 변수가 포함되며, 모든 선택 항목이 위 목록에 설명된 모든 개인 정보 보호 관련 속성을 제공하는 것은 아닙니다(아래 표 § 교환, § 암호 보안 및 § 데이터 무결성 참조).

TLS가 제공하려는 통신 보안 측면을 전복하려는 시도가 있었고, 이러한 보안 위협을 해결하기 위해 프로토콜이 여러 차례 수정되었습니다.웹 브라우저 개발자들은 보안 취약점이 발견된 후 보안 취약점을 방어하기 위해 제품을 반복적으로 수정했습니다(웹 브라우저의 TLS/SSL 지원 이력 참조).

데이터그램 전송 계층 보안

데이터그램 전송 계층 보안, 약칭 DTLS는 데이터그램 기반 응용 프로그램이 도청, 변조 또는 메시지 위조를 방지하도록 설계된[7][8] 방식으로 통신할 수 있도록 함으로써 데이터그램 기반 응용 프로그램에 보안을 제공하는 관련 통신 프로토콜입니다.DTLS 프로토콜은 스트림 지향 TLS(Transport Layer Security) 프로토콜을 기반으로 하며 유사한 보안 보장을 제공하기 위한 것입니다.그러나 TLS와는 달리 사용자 데이터그램 프로토콜(UDP), 데이터그램 혼잡 제어 프로토콜(DCCP), 무선 액세스 포인트 제어 및 프로비저닝(CAPWAP), 스트림 제어 전송 프로토콜(SCTP) 캡슐화 및 보안 실시간 전송 프로토콜(SRTP) 등 대부분의 데이터그램 지향 프로토콜에서 사용할 수 있습니다.

DTLS 프로토콜 데이터그램은 기본 전송인 스트림 프로토콜과 관련된 지연을 겪지 않는 응용 프로그램이기 때문에 패킷 순서 변경, 데이터그램 손실 및 데이터그램 네트워크 패킷의 크기보다 큰 데이터를 처리해야 합니다.DTLS는 TCP가 아닌 UDP 또는 SCTP를 사용하기 때문에 VPN 터널을 만드는 데 사용될 때 [9][10]"TCP 멜트다운 문제"를 방지합니다.

DTLS 버전 1.0의 원래 2006년 릴리스는 독립 실행형 문서가 아니었습니다.TLS 1.1에 대한 일련의 델타로 부여되었습니다.[11] 마찬가지로 2012년 후속 DTLS 릴리스도 TLS 1.2에 대한 델타입니다.TLS 버전과 일치하도록 DTLS 1.2 버전 번호가 부여되었습니다.마지막으로 2022년형 DTLS 1.3은 TLS 1.3에 대한 델타입니다. 이전 두 버전과 마찬가지로, DTLS 1.3은 "TLS 1.3과 동등한 보안 보장"을 제공하기 위한 것으로 순서 보호/재생 불가능성을 제외하고 제공합니다.[12]

Cisco AnyConnect[13] & InterCloud Fabric,[14] OpenConnect,[15] ZScaler 터널,[16] F5 Networks Edge VPN Client [17]및 Citrix Systems NetScaler를 비롯한[18] 많은 VPN 클라이언트가 DTLS를 사용하여 UDP 트래픽을 보호합니다.또한 모든 최신 웹 브라우저는 WebRTC용 DTLS-SRTP를[19] 지원합니다.

역사와 발전

SSL 및 TLS 프로토콜
의전 출판된 상황
이전 버전,이상 유지 관리되지 않음: SSL 1.0 미발행 미발행
이전 버전,이상 유지 관리되지 않음: SSL 2.0 1995 2011년 감가상각(RFC 6176)
이전 버전,이상 유지 관리되지 않음: SSL 3.0 1996 2015년 폐지(RFC 7568)
이전 버전, 더 이상 유지되지 않음:TLS 1.0 1999 2021년에 사용하지 않음 (RFC 8996)[20][21][22]
이전 버전, 더 이상 유지되지 않음:TLS 1.1 2006 2021년에 사용하지 않음 (RFC 8996)[20][21][22]
이전 버전이지만 여전히 유지됨:TLS 1.2 2008 2008년[23][24] 이후 사용중
현재 안정 버전: TLS 1.3 2018 2018년부터[24][25] 사용중

보안 데이터 네트워크 시스템

TLS(Transport Layer Security Protocol)는 다른 여러 기본 네트워크 보안 플랫폼과 함께 1986년 8월에 시작된 국가안보국, 국가표준국, 국방통신국 간의 공동 이니셔티브를 통해 개발되었습니다.그리고 SDNS(Secure Data Network System)[26]라는 특별한 프로젝트를 시작한 12개의 통신 및 컴퓨터 회사.이 프로그램은 1987년 9월 제10회 전국 컴퓨터 보안 회의에서 발표된 광범위한 논문집에 기술되었습니다.혁신적인 연구 프로그램은 공공 및 민간 인터넷의 응용을 위해 구현될 차세대 보안 컴퓨터 통신망과 제품 사양을 설계하는 데 초점을 맞췄습니다.이는 미국 정부의 GOSIP 프로파일과 국제적으로 거대한 ITU-ISO JTC1 인터넷 노력 모두에서 빠르게 부상하고 있는 새로운 OSI 인터넷 표준을 보완하기 위한 것이었습니다.원래 SP4 프로토콜로 알려졌던 이 프로토콜은 TLS로 이름이 바뀌었고 1995년에 국제 표준 ITU-TX.274 ISO/IEC 10736:1995로 출판되었습니다.

안전한 네트워크 프로그래밍

전송 계층 보안을 위한 초기 연구 노력에는 보안 네트워크 프로그래밍(SNP) 응용 프로그램 프로그래밍 인터페이스(API)가 포함되었는데, 이 API는 1993년에 버클리 소켓과 유사한 보안 전송 계층 API를 갖는 접근 방식을 탐구하여 보안 조치를 통해 기존의 네트워크 응용 프로그램을 쉽게 개조할 수 있었습니다.[27]

SSL 1.0, 2.0 및 3.0

Netscape는 원래 SSL 프로토콜을 개발했으며 1995년부터 1998년까지 Netscape Communications의 수석 과학자인 Taher Elgamal은 "SSL의 아버지"로 묘사되었습니다.[28][29][30][31] SSL 버전 1.0은 프로토콜의 심각한 보안 결함 때문에 공개되지 않았습니다.1995년 2월에 출시된 버전 2.0은 보안 및 사용성에 문제가 있음을 빠르게 발견했습니다.메시지 인증과 암호화에 동일한 암호키를 사용했습니다.비밀 접두사가 붙은 MD5 해시 함수를 사용하는 약한 MAC 구조를 가지고 있어 길이 확장 공격에 취약했습니다.또한 중간자 공격이 탐지되지 않을 수 있다는 것을 의미하는 오프닝 악수나 명시적 메시지 클로즈에 대한 보호 기능도 제공하지 않았습니다.또한 SSL 2.0은 단일 서비스와 고정 도메인 인증서를 가정하여 웹 서버에서 널리 사용되는 가상 호스팅 기능과 상충되므로 대부분의 웹 사이트에서 SSL을 사용할 수 없게 되었습니다.

이러한 결함으로 인해 프로토콜을 SSL 버전 3.0으로 완전히 재설계해야 했습니다.[32][30]1996년에 출시되었으며, 폴 코처(Paul Kocher)가 넷스케이프 엔지니어 필 칼튼(Phil Karton), 앨런 프라이어(Alan Freier)와 함께 제작하였으며, 크리스토퍼 앨런(Christopher Allen)과 팀 디어크(Tim Dierks)가 컨센세이션 개발을 참조하여 구현했습니다.SSL/TLS의 최신 버전은 SSL 3.0을 기반으로 합니다.SSL 3.0의 1996년 초안은 RFC 6101의 역사적 문서로서 IETF에 의해 발표되었습니다.

SSL 2.0은 2011년 RFC 6176에 의해 더 이상 사용되지 않습니다.2014년 SSL 3.0은 SSL의 모든 블록 암호에 영향을 미치는 POODLE 공격에 취약한 것으로 확인되었습니다. SSL 3.0에서 지원되는 유일한 비블록 암호인 RC4도 SSL 3.0에서 사용된 것처럼 실제로 손상되었습니다.[33] SSL 3.0은 2015년 6월 RFC 7568에 의해 더 이상 사용되지 않습니다.

TLS 1.0

TLS 1.0은 1999년 1월 SSL 버전 3.0의 업그레이드로 RFC 2246에서 처음 정의되었으며 컨센서스 개발의 Christopher Allen과 Tim Dierks가 작성했습니다.RFC에 명시된 바와 같이, "이 프로토콜과 SSL 3.0의 차이점은 극적인 것은 아니지만 TLS 1.0과 SSL 3.0 사이의 상호 운용성을 방해할 만큼 충분히 중요합니다."팀 디어크는 나중에 이러한 변경과 "SSL"에서 "TLS"로 이름을 바꾼 것은 마이크로소프트의 체면을 구기는 행동이며, 따라서 IETF가 넷스케이프의 프로토콜을 고무로 찍는 것처럼 보이지 않을 것입니다."라고 썼습니다.[34]

PCI 위원회는 2018년 6월 30일 이전에 조직을 TLS 1.0에서 TLS 1.1 이상으로 마이그레이션할 것을 제안했습니다.[35][36]2018년 10월, 애플, 구글, 마이크로소프트, 모질라는 공동으로 2020년 3월에 TLS 1.0과 1.1을 폐지할 것이라고 발표했습니다.[20]TLS 1.0과 1.1은 2021년 3월에 RFC 8996에서 공식적으로 폐지되었습니다.

TLS 1.1

TLS 1.1은 2006년 4월 RFC 4346에서 정의되었습니다.[37]TLS 버전 1.0의 업데이트입니다.이 버전의 중요한 차이점은 다음과 같습니다.

TLS 버전 1.0 및 1.1에 대한 지원은 2020년경 웹 사이트에서 널리 사용되지 않게 되었으며, 24 이전의 파이어폭스 버전과 29 이전의 크롬 기반 브라우저에 대한 액세스를 비활성화했습니다.[39][40][41]

TLS 1.2

TLS 1.2는 2008년 8월 RFC 5246에서 정의되었습니다.[23]이는 이전 TLS 1.1 사양을 기반으로 합니다.주요 차이점은 다음과 같습니다.

  • 의사 난수 함수(PRF)의 MD5SHA-1 조합이 SHA-256으로 대체되었으며, 암호 모음 지정 PRF를 사용할 수 있는 옵션이 추가되었습니다.
  • 완성된 메시지 해시에 포함된 MD5와 SHA-1 조합은 SHA-256으로 대체되었으며, 암호 스위트별 해시 알고리즘을 사용할 수 있는 옵션이 추가되었습니다.그러나 완료된 메시지의 해시 크기는 여전히 96비트 이상이어야 합니다.[23]: §7.4.9
  • 디지털 서명된 요소의 MD5 및 SHA-1 조합은 핸드셰이크 중에 협상된 단일 해시로 대체되었으며, SHA-1은 기본값입니다.
  • 어떤 해시와 서명 알고리즘을 사용할 것인지 지정할 수 있는 클라이언트 및 서버의 기능이 향상되었습니다.
  • 주로 GCM(Galois/Counter Mode) 및 AES(Advanced Encryption Standard) 암호화의 CCM 모드에 사용되는 인증된 암호화 암호에 대한 지원 확대
  • TLS Extensions 정의 및 AES 암호 제품군이 추가되었습니다.[38]

TLS 세션이 SSL(Secure Sockets Layer) 버전 2.0의 사용을 협상하지 않도록 하기 위해 모든 TLS 버전은 2011년 3월 RFC 6176에서 더욱 세분화되었습니다.TLS 1.2가 폐지되는 공식 날짜는 현재 없습니다.

TLS 1.3

TLS 1.3은 2018년 8월 RFC 8446에서 정의되었습니다.[6]이는 이전 TLS 1.2 사양을 기반으로 합니다.TLS 1.2와의 주요 차이점은 다음과 같습니다.[42]

  • 암호 제품군에서[38][6]: §11 키 계약 및 인증 알고리즘 분리
  • 약하고 덜 사용되는 명명된 타원 곡선에 대한 지지대 제거
  • MD5 및 SHA-224 암호화 해시 함수 지원 제거
  • 이전 구성을 사용하는 경우에도 디지털 서명 필요
  • HKDF와 반이중 DH 제안을 통합하는 방법
  • PSK 및 티켓으로 재개 대체
  • 1-RTT 악수 지원 및 0-RTT 초기 지원
  • (EC) 중에 사용 후 삭제 키를 사용하여 완전한 순방향 비밀 유지를 요구합니다.DH키약정
  • 압축, 재협상, 비 AEAD 암호, 비 PFS 키 교환(정적 RSA정적 DH 키 교환 포함), 사용자 지정 DHE 그룹, EC 포인트 형식 협상, Change Cipher Spec 프로토콜, Hello 메시지 UNIX 시간, AEAD 암호에 입력된 길이 필드 AD 등을 포함한 많은 안전하지 않거나 오래된 기능에 대한 지원 중단
  • 역호환성을 위해 SSL 또는 RC4 협상 금지
  • 세션 해시 통합 사용
  • 레코드 계층 버전 번호의 사용을 중지하고 하위 호환성 향상을 위해 번호를 동결합니다.
  • 일부 보안 관련 알고리즘 세부 정보를 규격 부록으로 이동하고 ClientKeyShare를 부록으로 강등
  • Poly1305 메시지 인증 코드로 ChaCha20 스트림 암호 추가
  • Ed25519Ed448 디지털 서명 알고리즘 추가
  • x25519x448 키 교환 프로토콜 추가
  • 여러 OCSP 응답 전송 지원 추가
  • 서버 Hello 뒤의 모든 핸드셰이크 메시지 암호화

모질라가 개발하고 웹 브라우저 파이어폭스가 사용하는 암호학 라이브러리인 네트워크 보안 서비스(NSS)는 2017년 2월에 기본적으로 TLS 1.3을 활성화했습니다.[43]TLS 1.3 지원은 이후에 파이어폭스 52.0에 추가되었지만 자동으로 활성화되지[44] 않은 소수의 사용자에 대한 호환성 문제로 인해 2017년 3월에 출시되었습니다.TLS 1.3은 2018년 5월 파이어폭스 60.0 출시와 함께 기본적으로 활성화되었습니다.[45]

구글 크롬은 2017년 TLS 1.3을 짧은 시간 동안 기본 버전으로 설정했습니다.그런 다음 Blue Coat 프록시와 같은 호환되지 않는 미들박스로 인해 기본값으로 제거했습니다.[46]

TLS의 새로운 버전에 대한 내성은 프로토콜 골화였습니다. 미들박스는 프로토콜의 버전 매개변수를 골화했습니다.따라서 버전 1.3은 버전 1.2의 와이어 이미지를 모방합니다.이러한 변경 사항은 설계 프로세스에서 매우 늦게 발생했으며 브라우저 배포 중에 발견되었습니다.[47]이러한 불관용성의 발견으로 가장 높은 일치 버전을 선택했던 이전 버전 협상 전략도 실행 불가능한 수준의 골화로 인해 포기하게 되었습니다.[48]한 프로토콜 참가자가 인식되지 않지만 실제로 존재하는 확장을 허용하고 골화에 저항하기 위해 존재하지 않는 확장을 지원한다고 주장하는 'Greasing' 확장 지점은 원래 TLS를 위해 설계되었지만 그 이후 다른 곳에서 채택되었습니다.[49]

2017년 싱가포르에서 열린 IETF 100 해커톤에서 TLS 그룹은 TLS 1.3을 사용하기 위해 오픈 소스 응용 프로그램을 적용하는 작업을 했습니다.[50][51]TLS 그룹은 cyberstorm.mu 팀을 통해 일본, 영국, 모리셔스 출신으로 구성되었습니다.이 작업은 런던의 IETF 101 해커톤과 [52]몬트리올의 IETF 102 해커톤에서도 계속되었습니다.[53]

wolfSSL은 2017년 5월에 출시된 버전 3.11.1에서 TLS 1.3을 사용할 수 있게 되었습니다.[54]첫 번째 상용 TLS 1.3 구현으로, wolfSSL 3.11.1은 Draft 18을 지원하였으며, 현재는 최종 [55]버전인 Draft 28과 이전 버전을 지원하고 있습니다.TLS 1.2와 1.3의 성능 차이에 대한 블로그가 잇따라 게재되었습니다.[56]

에서 인기있는 OpenSSL 프로젝트는 TLS 1.3을 지원하는 라이브러리 버전 1.1.1을 공개했습니다.[57]

TLS 1.3 지원은 윈도우 11윈도우 서버 2022를 사용하는 채널에 처음 추가되었습니다.[58]

엔터프라이즈 운송 보안

Electronic Frontier Foundation은 TLS 1.3을 칭찬하고 TLS 1.3에서 중요한 보안 조치를 의도적으로 비활성화하는 변종 ETS(Enterprise Transport Security)에 대해 우려를 나타냈습니다.[59]원래 eTLS(Enterprise TLS)라고 불렸던 ETS는 'ETSI TS103523-3', "중간박스 보안 프로토콜, 파트 3: 엔터프라이즈 전송 보안'으로 알려진 공개된 표준입니다.이는 은행 시스템과 같은 독점 네트워크 내에서 전적으로 사용하기 위한 것입니다.ETS는 고유 네트워크에 연결된 타사 조직이 네트워크 트래픽을 모니터링하여 멀웨어를 탐지하고 감사를 수행하기 쉽도록 개인 키를 사용할 수 있도록 전방 보안을 지원하지 않습니다.[60][61]장점이 있다고 주장했음에도 불구하고, EFF는 전방 기밀이 손실되면 트래픽을 분석할 수 있는 더 나은 방법이 있다고 말하면서 데이터가 더 쉽게 노출될 수 있다고 경고했습니다.

디지털 인증서

디지털 인증서가 있는 웹 사이트의 예

디지털 인증서는 인증서의 명명된 주체별로 공개 키의 소유권을 인증하고 해당 키의 예상되는 특정 용도를 나타냅니다.이를 통해 다른 사람(신속 당사자)은 서명 또는 인증된 공개 키에 해당하는 개인 키에 의한 주장에 의존할 수 있습니다.키 저장소 및 신뢰 저장소는 .pem, .crt, .pfx 및 .jk와 같은 다양한 형식일 수 있습니다.

인증기관

TLS는 일반적으로 신뢰할 수 있는 타사 인증 기관 집합을 사용하여 인증서의 신뢰성을 설정합니다.신뢰는 일반적으로 사용자 에이전트 소프트웨어와 함께 배포된 인증서 목록에 고정되며 의존하는 당사자가 수정할 수 있습니다.[62]

액티브 TLS 인증서를 모니터링하는 넷크래프트에 따르면 시장을 선도하는 인증기관(CA)은 조사 초기부터 시만텍(또는 인증 서비스 사업부가 시만텍에 인수되기 전 VeriSign)이었습니다.2015년 기준, Symantec은 전체 인증서의 3분의 1에 불과하며, Netcraft가 집계한 바에 따르면 가장 바쁜 100만 개의 웹 사이트에서 사용하는 유효한 인증서의 44%를 차지했습니다.[63]2017년 시만텍은 TLS/SSL 사업을 디지서트에 매각했습니다.[64]업데이트된 보고서를 통해 2019년 5월 이후 시장점유율 기준 3대 인증기관은 아이덴트러스트, 디지서트, 섹티고로 나타났습니다.[65]

X.509 인증서를 선택한 결과 인증서와 소유자 간의 관계를 확인하고 인증서의 유효성을 생성, 서명 및 관리하기 위해 인증서 당국과 공개인프라가 필요합니다.신뢰 네트워크를 통해 신원을 확인하는 것보다 더 편리할 수도 있지만, 2013년 대규모 보안 감시 공개를 통해 인증 기관이 보안 측면에서 약점이라는 사실이 더욱 널리 알려짐에 따라 인증 기관이 협조(또는 손상)할 경우 중간자 공격(MITM)을 허용할 수 있게 되었습니다.[66][67]

알고리즘

키교환 또는 키약정

클라이언트와 서버가 TLS로 보호되는 정보를 교환하기 전에 데이터를 암호화할 때 사용할 암호 키와 암호를 안전하게 교환하거나 동의해야 합니다( § 암호 참조).키 교환/합의에 사용되는 방법 중에는 RSA(TLS 핸드셰이크 프로토콜에서 TLS_RSA로 표시됨)로 생성된 공개 키와 개인 키, Diffie-헬맨(TLS_DH), 덧없는 디피-헬만(TLS_DHE), 타원 곡선 디피-헬만(TLS_ECDH), 덧없는 타원 곡선 디피(Diffie-헬먼(TLS_ECDHE), 익명의 디피-Hellman(TLS_DH_anon),[23] 사전 공유 키(TLS_PSK)[68]보안 원격 암호(TLS_SRP).[69]

TLS_DH_anon 및 TLS_ECDH_anon 키 합의 방법은 서버 또는 사용자를 인증하지 않으므로 중간자 공격에 취약하기 때문에 거의 사용되지 않습니다.TLS_DHE 및 TLS_ECDHE만 순방향 비밀을 제공합니다.

교환/약정 시 사용되는 공개 키 인증서는 교환 시 사용되는 공개/비공개 암호 키의 크기도 다양하며, 따라서 제공되는 보안의 견고성도 다릅니다.2013년 7월, 구글은 암호화 강도가 키 크기와 직접적인 관련이 있기 때문에 사용자에게 제공하는 TLS 암호화의 보안을 높이기 위해 1024비트 공개 키를 더 이상 사용하지 않고 대신 2048비트 키로 전환할 것이라고 발표했습니다.[70][71]

키 교환/약정 및 인증
알고리즘. SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 상황
RSA 네. 네. 네. 네. 네. 아니요. RFC에서 TLS 1.2에 대해 정의됨
DH-RSA 아니요. 네. 네. 네. 네. 아니요.
DHE-RSA(전방비밀) 아니요. 네. 네. 네. 네. 네.
ECDH-RSA 아니요. 아니요. 네. 네. 네. 아니요.
ECDHE-RSA(전방비밀) 아니요. 아니요. 네. 네. 네. 네.
DH-DSS 아니요. 네. 네. 네. 네. 아니요.
DHE-DSS(전방비밀) 아니요. 네. 네. 네. 네. 아니요[72]
ECDH-ECDSA 아니요. 아니요. 네. 네. 네. 아니요.
ECDHE-ECDSA(전방비밀) 아니요. 아니요. 네. 네. 네. 네.
ECDH-EdDSA 아니요. 아니요. 네. 네. 네. 아니요.
ECDHE-EdDSA(순방향 기밀)[73] 아니요. 아니요. 네. 네. 네. 네.
PSK 아니요. 아니요. 네. 네. 네. 네.
PSK-RSA 아니요. 아니요. 네. 네. 네. 아니요.
DHE-PSK(순방향 기밀) 아니요. 아니요. 네. 네. 네. 네.
ECDHE-PSK(전방비밀) 아니요. 아니요. 네. 네. 네. 네.
SRP 아니요. 아니요. 네. 네. 네. 아니요.
SRP-DSS 아니요. 아니요. 네. 네. 네. 아니요.
SRP-RSA 아니요. 아니요. 네. 네. 네. 아니요.
케르베로스 아니요. 아니요. 네. 네. 네. ?
DH-ANON(불안정) 아니요. 네. 네. 네. 네. 아니요.
ECDH-ANON(보안되지 않음) 아니요. 아니요. 네. 네. 네. 아니요.
GOSTR 34.10-2012[74] 아니요. 아니요. 아니요. 아니요. 네. 네. RFC 9189, 9367에서 TLS 1.2 및 TLS 1.3에 대해 정의되었습니다.

암호

공개적으로 알려진 실현 가능한 공격에 대한 암호 보안
암호 프로토콜 버전 상황
유형 알고리즘. 공칭 강도(비트) SSL 2.0 SSL 3.0[n 1][n 2][n 3][n 4] TLS 1.0[n 1][n 3] TLS 1.1[n 1] TLS 1.2[n 1] TLS 1.3
블록 암호
와 함께
작동방식
AES GCM[75][n5] 256, 128 시큐어 시큐어 RFC에서 TLS 1.2에 대해 정의됨
AES CCM[76][n5] 시큐어 시큐어
AES CBC[n6] 불안전한 완화 여부에 따라 다름 완화 여부에 따라 다름 완화 여부에 따라 다름
동백 GCM[77][n5] 256, 128 시큐어
동백 CBC[78][n6] 불안전한 완화 여부에 따라 다름 완화 여부에 따라 다름 완화 여부에 따라 다름
아리아 GCM[79][n5] 256, 128 시큐어
아리아 CBC[79][n6] 완화 여부에 따라 다름 완화 여부에 따라 다름 완화 여부에 따라 다름
SEED CBC[80][n6] 128 불안전한 완화 여부에 따라 다름 완화 여부에 따라 다름 완화 여부에 따라 다름
3DESEDE CBC[n6][n7] 112[n 8] 불안전한 불안전한 불안전한 불안전한 불안전한
GOSTR 34.12-2015 마그마 CTR[74][n7] 256 완화 여부에 따라 다름 완화 여부에 따라 다름 완화 여부에 따라 다름 RFC 4357, 9189에 정의됨
GOSTR 34.12-2015 Kuznyechik CTR[74] 256 시큐어 RFC 9189에 정의되어 있음
GOSTR 34.12-2015 마그마 MGM[74][n5] 256 시큐어 RFC 9367에 정의되어 있음
GOSTR 34.12-2015 Kuznyechik MGM[74][n5] 256 시큐어 RFC 9367에 정의되어 있음
아이디어 CBC[n6][n7][n9] 128 불안전한 불안전한 불안전한 불안전한 TLS 1.2에서 제거됨
DES CBC[n6][n7][n9] 056 불안전한 불안전한 불안전한 불안전한
040[n 10] 불안전한 불안전한 불안전한 TLS 1.1 이상에서는 금지됨
RC2 CBC[n6][n7] 040[n 10] 불안전한 불안전한 불안전한
스트림 암호 차차20-폴리1305[85][n 5] 256 시큐어 시큐어 RFC에서 TLS 1.2에 대해 정의됨
RC4[n11] 128 불안전한 불안전한 불안전한 불안전한 불안전한 RFC 7465에 의해 TLS의 모든 버전에서 금지됨
040[n 10] 불안전한 불안전한 불안전한
없음. Null[n 12] 불안전한 불안전한 불안전한 불안전한 불안전한 RFC에서 TLS 1.2에 대해 정의됨
메모들
  1. ^ a b c d RFC 5746은 재협상 결함을 수정하기 위해 구현되어야 하며 그렇지 않으면 이 프로토콜이 손상될 수 있습니다.
  2. ^ 라이브러리가 RFC 5746에 나열된 수정사항을 구현하는 경우 이는 TLS와 달리 IETF는 변경할 수 없는 SSL 3.0 규격을 위반합니다.대부분의 최신 라이브러리는 수정을 구현하고 이것이 야기하는 위반을 무시합니다.
  3. ^ a b 비스트 공격은 클라이언트 및/또는 서버에 의해 완화되지 않는 한 SSL 3.0 및 TLS 1.0에서 사용되는 모든 블록 암호(CBC 암호)를 파괴합니다.§ 웹 브라우저를 참조하십시오.
  4. ^ POODLE 공격은 클라이언트 및/또는 서버에 의해 완화되지 않는 한 SSL 3.0에서 사용되는 모든 블록 암호(CBC 암호)가 끊어집니다.§ 웹 브라우저를 참조하십시오.
  5. ^ a b c d e f g AED 암호(예: GCMCCM)는 TLS 1.2 이상에서만 사용할 수 있습니다.
  6. ^ a b c d e f g h CBC 암호는 타이밍 사이드 채널을 제거하기 위해 라이브러리를 주의 깊게 작성하지 않으면 럭키 서틴 공격으로 공격을 받을 수 있습니다.
  7. ^ a b c d e Sweet32 공격으로 블록 크기가 64비트인 블록 암호가 깨집니다.[81]
  8. ^ 3DES의 키 길이는 168비트이지만 3DES의 유효 보안 강도는 112비트에 불과해 [82]권장 최소값인 128비트보다 낮습니다.[83]
  9. ^ a b IDEA와 DES는 TLS 1.2에서 제거되었습니다.[84]
  10. ^ a b c 40비트 강도 암호 제품군은 특정 강력한 암호화 알고리즘을 포함하는 암호화 소프트웨어를 내보내는 것을 금지하는 미국 규정을 준수하기 위해 의도적으로 키 길이를 줄여 설계되었습니다(미국에서 암호화 내보내기 참조).TLS 1.1 이상에서는 이러한 취약한 제품군을 사용할 수 없습니다.
  11. ^ RFC 7465에서는 모든 버전의 TLS에서 RC4의 사용이 금지되어 있습니다(RC4 공격은 SSL/TLS에서 사용되는 RC4를 약화시키거나 파괴하기 때문입니다).
  12. ^ 인증만 가능하고 암호화는 없습니다.

데이터 무결성

MAC(Message Authentication Code)는 데이터 무결성을 위해 사용됩니다.HMAC는 블록 암호의 CBC 모드에 사용됩니다.GCMCCM 모드와 같은 AEAD(Authenticated Encryption)는 AEAD 통합 MAC을 사용하고 HMAC를 사용하지 않습니다.[6]: §8.4 HMAC 기반 PRF 또는 HKDF는 TLS 핸드셰이크에 사용됩니다.

데이터 무결성
알고리즘. SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 상황
HMAC-MD5 네. 네. 네. 네. 네. 아니요. RFC에서 TLS 1.2에 대해 정의됨
HMAC-SHA1 아니요. 네. 네. 네. 네. 아니요.
HMAC-SHA256/384 아니요. 아니요. 아니요. 아니요. 네. 아니요.
AEAD 아니요. 아니요. 아니요. 아니요. 네. 네.
GOST 28147-89 IMIT[74] 아니요. 아니요. 아니요. 아니요. 네. 아니요. RFC 9189에서 TLS 1.2에 대해 정의되었습니다.
GOSTR 34.12-2015 AEAD[74] 아니요. 아니요. 아니요. 아니요. 아니요. 네. RFC 9367에서 TLS 1.3에 대해 정의되었습니다.

응용프로그램 및 채택

응용 프로그램 설계에서 TLS는 일반적으로 전송 계층 프로토콜 위에 구현되며 HTTP, FTP, SMTP, NNTP XMPP와 같은 프로토콜의 모든 프로토콜 관련 데이터를 암호화합니다.

역사적으로 TLS는 전송 제어 프로토콜(TCP)과 같은 신뢰성 있는 전송 프로토콜과 함께 주로 사용되어 왔습니다.그러나, 그것은 사용자 데이터그램 프로토콜(UDP) 및 데이터그램 혼잡 제어 프로토콜(DCCP)과 같은 데이터그램 지향 전송 프로토콜들로도 구현되어 왔으며, 그 사용은 데이터그램 전송 계층 보안(DTLS)이라는 용어를 사용하여 독립적으로 표준화되었습니다.

웹사이트

TLS의 주된 용도는 HTTP 프로토콜로 인코딩된 웹 사이트와 웹 브라우저 간의 월드 와이드트래픽을 보호하는 것입니다.HTTP 트래픽을 보호하기 위해 TLS를 사용하는 것이 HTTPS 프로토콜을 구성합니다.[86]

웹사이트 프로토콜 지원 (2022년 5월)
의전
버전
웹사이트
버팀목이[87]
보안[87][88]
이전 버전,이상 유지 관리되지 않음: SSL 2.0 0.3% 불안전한
이전 버전,이상 유지 관리되지 않음: SSL 3.0 2.5% 불안전한[89]
이전 버전, 더 이상 유지되지 않음:TLS 1.0 37.1% 감가[20][21][22] 상각됨
이전 버전, 더 이상 유지되지 않음:TLS 1.1 40.6% 감가[20][21][22] 상각됨
이전 버전이지만 여전히 유지됨:TLS 1.2 99.7% 암호화[n 1] 및 클라이언트 완화에[n 2] 따라 다름
현재 안정 버전: TLS 1.3 54.2% 시큐어
메모들
  1. ^ 위의 § 암호 표 참조
  2. ^ § 웹 브라우저 및 § TLS/SSL에 대한 공격 섹션 참조

웹 브라우저

2016년 4월 현재 모든 주요 웹 브라우저의 최신 버전은 TLS 1.0, 1.1 및 1.2를 지원하며 기본적으로 활성화되어 있습니다.그러나 모든 지원되는 Microsoft 운영 체제가 IE의 최신 버전을 지원하는 것은 아닙니다.또한 현재 많은 마이크로소프트 운영 체제에서 여러 버전의 IE를 지원하고 있지만, 이는 마이크로소프트의 Internet Explorer 지원 라이프사이클 정책 FAQ에 따라 변경되었습니다. "2016년 1월 12일부터,지원되는 운영 체제에서 사용 가능한 최신 버전의 Internet Explorer(인터넷 익스플로러)만 기술 지원 및 보안 업데이트를 받을 수 있습니다."그런 다음 페이지에는 각 운영 체제에 대해 해당 날짜에 지원되는 IE의 최신 버전이 나열됩니다.다음 중요한 날짜는 운영 체제가 수명이 다한 시점이 될 것입니다.2022년 6월 15일 이후, 인터넷 익스플로러 11은 마이크로소프트의 모던 라이프사이클 정책을 따르는 윈도우 10 에디션에 대한 지원을 중단했습니다.[90][91]

알려진 공격에 대한 완화는 아직 충분하지 않습니다.

  • POODLE 공격에 대한 완화: 일부 브라우저는 이미 SSL 3.0으로의 폴백을 방지하지만, 이 완화는 클라이언트뿐만 아니라 서버에서도 지원되어야 합니다.SSL 3.0 자체를 비활성화하려면 "Anti-POODLE 레코드 분할"을 구현하거나 SSL 3.0에서 CBC 암호를 거부해야 합니다.
    • Google Chrome: complete(버전 33부터 TLS_FALLBACK_SCSV 구현, 버전 39부터 SSL 3.0으로의 폴백 사용 안 함, 버전 40부터 SSL 3.0 자체가 기본적으로 사용 안 함).버전 44 이후로 SSL 3.0 자체의 지원이 중단되었습니다.)
    • Mozilla Firefox: complete(버전 39 이후 SSL 3.0 자체 지원이 중단됨).SSL 3.0 자체는 기본적으로 사용할 수 없으며 버전 34에서는 TLS_FALLBACK_SCSV가 버전 35에서는 구현되므로 SSL 3.0으로의 폴백이 사용할 수 없습니다.ESR에서는 SSL 3.0 자체가 기본적으로 사용되지 않도록 설정되어 있으며 ESR 31.3.0 이후 TLS_FALLBACK_SCSV가 구현됩니다.)
    • Internet Explorer: 부분(버전 11에서만 SSL 3.0이 2015년 4월부터 기본적으로 비활성화됨)버전 10 이상은 여전히 POODLE에 취약합니다.)
    • Opera: complete (TLS_FALLBACK_SCSV 버전 20부터 구현, 클라이언트 측 구현만으로 효과적인 "Anti-POODLE 레코드 분할" 버전 25부터 구현, SSL 3.0 자체는 버전 27부터 기본적으로 비활성화됩니다.버전 31 이후로 SSL 3.0 자체에 대한 지원이 중단됩니다.)
    • Safari: complete(OS X 10.8 이상 및 iOS 8에서만 SSL 3.0으로 폴백하는 동안 CBC 암호가 거부되지만 RC4를 사용하는 것이 권장되지 않습니다.)OS X 10.11 이상과 iOS 9에서는 SSL 3.0 자체의 지원이 중단되었습니다.)
  • RC4 공격에 대한 완화:
    • Google Chrome은 버전 43 이후 폴백을 제외하고 RC4를 비활성화했습니다. RC4는 Chrome 48 이후로 비활성화되었습니다.
    • 파이어폭스는 버전 36 이후 폴백을 제외하고는 RC4를 사용하지 않도록 설정했습니다.파이어폭스 44는 기본적으로 RC4를 사용하지 않도록 설정했습니다.
    • 버전 30 이후의 폴백을 제외하고 Opera는 RC4를 비활성화했습니다. Opera 35 이후로는 RC4가 비활성화되었습니다.
    • Windows 7/Server 2008 R2 및 Windows 8/Server 2012용 Internet Explorer는 RC4 우선 순위를 가장 낮게 설정했으며 레지스트리 설정을 통한 폴백을 제외하고는 RC4를 사용하지 않도록 설정할 수도 있습니다.Windows Phone 8.1용 Internet Explorer 11 모바일 11은 다른 활성화된 알고리즘이 작동하지 않는 경우 폴백을 제외하고 RC4를 비활성화합니다.Edge와 IE 11은 2016년 8월 RC4를 완전히 비활성화합니다.
  • FREAK 공격에 대한 완화:
    • Android 4.0 이상에 포함된 Android Browser는 FREK 공격에 여전히 취약합니다.
    • 인터넷 익스플로러 11 모바일은 여전히 프리크 공격에 취약합니다.
    • Google Chrome, Internet Explorer(데스크탑), Safari(데스크탑 및 모바일), Opera(모바일)에는 FREK 완화 기능이 있습니다.
    • 모든 플랫폼의 Mozilla Firefox와 Windows의 Google Chrome은 FREK의 영향을 받지 않았습니다.

라이브러리

대부분의 SSL 및 TLS 프로그래밍 라이브러리는 무료 오픈 소스 소프트웨어입니다.

  • Chrome/Chromium 및 Android용 OpenSSL 및 기타 Google 애플리케이션의 일부인 BoringSSL.
  • C++로 작성된 BSD 라이선스 암호 라이브러리인 Botan.
  • BSAFE Micro Edition Suite: FIPS 인증 암호 모듈을 사용하여 C로 작성된 TLS의 멀티 플랫폼 구현
  • BSAFE SSL-J: FIPS 인증 암호 모듈을 사용하여 전용 API와 JSSE API를 모두 제공하는 TLS 라이브러리
  • cryptlib: 휴대용 오픈 소스 암호 라이브러리(TLS/SSL 구현 포함)
  • 델파이 프로그래머들은 OpenSSL을 활용하는 Indy 또는 현재 TLS 1.3을 지원하는 ICS라는 라이브러리를 사용할 수 있습니다.
  • GnuTLS: 무료 구현 (LGPL 라이선스)
  • Java Secure Socket Extension (JSSE): Java API 및 공급자 구현 (SunJSSE로 명명됨)[92]
  • LibreSSL: OpenBSD 프로젝트에 의한 OpenSSL의 한 갈래.
  • MatrixSSL: 이중 라이센스 구현
  • Mbed TLS(이전 PolarSSL): 내장형 장치를 위한 소형 SSL 라이브러리 구현으로, 사용 편의성을 위해 설계되었습니다.
  • 네트워크 보안 서비스: FIPS 140 검증된 오픈 소스 라이브러리
  • OpenSSL: 무료 구현(일부 확장이 있는 BSD 라이선스)
  • 채널: SSL 및 TLS Microsoft Windows를 패키지의 일부로 구현한 것입니다.
  • 보안 전송: OS XiOS에서 패키지의 일부로 사용되는 SSL 및 TLS의 구현.
  • wolfSSL (이전 CyaSSL) : 속도와 크기에 중점을 둔 임베디드 SSL/TLS 라이브러리

컴퓨터통신 보안[93] 관한 2012 ACM 컨퍼런스에서 발표된 논문에 따르면 많은 애플리케이션이 이러한 SSL 라이브러리 중 일부를 잘못 사용하여 취약점이 발생했습니다.저자들에 의하면:

"대부분의 이러한 취약성의 근본 원인은 기본 SSL 라이브러리에 대한 API의 끔찍한 설계 때문입니다.이러한 API는 기밀성 및 인증과 같은 네트워크 터널의 높은 수준의 보안 속성을 표현하는 대신 애플리케이션 개발자에게 SSL 프로토콜의 낮은 수준의 세부 정보를 노출합니다.그 결과 개발자들은 종종 SSL API를 잘못 사용하여 매니폴드 매개 변수, 옵션, 부작용 및 반환 값을 잘못 이해하고 오해하게 됩니다."

기타용도

SMTP(Simple Mail Transfer Protocol)도 TLS로 보호할 수 있습니다.이러한 응용 프로그램은 공개 인증서를 사용하여 엔드포인트의 ID를 확인합니다.

TLS를 사용하여 전체 네트워크 스택을 터널링하여 VPN을 생성할 수도 있습니다. 이는 OpenVPN 및 OpenConnect의 경우와 같습니다.많은 공급업체가 TLS의 암호화 및 인증 기능을 승인과 결합했습니다.또한 1990년대 후반부터 클라이언트/서버 응용 프로그램을 지원하기 위해 웹 브라우저 외부에서 클라이언트 기술을 개발하는 데 상당한 발전이 있었습니다.기존의 IPsec VPN 기술과 비교할 때 TLS는 방화벽 및 NAT 통과에 내재된 몇 가지 이점을 가지고 있어 대규모 원격 액세스 인구에 대해 보다 쉽게 관리할 수 있습니다.

TLS는 SIP(Session Initiation Protocol) 애플리케이션 시그널링을 보호하기 위한 표준 방법이기도 합니다.TLS는 VoIP 및 기타 SIP 기반 응용 프로그램과 연관된 SIP 신호 전달의 인증 및 암호화를 제공하는 데 사용될 수 있습니다.[94]

보안.

TLS/SSL에 대한 공격

TLS/SSL에 대한 중요한 공격이 아래에 나열되어 있습니다.

2015년 2월, IETF는 TLS/SSL에 대한 알려진 다양한 공격을 요약한 정보 RFC를[95] 발표했습니다.

재협상 공격

재협상 절차의 취약성은 2009년 8월에 발견되었으며 SSL 3.0 및 모든 현재 버전의 TLS에 대한 평문 주입 공격을 초래할 수 있습니다.[96]예를 들어 https 연결을 가로챌 수 있는 공격자가 클라이언트가 웹 서버와 나눈 대화의 시작 부분에 자신의 요청을 연결할 수 있습니다.공격자는 클라이언트와 서버 간 통신을 실제로 해독할 수 없으므로 일반적인 중간자 공격과는 다릅니다.단기 수정은 웹 서버가 재협상 허용을 중지하는 것이며, 일반적으로 클라이언트 인증서 인증확인을 사용하지 않는 한 다른 변경사항은 필요하지 않습니다.취약성을 해결하기 위해 TLS에 대한 재협상 표시 확장이 제안되었습니다.클라이언트와 서버가 재협상 악수 시 이전 악수에 대한 정보를 포함하고 확인해야 합니다.[97]이 확장은 제안된 표준이 되었고 RFC 5746이라는 번호를 부여 받았습니다.RFC는 여러 라이브러리에 의해 구현되었습니다.[98][99][100]

다운그레이드 공격: FREK 공격과 로그잼 공격

프로토콜 다운그레이드 공격(버전 롤백 공격이라고도 함)은 웹 서버가 오랫동안 안전하지 않은 상태로 폐기된 이전 버전의 TLS(예: SSLv2)와 연결을 협상하도록 속입니다.

False Start[101](Google Chrome에[102] 의해 채택 및 활성화됨) 또는 Snap Start와 같은 원래 프로토콜에 대한 이전 수정은 제한된 TLS 프로토콜 다운그레이드 공격을[103] 도입하거나 클라이언트가 서버로 전송한 암호 모음 목록에 대한 수정을 허용한 것으로 알려졌습니다.이를 통해 공격자는 더 약한 대칭 암호 알고리즘 또는 더 약한 키 교환을 사용하도록 협상된 암호 모음을 다운그레이드하려고 시도하여 암호 모음 선택에 영향을 미치는 데 성공할 수 있습니다.[104]2012년 컴퓨터통신 보안에 관한 ACM 컨퍼런스에서 발표된 논문에 따르면 False Start 확장이 위험에 처해 있음을 보여줍니다. 특정 상황에서는 공격자가 오프라인에서 암호화 키를 복구하고 암호화된 데이터에 액세스할 수 있습니다.[105]

암호화 다운그레이드 공격은 서버와 클라이언트가 암호학적으로 취약한 키를 사용하여 연결을 협상하도록 할 수 있습니다.2014년에는 기본 안드로이드 브라우저인 OpenSSL 스택과 일부 사파리 브라우저에 영향을 미치는 중간자 공격이 발견되었습니다.[106]이 공격에는 암호학적으로 취약한 512비트 암호화 키를 사용하여 서버가 TLS 연결을 협상하도록 속이는 것이 포함되었습니다.

Logjam(로그잼)은 2015년 5월에 발견된 보안 취약점으로, 기존의 "export-grade" 512비트 Diffie를 사용할 수 있는 옵션을 이용합니다.1990년대로 거슬러 올라가는 헬맨 그룹들.[107]취약한 서버를 암호학적으로 취약한 512비트 Diffie로 다운그레이드합니다.헬맨 그룹.공격자는 Diffie를 사용하여 클라이언트와 서버가 결정하는 키를 추론할 수 있습니다.헬맨교환.

프로토콜간 공격: 익사

DULL 공격은 최신 프로토콜을 사용하는 연결에 대한 공격을 활용하기 위해 오래되고 안전하지 않은 SSLv2 프로토콜을 지원하는 서버를 공격하는 공격입니다.[108][109]DOWN은 특정 구현 오류가 아닌 사용되는 프로토콜 및 서버 구성의 취약성을 이용합니다.2016년 3월, 디운에 대한 전체 세부 사항이 이 악용을 위한 패치와 함께 발표되었습니다.당시 가장 인기 있는 100만 개 이상의 웹사이트 중 81,000개 이상이 익사 공격에 취약한 TLS 보호 웹사이트 중 하나였습니다.[109]

비스트 어택

2011년 9월 23일, 연구원 Thai Duong과 Juliano Rizzo는 자바 애플릿을 사용하여, TLS 1.0의 오래된 CBC(암호 블록 체인) 취약성에 대해 동일한 오리진 정책 제약을 위반하는 BEAST(브라우저 익스플로이트 어게인스트 SSL/TLS)[110]라는 개념 증명을 시연했습니다.[111][112] 2개의 연속적인 암호문 블록 C0, C1을 관찰하는 공격자는 다음을 테스트할 수 있습니다.평문 블록 P1은 다음 평문 블록 P2 = x ⊕ C0 ⊕ C1을 선택하면 x와 같으며, CBC 연산에 따라 C2 = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x)이며, 이는 x = P1인 경우 C1과 같습니다.취약성에 대한 실제적인 공격은 이전에 입증되지 않았으며, 2002년 필립 로가웨이[113] 의해 처음 발견되었습니다.이 공격의 취약점은 2006년 TLS 1.1로 수정되었지만, TLS 1.1은 이번 공격 시연 이전에는 널리 채택되지 않았습니다.

스트림 암호로서의 RC4는 비스트 공격에 영향을 받지 않습니다.따라서 서버측의 비스트 공격을 완화하기 위한 방법으로 RC4를 많이 사용하였습니다.하지만, 2013년에 연구원들은 RC4에서 더 많은 약점을 발견했습니다.그 후 서버 측에서 RC4를 활성화하는 것은 더 이상 권장되지 않습니다.[114]

Chrome과 Firefox 자체는 비스트 공격에 [115][116]취약하지 않지만, Mozilla는 비스트와 유사한 공격을 완화하기 위해 NSS 라이브러리를 업데이트했습니다.NSS는 Mozilla FirefoxGoogle Chrome에서 SSL을 구현하는 데 사용되므로 SSL 규격을 구현하지 못한 일부서버가 작동을 중지할 수 있습니다.[117]

Microsoft는 2012년 1월 10일에 Windows Secure Channel(Channel) 구성 요소가 서버 끝에서 암호화된 네트워크 패킷을 전송하는 방식을 변경하여 비스트 취약성을 수정한 보안 게시판 MS12-006을 발표했습니다.[118]이전 버전의 Windows(Windows 7, Windows 8 Windows Server 2008 R2)에서 실행되는 Internet Explorer(버전 11 이전) 사용자는 TLS 사용을 1.1 이상으로 제한할 수 있습니다.

애플은 2013년 10월 22일에 출시된 OS X 매버릭스에서 1/n-1 스플릿을 구현하고 기본적으로 전원을 켜서 비스트의 취약성을 수정했습니다.[119]

범죄 및 침입 공격

비스트 공격의 작성자는 나중의 CRIM 공격의 작성자이기도 하며, TLS와 함께 데이터 압축을 사용하면 공격자가 웹 쿠키의 내용을 복구할 수 있습니다.[120][121]비밀 인증 쿠키의 내용을 복구하는 데 사용하면 공격자가 인증된 웹 세션에서 세션 하이재킹을 수행할 수 있습니다.

CRIM 공격은 TLS를 포함하여 많은 수의 프로토콜과 SPDY 또는 HTTP와 같은 애플리케이션 계층 프로토콜에 대해 효과적으로 작동할 수 있는 일반적인 공격으로 제시되었지만, TLS 및 SPDY에 대한 공격만이 브라우저 및 서버에서 시연되었으며 크게 완화되었습니다.CRIM의 저자들은 이러한 취약성이 SPDY와 TLS 압축을 합친 것보다 훨씬 더 광범위할 수 있다고 경고했음에도 불구하고 HTTP 압축에 대한 CRIM 악용은 전혀 완화되지 않았습니다.2013년에는 HTTP 압축에 대한 CRIM 공격의 새로운 사례인 BREATE가 발표되었습니다.CRIM 공격에 기반하여 BREATE 공격은 TLS 암호화된 웹 트래픽에서 로그인 토큰, 이메일 주소 또는 기타 중요한 정보를 30초 이내에 추출할 수 있습니다(추출할 바이트 수에 따라 다름).공격자가 공격 대상자를 속여 악의적인 웹 링크를 방문하게 하거나 사용자가 방문 중인 유효한 페이지(예:[122] 공격자의 제어하에 있는 무선 네트워크)에 콘텐츠를 주입할 수 있는 경우.사용되는 암호화 알고리즘이나 암호에 관계없이 모든 버전의 TLS 및 SSL은 BREATE의 위험에 노출됩니다.[123]TLS 압축이나 SPDY 헤더 압축을 해제하면 성공적으로 방어할 수 있는 이전 CRIM의 경우와 달리 BREATE는 사실상 모든 웹 서버가 HTTP 압축에 의존하여 사용자의 데이터 전송 속도를 향상시키기 때문에 현실적으로 해제할 수 없는 HTTP 압축을 활용합니다.[122]이는 TLS가 보호하고자 하는 애플리케이션 계층 데이터에 대한 선택된 일반 텍스트 공격에 취약하기 때문에 TLS의 알려진 제한 사항입니다.

패딩에 대한 타이밍 공격

이전 TLS 버전은 2002년에 발견된 패딩 오라클 공격에 취약했습니다.럭키 서틴 공격이라고 불리는 새로운 변형이 2013년에 출판되었습니다.

일부 전문가들은[83] 트리플 DECBC를 피할 것을 권하기도 했습니다.Windows XP에서 Internet Explorer와 같은 Windows XP의 SSL/TLS 라이브러리를 사용하는 모든 프로그램을 지원하기 위해 마지막으로 지원된 암호는 RC4 및 Triple-DES이므로 RC4는 이제 더 이상 사용되지 않으므로(RC4 공격에 대한 설명 참조) XP에서 이 라이브러리를 사용하는 모든 프로그램에 대해 SSL 버전을 지원하기가 어렵습니다.

수정 프로그램은 TLS 규격에 대한 Encrypt-then-MAC 확장으로 RFC 7366으로 릴리스되었습니다.[124]럭키 서틴 공격은 AES_GCM 암호만 사용하면 TLS 1.2에서 완화될 수 있으며 AES_CBC는 여전히 취약합니다.SSL은 클라이언트와 서버 간의 안전한 데이터 전송에 대한 주요 사용 사례와 더불어 이메일, VoIP 및 기타 유형의 통신을 안전하지 않은 네트워크를 통해 보호할 수 있습니다.

푸들 공격

Google 연구진은 2014년 10월 14일 SSL 3.0의 설계에 대한 취약성을 발표하였는데, 이로 인해 SSL 3.0을 사용하는 CBC 모드패딩 공격에 취약하게 됩니다(CVE-2014-3566).그들은 이 공격을 POODLE(Padding Oracle On Downgraded Legacy Encryption)이라고 이름 지었습니다.평균적으로 공격자는 암호화된 메시지 1바이트를 노출하기 위해 256개의 SSL 3.0 요청만 하면 됩니다.[89]

이 취약성은 SSL 3.0에만 존재하며 대부분의 클라이언트와 서버는 TLS 1.0 이상을 지원하지만, 사용자 또는 관리자가 SSL 3.0을 사용하지 않도록 설정하는 옵션을 제공하지 않고 사용자 또는 관리자가 사용하지[citation needed] 않도록 설정하지 않는 한 새로운 버전의 TLS를 사용하는 핸드셰이크가 실패하면 모든 주요 브라우저가 자발적으로 SSL 3.0으로 다운그레이드합니다.따라서 중간자가 먼저 버전 롤백 공격을 수행한 다음 이 취약성을 이용할 수 있습니다.[89]

2014년 12월 8일, 패딩 바이트 요구 사항을 제대로 시행하지 않는 TLS 구현에 영향을 미치는 POODLE의 변형이 발표되었습니다.[125]

RC4 공격

RC4에 대한 공격으로 보안이 깨졌지만, RC4를 기반으로 하는 SSL 및 TLS의 암호 제품군은 SSL 및 TLS에서 사용되는 방식에 따라 2013년 이전에는 여전히 안전한 것으로 간주되었습니다.2011년, RC4 제품군은 실제로 비스트 공격에 대한 해결책으로 추천되었습니다.[126]2013년 3월에 공개된 새로운 형태의 공격은 결정적으로 TLS에서 RC4를 파괴할 수 있는 가능성을 보여주었고, 이는 비스트에게 좋은 회피책이 아님을 시사합니다.[88]AlFardan, Bernstein, Paterson, Poettering 및 Schuldt는 RC4 키 테이블에서[127] 새로 발견된 통계적 편향을 사용하여 많은 수의 TLS 암호로 평문의 일부를 복구하는 공격 시나리오를 제안했습니다.[128][129]2013년 7월 8일, 13×220 암호화를 통해 RC4를 파괴해야 하는 TLS 및 SSL의 RC4 공격이 공개되었으며, 이후 2013년 8월 USENIX 보안 심포지엄의 함께 제공된 프레젠테이션에서 "실행 가능"한 것으로 설명되었습니다.[130][131]2015년 7월, 공격의 후속 개선으로 RC4 암호화 TLS의 보안을 무력화하는 것이 점점 더 실용적이 되었습니다.[132]

많은 최신 브라우저가 비스트 공격을 물리치도록 설계되었기 때문에(Mac OS X 10.7 이전 사파리, iOS 6 이전 사파리, Windows용은 제외) RC4는 더 이상 TLS 1.0에 적합하지 않습니다.과거 비스트 공격의 영향을 받았던 CBC 암호는 더 대중적인 보호 대상이 되었습니다.[83]Mozilla와 Microsoft는 가능한 경우 RC4를 비활성화할 것을 권장합니다.[133][134]RFC 7465는 모든 버전의 TLS에서 RC4 암호 모음의 사용을 금지합니다.

2015년 9월 1일, 마이크로소프트, 구글, 모질라는 RC4 암호 모음이 2016년 초 브라우저(윈도우 7/8.1/10의 마이크로소프트 엣지, 인터넷 익스플로러 11, 파이어폭스, 크롬)에서 기본적으로 비활성화될 것이라고 발표했습니다.[135][136][137]

잘림 공격

TLS(로그아웃) 잘라내기 공격은 공격 대상자의 계정 로그아웃 요청을 차단하여 사용자가 알게 모르게 웹 서비스에 로그인한 상태를 유지하도록 합니다.로그아웃 요청이 전송되면 공격자는 암호화되지 않은 TCP FIN 메시지(발신자의 데이터는 더 이상 없음)를 주입하여 연결을 닫습니다.따라서 서버는 로그아웃 요청을 수신하지 않으며 비정상적인 종료를 인식하지 못합니다.[138]

2013년 7월에 발표된 [139][140]이 공격은 Gmail, Hotmail과 같은 웹 서비스가 사용자에게 성공적으로 로그아웃했음을 알리는 페이지를 표시하게 하는 동시에 사용자의 브라우저가 서비스에 대한 권한을 유지하도록 보장합니다.이를 통해 브라우저에 대한 후속 액세스 권한을 가진 공격자가 로그인한 사용자의 계정에 액세스하여 제어권을 넘겨받을 수 있습니다.공격은 공격 대상자의 컴퓨터에 멀웨어를 설치하는 것에 의존하지 않으며, 공격 대상자는 공격 대상자와 웹 서버(예: 악성 무선 핫스팟 설정) 사이에만 자신을 배치하면 됩니다.[138]이 취약성을 이용하려면 공격 대상자의 컴퓨터에도 액세스해야 합니다.FTP를 사용할 경우 데이터 스트림에 잘못된 FIN이 있을 수 있으며, close_notify 경보를 교환하는 프로토콜 규칙이 파일에 적용되지 않으면 파일이 잘릴 수 있습니다.

DTLS에 대한 평문 공격

2013년 2월, 런던 대학교의 로얄 할로웨이의 두 연구원은 암호 블록 체이닝 모드 암호화가 사용되었을 때 DTLS의 OpenSSL 또는 GnuTLS 구현을 사용하여 DTLS 연결에서 평문의 일부를 복구할 수 있는 타이밍 공격을[141] 발견했습니다.

신성불가침 PAC 공격

2016년 중반에 발견된 이 공격은 WPAD(Web Proxy Autodiscovery Protocol)의 약점을 이용하여 웹 사용자가 TLS 지원 웹 링크를 통해 도달하려고 하는 URL을 노출합니다.[142]URL이 노출되면 액세스된 웹 사이트뿐만 아니라 URL이 사용자를 인증하는 데 사용되기 때문에 사용자의 개인 정보를 침해할 수 있습니다.Google이나 Dropbox에서 제공하는 문서 공유 서비스도 URL에 포함된 보안 토큰을 사용자에게 전송함으로써 작동합니다. 이러한 URL을 획득한 공격자는 피해자의 계정이나 데이터에 완전히 접근할 수 있습니다.

이 공격은 거의 모든 브라우저와 운영 체제에 대해 작동합니다.

스위트32 공격

Sweet32 공격은 생일 공격중간자 공격 또는 악의적인 자바스크립트를 웹페이지에 주입하여 TLS에 사용되는 것처럼 CBC 모드에서 사용되는 모든 64비트 블록 암호를 깨뜨립니다.중간자 공격 또는 자바스크립트 주입의 목적은 공격자가 생일 공격을 탑재할 수 있는 충분한 트래픽을 캡처할 수 있도록 하는 것입니다.[143]

구현 오류:하트블리드 버그, BERserk 공격, 클라우드플레어 버그

하트블리드 버그는 인기 있는 OpenSSL 암호화 소프트웨어 라이브러리의 SSL/TLS 구현에 특정된 심각한 취약성으로 버전 1.0.1~1.0.1f에 영향을 미칩니다.2014년 4월에 보고된 이 취약점으로 인해 공격자는 일반적으로 보호해야 하는 서버에서 개인 키를 탈취할 수 있습니다.[144]Heartbleed 버그는 인터넷에 있는 모든 사람이 OpenSSL 소프트웨어의 취약한 버전으로 보호되는 시스템의 메모리를 읽을 수 있도록 합니다.이것은 서비스 공급자를 식별하고 트래픽, 사용자의 이름과 비밀번호 및 실제 콘텐츠를 암호화하는 데 사용되는 공인 인증서와 관련된 비밀 개인 키를 손상시킵니다.이를 통해 공격자는 통신을 도청하고, 서비스와 사용자로부터 직접 데이터를 탈취하고, 서비스와 사용자를 사칭할 수 있습니다.[145]이 취약성은 SSL 또는 TLS 프로토콜 규격의 결함이 아니라 OpenSSL 소프트웨어의 버퍼 과독 버그로 인해 발생합니다.

2014년 9월, Intel Security Advanced Threat Research는 Daniel Bleichenbacher의 PKCS#1 v1.5 RSA Signature 위조 취약성의[146] 변형을 발표했습니다.BERserk라고 불리는 이 공격은 일부 SSL 구현에서 공개 키 서명의 ASN.1 길이 디코딩이 불완전한 결과이며 공개 키 서명을 위조하여 중간자 공격을 허용합니다.[147]

2015년 2월, 미디어에서 일부 레노버 노트북에 슈퍼피시 애드웨어를 미리 설치했다는 보도가 나온 후,[148] 한 연구원은 영향을 받는 레노버 컴퓨터에서 신뢰할 수 있는 루트 인증서가 안전하지 않다는 것을 발견했습니다. 회사 이름인 Komodia를 암호로 사용하여 키에 쉽게 접근할 수 있었기 때문입니다.[149]Komodia 라이브러리는 부모의 통제와 감시를 위해 클라이언트 측 TLS/SSL 트래픽을 차단하도록 설계되었지만, 컴퓨터 사용자가 몰래 설치하는 경우가 많았던 Superfish를 비롯한 수많은 애드웨어 프로그램에서도 사용되었습니다.이에 따라 잠재적으로 원하지 않는 프로그램이 손상된 루트 인증서를 설치하여 공격자가 웹 트래픽을 완전히 제어하고 거짓 웹 사이트를 정품으로 확인할 수 있습니다.

2016년 5월 비자(Visa Inc.) 소속 덴마크 HTTPS로 보호되는 수십 개의 웹사이트가 해커들이 방문자들의 브라우저에 악성코드와 위조된 콘텐츠를 주입할 수 있는 공격에 취약한 것으로 보고되었습니다.[150]공격은 영향을 받는 서버에서 사용된 TLS 구현이 한 번만 사용하도록 의도된 난수(논스)를 잘못 재사용하여 각 TLS 핸드셰이크가 고유하도록 보장했기 때문에 작동했습니다.[150]

2017년 2월 HTML 구문 분석에 사용되는 코드의 단일 잘못 입력된 문자로 인한 구현 오류로 인해 Cloudflare 서버에 버퍼 오버플로 오류가 발생했습니다.2014년 발견된 Heartbleed 버그와 유사하게 Cloudbleed로 널리 알려진 이 오버플로 오류로 인해 권한 없는 제3자가 서버에서 실행 중인 프로그램의 메모리에 있는 데이터, 그렇지 않으면 TLS에 의해 보호되어야 하는 데이터를 읽을 수 있게 되었습니다.[151]

공격에 취약한 웹사이트 조사

2021년 7월 기준, 신뢰할 수 있는 인터넷 운동은 TLS 공격에 취약한 웹사이트의 비율을 추정했습니다.[87]

가장 인기있는 웹사이트의 TLS 취약점 조사
공격 보안.
불안전한 경우에 따라 다르지요 시큐어 다른.
재협상 공격 0.1%
불안정한 재협상을 지지합니다
<0.1%
두 사람을 지지하다
99.2%
안전한 재협상을 지지합니다
0.7%
지지 없음
RC4 공격 0.4%
최신 브라우저에서 사용되는 RC4 제품군 지원
6.5%
일부 RC4 스위트 지원
93.1%
지지 없음
TLS 압축(CRAY 공격) >0.0%
연약한
하트블리드 >0.0%
연약한
ChangeCipherSpec 주입 공격 0.1%
취약하고 이용하기 쉬운
0.2%
취약한, 악용할 수 없는
98.5%
연약하지 않은
1.2%
알 수 없는
TLS에 대한 푸들 공격
(SSL 3.0에 대한 원본 POODLE은 포함되지 않음)
0.1%
취약하고 이용하기 쉬운
0.1%
취약한, 악용할 수 없는
99.8%
연약하지 않은
0.2%
알 수 없는
프로토콜 다운그레이드 6.6%
다운그레이드 방어가 지원되지 않습니다.
72.3%
다운그레이드 방어 지원
21.0%
알 수 없는

순방향 비밀 유지

순방향 비밀은 암호 시스템의 속성으로, 향후 개인 키 중 하나가 손상될 경우 공개 키와 개인 키 집합에서 파생된 세션 키가 손상되지 않도록 보장합니다.[152]순방향 기밀성이 없으면 서버의 개인 키가 손상되면 해당 서버 인증서를 사용하는 향후 모든 TLS 암호화 세션뿐만 아니라 해당 서버 인증서를 사용한 모든 과거 세션도 손상됩니다(전송 시 이러한 과거 세션이 가로채어 저장된 경우).[153]TLS의 구현은 덧셈 디피를 사용하여 순방향 비밀을 제공할 수 있습니다.세션 키를 설정하기 위한 헬만교환과 일부 주목할 만한 TLS 구현은 Gmail과 OpenSSL을 사용하는 다른 Google HTTPS 서비스와 같이 독점적으로 수행됩니다.[154]그러나 TLS를 지원하는 많은 클라이언트와 서버(브라우저 및 웹 서버 포함)는 이러한 제한을 구현하도록 구성되어 있지 않습니다.[155][156]실제로 웹 서비스가 Diffie를 사용하지 않는 한,순방향 비밀을 구현하기 위한 헬만 키 교환, 서비스를 오가는 모든 암호화된 웹 트래픽은 제3자가 예를 들어 법원의 명령을 통해 서버의 마스터(개인) 키를 획득할 경우 해독할 수 있습니다.[157]

디피가 있는 곳에서도..헬만 키 교환이 구현되며, 서버측 세션 관리 메커니즘은 순방향 비밀 유지에 영향을 미칠 수 있습니다.TLS 세션 티켓(TLS 확장자)을 사용하면 순방향 기밀 암호 슈트를 포함한 다른 협상된 TLS 매개 변수에 관계없이 세션이 AES128-CBC-SHA256에 의해 보호되며,[158][159][160] 수명이 긴 TLS 세션 티켓 키는 순방향 기밀 구현 시도를 방해합니다.2014년 스탠포드 대학교의 조사 결과 473,802대의 TLS 서버 중 82.9%의 서버가 임시 Diffie를 구축하고 있는 것으로 나타났습니다.전방 비밀 유지를 지원하기 위한 헬만 키 교환은 약한 디피를 사용했습니다.헬맨 파라미터.이러한 취약한 매개 변수 선택은 서버가 제공하고자 했던 순방향 비밀성의 효과를 잠재적으로 손상시킬 수 있습니다.[161]

2011년 말부터 구글은 Gmail 서비스 사용자에게 구글 문서 및 암호화된 검색과 함께 TLS를 기본적으로 제공해 왔습니다.[162]Twitter는 2013년 11월부터 TLS로 서비스 이용자에게 순방향 비밀을 제공하고 있습니다.[163]2019년 8월 현재 TLS 지원 웹사이트의 약 80%가 대부분의 웹 브라우저에 순방향 비밀을 제공하는 암호 모음을 사용하도록 구성되어 있습니다.[87]

TLS 가로채기

TLS 감청(TLS 감청, 또는 해당 프로토콜에 특히 적용되는 경우 HTTPS 감청)은 암호화된 데이터 스트림을 복호화하여 읽고 조작한 다음 다시 암호화하여 데이터를 다시 전송하는 작업입니다.이 작업은 "투명 프록시"[164]를 통해 수행됩니다. 가로채기 소프트웨어는 수신 TLS 연결을 종료하고 HTTP 평문을 검사한 다음 대상에 대한 새로운 TLS 연결을 만듭니다.

TLS/HTTPS 감청은 컴퓨터 바이러스 및 기타 악성 프로그램과 같은 악성 콘텐츠의 네트워크 침입을 검색하고 보호하기 위해 네트워크 운영자가 정보 보안 수단으로 사용합니다.[164]HTTPS 및 기타 보안 프로토콜의 일상적인 사용의 결과로 인해 암호화로 보호되는 한 이러한 콘텐츠를 탐지할 수 없습니다.

TLS/HTTPS 감청의 중요한 단점은 TLS/HTTPS 감청이 자체적으로 새로운 보안 위험을 초래한다는 것입니다.한 가지 주목할 만한 제한 사항은 네트워크 트래픽을 암호화되지 않은 상태로 사용할 수 있는 지점을 제공하여 공격자가 보안 콘텐츠에 액세스하기 위해 이 지점을 공격할 유인을 제공한다는 것입니다.또한 가로채기는 네트워크 운영자 또는 해당 가로채기 시스템에 접근한 사용자가 네트워크 사용자를 대상으로 중간자 공격을 수행할 수 있습니다.2017년의 한 연구는 "HTTPS 가로채기가 놀라울 정도로 널리 퍼졌고, 가로채기 제품은 등급별로 접속 보안에 극적으로 부정적인 영향을 끼친다"고 밝혔습니다.[164]

프로토콜상세

TLS 프로토콜은 교환할 데이터를 특정 형식으로 캡슐화하는 레코드를 교환합니다(아래 참조).각 레코드는 연결 상태에 따라 압축, 패딩, 메시지 인증 코드(MAC) 추가 또는 암호화할 수 있습니다.각 레코드에는 캡슐화된 데이터의 유형을 지정하는 내용 유형 필드, 길이 필드 및 TLS 버전 필드가 있습니다.캡슐화된 데이터는 TLS 자체의 제어 메시지 또는 절차 메시지이거나 TLS에 의해 전송되는 데 필요한 애플리케이션 데이터일 수 있습니다.TLS에 의한 애플리케이션 데이터 교환에 필요한 사양(암호 스위트, 키 등)은 데이터를 요청하는 클라이언트와 요청에 응답하는 서버 간의 "TLS 핸드셰이크"에서 합의됩니다.따라서 프로토콜은 TLS에서 전송되는 페이로드의 구조와 전송을 설정하고 모니터링하는 절차를 모두 정의합니다.

TLS 핸드셰이크

TLS 1.2 전체 핸드셰이크와 타이밍 정보를 간단히 설명합니다.

연결이 시작되면 레코드는 "제어" 프로토콜인 핸드셰이크 메시징 프로토콜(내용 유형 22)을 캡슐화합니다.이 프로토콜은 TLS에 의한 실제 응용 데이터의 교환을 위해 양측이 요구하는 모든 정보를 교환하는 데 사용됩니다.메시지의 형식과 교환 순서를 정의합니다.이는 클라이언트와 서버의 요구에 따라 달라질 수 있습니다. 즉, 연결을 설정하는 데 몇 가지 가능한 절차가 있습니다.이 초기 교환으로 TLS 연결(양측 모두 TLS로 응용 프로그램 데이터를 전송할 준비가 됨) 또는 경고 메시지(아래 지정됨)가 발생합니다.

기본 TLS 핸드셰이크

서버(클라이언트가 아닌)가 인증서로 인증되는 핸드셰이크를 나타내는 일반적인 연결 예는 다음과 같습니다.

  1. 협상 단계:
    • 클라이언트는 자신이 지원하는 최고 TLS 프로토콜 버전, 임의 번호, 제안된 암호 모음 목록 및 제안된 압축 방법을 지정하는 ClientHello 메시지를 보냅니다.클라이언트가 핸드셰이크를 재개하려고 하면 세션 ID를 보낼 수 있습니다.클라이언트가 Application-Layer Protocol Negotiation을 사용할 수 있는 경우 HTTP/2와 같은 지원되는 응용프로그램 프로토콜 목록을 포함할 수 있습니다.
    • 서버는 선택한 프로토콜 버전, 랜덤 번호, 암호 모음 및 클라이언트가 제공한 선택사항에서 압축 방법을 포함하는 ServerHello 메시지로 응답합니다.핸드셰이크 재개를 확인하거나 허용하기 위해 서버는 세션 ID를 보낼 수 있습니다.선택한 프로토콜 버전은 클라이언트와 서버 모두가 지원하는 가장 높은 버전이어야 합니다.예를 들어 클라이언트가 TLS 버전 1.1을 지원하고 서버가 버전 1.2를 지원하는 경우 버전 1.1을 선택해야 하며 버전 1.2를 선택해서는 안 됩니다.
    • 서버가 인증서 메시지를 보냅니다(선택한 암호 모음에 따라 서버에서 생략할 수 있음).[165]
    • 서버가 서버 를 전송합니다.교환 메시지(선택한 암호 모음에 따라 서버에서 생략할 수 있음).이 메시지는 모든 DHE, ECDHE 및 DH_anon 암호 스위트에 대해 전송됩니다.[23]
    • 서버는 핸드셰이크 협상이 완료되었음을 나타내는 ServerHelloDone 메시지를 보냅니다.
    • 클라이언트가 클라이언트 로 응답합니다.교환 메시지. PreMasterSecret, 공개 키 또는 아무것도 포함하지 않을 수 있습니다. (다시 말하지만, 이는 선택한 암호에 따라 다릅니다.)PreMasterSecret는 서버 인증서의 공용 키를 사용하여 암호화됩니다.
    • 그런 다음 클라이언트와 서버는 난수와 PreMasterSecret를 사용하여 "마스터 비밀"이라고 불리는 공통 비밀을 계산합니다.이 연결을 위한 다른 모든 키 데이터(IV, 대칭 암호화 키, MAC 키와[166] 같은 세션 키)는 이 마스터 비밀(및 클라이언트 및 서버에서 생성된 랜덤 값)에서 파생되며, 이는 주의 깊게 설계된 의사 랜덤 함수를 통해 전달됩니다.
  2. 이제 클라이언트는 ChangeCipherSpec 레코드를 보내 서버에 "지금부터 말하는 모든 것이 인증되고 서버 인증서에 암호화 매개 변수가 있는 경우 암호화됩니다."라고 본질적으로 말합니다.ChangeCipherSpec은 그 자체로 콘텐츠 유형이 20인 레코드 레벨 프로토콜입니다.
    • 클라이언트는 이전 핸드셰이크 메시지를 통해 해시 및 MAC를 포함하는 인증되고 암호화된 완료 메시지를 보냅니다.
    • 서버는 클라이언트의 완료 메시지를 해독하고 해시 및 MAC를 확인합니다.암호 해독 또는 확인에 실패하면 핸드셰이크가 실패한 것으로 간주되어 연결을 종료해야 합니다.
  3. 마지막으로 서버는 ChangeCipherSpec을 보내 클라이언트에게 "지금부터 내가 말하는 모든 것이 인증(암호화 협상이 진행된 경우 암호화)될 것입니다."라고 말합니다.
    • 서버는 인증되고 암호화된 완료 메시지를 발송합니다.
    • 클라이언트는 이전 단계의 서버와 동일한 복호화 및 확인 절차를 수행합니다.
  4. 응용 프로그램 단계: 이 시점에서 "악수"가 완료되고 응용 프로그램 프로토콜이 활성화되며 내용 유형은 23입니다.클라이언트와 서버 간에 교환된 응용프로그램 메시지도 완료된 메시지와 동일하게 인증되고 선택적으로 암호화됩니다.그렇지 않으면 내용 유형이 25를 반환하고 클라이언트가 인증하지 않습니다.

클라이언트 인증 TLS 핸드셰이크

다음 전체 예는 두 피어 간에 교환된 인증서를 사용하여 TLS를 통해 인증되는 클라이언트(위 예와 같은 서버 외에도; 상호 인증 참조)를 보여줍니다.

  1. 협상 단계:
    • 클라이언트는 자신이 지원하는 최고 TLS 프로토콜 버전, 임의 번호, 제안된 암호 모음 목록 및 압축 방법을 지정하는 ClientHello 메시지를 보냅니다.
    • 서버는 선택한 프로토콜 버전, 랜덤 번호, 암호 모음 및 클라이언트가 제공한 선택사항에서 압축 방법을 포함하는 ServerHello 메시지로 응답합니다.서버는 재개된 핸드셰이크를 수행하기 위해 메시지의 일부로 세션 ID를 보낼 수도 있습니다.
    • 서버가 인증서 메시지를 보냅니다(선택한 암호 모음에 따라 서버에서 생략할 수 있음).[165]
    • 서버가 서버 를 전송합니다.교환 메시지(선택한 암호 모음에 따라 서버에서 생략할 수 있음).이 메시지는 모든 DHE, ECDHE 및 DH_an 암호 세트에 대해 발송됩니다.[1]
    • 서버는 클라이언트에게 인증서를 요청하기 위해 CertificateRequest 메시지를 보냅니다.
    • 서버는 핸드셰이크 협상이 완료되었음을 나타내는 ServerHelloDone 메시지를 보냅니다.
    • 클라이언트는 클라이언트의 인증서는 포함하지만 개인 키는 포함하지 않는 인증서 메시지로 응답합니다.
    • 클라이언트가 클라이언트 를 보냅니다.교환 메시지. PreMasterSecret, 공개 키 또는 아무것도 포함하지 않을 수 있습니다. (다시 말하지만, 이는 선택한 암호에 따라 다릅니다.)PreMasterSecret는 서버 인증서의 공용 키를 사용하여 암호화됩니다.
    • 클라이언트는 CertificateVerify 메시지를 전송합니다. 이 메시지는 클라이언트의 인증서 개인 키를 사용하는 이전 핸드셰이크 메시지에 대한 서명입니다.이 서명은 클라이언트의 인증서 공개 키를 사용하여 확인할 수 있습니다.이렇게 하면 서버는 클라이언트가 인증서의 개인 키에 액세스할 수 있으므로 인증서를 소유하고 있음을 알 수 있습니다.
    • 그런 다음 클라이언트와 서버는 난수와 PreMasterSecret를 사용하여 "마스터 비밀"이라고 불리는 공통 비밀을 계산합니다.이 연결을 위한 다른 모든 키 데이터("세션 키")는 주의 깊게 설계된 의사 랜덤 함수를 통해 전달되는 이 마스터 비밀(및 클라이언트 및 서버에서 생성된 랜덤 값)에서 파생됩니다.
  2. 이제 클라이언트는 ChangeCipherSpec 레코드를 보내 서버에 기본적으로 "지금부터 말하는 모든 것이 인증되고 암호화 협상이 진행된 경우 암호화됩니다."ChangeCipherSpec은 그 자체로 레코드 레벨 프로토콜이며 22가 아닌 20형을 가지고 있습니다.
    • 마지막으로 클라이언트는 이전 핸드셰이크 메시지를 통해 해시 및 MAC가 포함된 암호화된 완료 메시지를 보냅니다.
    • 서버는 클라이언트의 완료 메시지를 해독하고 해시 및 MAC를 확인합니다.암호 해독 또는 확인에 실패하면 핸드셰이크가 실패한 것으로 간주되어 연결을 해체해야 합니다.
  3. 마지막으로 서버는 ChangeCipherSpec을 보내 클라이언트에게 "지금부터 내가 말하는 모든 것이 인증(암호화 협상이 진행된 경우 암호화)될 것입니다."라고 말합니다.
    • 서버는 자체적으로 암호화된 완료 메시지를 발송합니다.
    • 클라이언트는 이전 단계의 서버와 동일한 복호화 및 확인 절차를 수행합니다.
  4. 응용 프로그램 단계: 이 시점에서 "악수"가 완료되고 응용 프로그램 프로토콜이 활성화되며 내용 유형은 23입니다.클라이언트와 서버 간에 교환되는 응용프로그램 메시지도 완료된 메시지와 동일하게 암호화됩니다.

TLS 핸드셰이크 재개

공개 키 작업(예: RSA)은 계산 능력 측면에서 상대적으로 비용이 많이 듭니다.TLS는 핸드셰이크 메커니즘에서 이러한 작업을 방지할 수 있는 안전한 바로 가기를 제공합니다. 세션이 재개됩니다.재개된 세션은 세션 ID 또는 세션 티켓을 사용하여 구현됩니다.

성능상의 이점 외에도 재개된 세션은 원래 세션과 재개된 세션이 모두 동일한 클라이언트에서 시작되는 것을 보장하므로 단일 로그온에도 사용할 수 있습니다.이는 TLS/SSL을 통한 FTP 프로토콜에서 특히 중요합니다. 그렇지 않으면 공격자가 2차 데이터 연결의 내용을 가로챌 수 있는 중간자 공격이 발생합니다.[167]

TLS 1.3 핸드셰이크

TLS 1.3 핸드셰이크는 이전 버전의 TLS/SSL에서 필요했던 두 번의 왕복에 비해 단 한 번의 왕복으로 압축되었습니다.

핸드셰이크를 시작하기 위해, 클라이언트는 서버가 선택할 키 교환 알고리즘을 추측하고, 클라이언트가 선호하는 순서대로 지원되는 암호 목록과 키 교환 추측의 일부 또는 전부에 대한 공개 키를 포함하는 클라이언트Hello 메시지를 서버에 보냅니다.클라이언트가 키 교환 알고리즘을 성공적으로 추측하면 핸드셰이크에서 왕복 1회가 제거됩니다.클라이언트 Hello를 수신한 후 서버는 암호를 선택하고 서버 Hello를 자신의 공용 키와 함께 다시 보내고 서버 CertificateFinished 메시지를 보냅니다.[168]

클라이언트가 서버의 완료된 메시지를 수신한 후, 이제 클라이언트는 사용할 암호 모음의 서버와 조정됩니다.[169]

세션 ID

일반적인 전체 핸드셰이크에서 서버는 ServerHello 메시지의 일부로 세션 ID를 발송합니다.클라이언트는 이 세션 ID를 서버의 IP 주소 및 TCP 포트와 연결하여 클라이언트가 해당 서버에 다시 연결할 때 세션 ID를 사용하여 핸드셰이크를 단축할 수 있습니다.서버에서 세션 ID는 이전에 협상된 암호화 매개 변수, 특히 "마스터 비밀"에 매핑됩니다.양쪽 모두 동일한 "마스터 비밀"을 가지고 있어야 합니다. 그렇지 않으면 재개된 핸드셰이크가 실패합니다(이로 인해 도청자가 세션 ID를 사용할 수 없음).ClientHelloServerHello 메시지의 임의 데이터는 생성된 연결 키가 이전 연결과 다르다는 것을 사실상 보장합니다.RFC에서는 이러한 유형의 핸드셰이크를 축약 핸드셰이크라고 합니다.또한 문헌에는 재시작 악수로 설명되어 있습니다.

  1. 협상 단계:
    • 클라이언트는 자신이 지원하는 최고 TLS 프로토콜 버전, 임의 번호, 제안된 암호 모음 목록 및 압축 방법을 지정하는 ClientHello 메시지를 보냅니다.메시지에 포함된 것은 이전 TLS 연결의 세션 ID입니다.
    • 서버는 선택한 프로토콜 버전, 랜덤 번호, 암호 모음 및 클라이언트가 제공한 선택사항에서 압축 방법을 포함하는 ServerHello 메시지로 응답합니다.서버가 클라이언트가 보낸 세션 ID를 인식하면 동일한 세션 ID로 응답합니다.클라이언트는 이 기능을 사용하여 핸드셰이크가 재개되고 있음을 인식합니다.서버가 클라이언트가 보낸 세션 ID를 인식하지 못할 경우, 서버는 해당 세션 ID에 대해 다른 값을 보냅니다.이는 클라이언트에게 재개된 핸드셰이크가 수행되지 않음을 알려줍니다.이때 클라이언트와 서버 모두 "마스터 비밀"과 랜덤 데이터를 사용하여 이 연결에 사용할 키 데이터를 생성합니다.
  2. 이제 서버는 ChangeCipherSpec 레코드를 전송하고, 기본적으로 클라이언트에게 "지금부터 내가 말하는 모든 것은 암호화될 것입니다."라고 말합니다.ChangeCipherSpec은 그 자체로 레코드 레벨 프로토콜이며 22가 아닌 20형을 가지고 있습니다.
    • 마지막으로 서버는 이전 핸드셰이크 메시지를 통해 해시 및 MAC를 포함하는 암호화된 완료 메시지를 보냅니다.
    • 클라이언트가 서버의 완료 메시지를 해독하고 해시 및 MAC를 확인합니다.암호 해독 또는 확인에 실패하면 핸드셰이크가 실패한 것으로 간주되어 연결을 해체해야 합니다.
  3. 마지막으로 클라이언트는 ChangeCipherSpec을 보내 서버에 "지금부터 내가 하는 모든 말은 암호화될 것입니다."라고 말합니다.
    • 클라이언트는 자체 암호화된 Finished 메시지를 보냅니다.
    • 서버는 클라이언트가 이전 단계에서 수행한 것과 동일한 복호화 및 확인 절차를 수행합니다.
  4. 응용 프로그램 단계: 이 시점에서 "악수"가 완료되고 응용 프로그램 프로토콜이 활성화되며 내용 유형은 23입니다.클라이언트와 서버 간에 교환되는 응용프로그램 메시지도 완료된 메시지와 동일하게 암호화됩니다.
세션티켓

RFC 5077은 세션 ID 대신 세션 티켓을 사용하여 TLS를 확장합니다.세션별 상태를 TLS 서버에 저장할 필요 없이 TLS 세션을 재개하는 방법을 정의합니다.

세션 티켓을 사용할 때 TLS 서버는 세션별 상태를 세션 티켓에 저장하고 세션 티켓을 TLS 클라이언트에 전송하여 저장합니다.클라이언트는 세션 티켓을 서버로 전송하여 TLS 세션을 재개하고 서버는 티켓의 세션별 상태에 따라 TLS 세션을 재개합니다.세션 티켓은 서버에 의해 암호화되고 인증되며 서버는 내용을 사용하기 전에 유효성을 확인합니다.

OpenSSL의 이 방법의 한 가지 특히 약점은 전송된 TLS 세션 티켓의 암호화 및 인증 보안을 항상 다음으로 제한한다는 것입니다.AES128-CBC-SHA256, 실제 TLS 세션에 대해 협상된 다른 TLS 매개변수가 무엇이든 간에.[159]이는 상태 정보(TLS 세션 티켓)가 TLS 세션 자체만큼 잘 보호되지 않는다는 것을 의미합니다.특히 OpenSSL이 애플리케이션 전체의 맥락에서 키를 저장하는 것이 중요합니다.SSL_CTX), 즉, 애플리케이션의 수명을 위해, 그리고 그것의 재키핑을 허용하지 않습니다.AES128-CBC-SHA256응용 프로그램 전체 OpenSSL 컨텍스트를 재설정하지 않고 TLS 세션 티켓을 사용합니다(흔치 않고 오류가 발생하기 쉬우며 종종 수동 관리 개입이 필요함).[160][158]

TLS레코드

이것은 모든 TLS 레코드의 일반 형식입니다.

TLS 레코드 형식, 일반
간격띄우기 바이트+0 바이트+1 바이트+2 바이트+3
바이트
0
내용유형
바이트 수
1–4
레거시 버전 길이
(전공) (단조) (비트 15-8) (비트 7–0)
바이트 수
5–(m−1)
프로토콜 메시지
바이트 수
m–(p−1)
MAC(옵션)
바이트 수
p–(q−1)
패딩(블록 암호만 해당)
내용유형
이 필드는 이 레코드에 포함된 레코드 계층 프로토콜 유형을 식별합니다.
내용 유형
육각형 12월 유형
0×14 20 암호 사양 변경
0×15 21 알림
0×16 22 악수
0×17 23 어플
0×18 24 하트비트
레거시 버전
이 필드는 포함된 메시지에 대한 TLS 1.3 이전 TLS의 주 버전과 부 버전을 식별합니다.ClientHello 메시지의 경우 클라이언트가 지원하는 가장 높은 버전일 필요는 없습니다.TLS 1.3 이상의 경우 이 값을 0x0303으로 설정해야 하며 응용 프로그램은 추가 메시지 확장 블록에 지원되는 버전을 전송해야 합니다.
버전
주요한
버전
작은
버전
버전종류
3 0 SSL 3.0
3 1 TLS 1.0
3 2 TLS 1.1
3 3 TLS 1.2
3 4 TLS 1.3
길이
"프로토콜 메시지(들)", "MAC" 및 "패딩" 필드를 결합한 길이(즉, q-5), 2바이트14(16KiB)를 초과하지 않습니다.
프로토콜 메시지
프로토콜 필드에 의해 식별된 하나 이상의 메시지입니다.이 필드는 연결 상태에 따라 암호화될 수 있습니다.
맥앤패딩
"protocol message(들)" 필드를 통해 계산된 메시지 인증 코드로, 추가적인 키 자료가 포함됩니다.이 필드는 연결 상태에 따라 암호화되거나 완전히 포함되지 않을 수 있습니다.
모든 암호 알고리즘 및 매개 변수가 협상 및 핸드셰이크되기 전에 TLS 레코드의 끝에 "MAC" 또는 "패딩" 필드가 존재할 수 없으며, 이들 매개 변수가 동일한 피어가 전송한 이후의 모든 레코드에서 적용된다는 신호를 보내기 위해 CipherStateChange 레코드(아래 참조)를 전송하여 확인할 수 있습니다.

핸드셰이크 프로토콜

TLS 세션 설정 중에 교환되는 대부분의 메시지는 오류 또는 경고가 발생하여 Alert 프로토콜 레코드(아래 참조)에 의해 시그널링되어야 하거나 세션의 암호화 모드가 다른 레코드에 의해 수정되지 않는 한 이 레코드를 기반으로 합니다(아래 ChangeCipherSpec 프로토콜 참조).

핸드셰이크 프로토콜의 TLS 레코드 형식
간격띄우기 바이트+0 바이트+1 바이트+2 바이트+3
바이트
0
22
바이트 수
1–4
레거시 버전 길이
(전공) (단조) (비트 15-8) (비트 7–0)
바이트 수
5–8
메시지유형 악수 메시지 데이터 길이
(비트 23-16) (비트 15-8) (비트 7–0)
바이트 수
9–(n−1)
핸드셰이크 메시지 데이터
바이트 수
n–(n+3)
메시지유형 악수 메시지 데이터 길이
(비트 23-16) (비트 15-8) (비트 7–0)
바이트 수
(n+4)–
핸드셰이크 메시지 데이터
메시지유형
이 필드는 핸드셰이크 메시지 유형을 식별합니다.
메시지 종류
코드 묘사
0 HelloRequest
1 클라이언트 Hello
2 서버Hello
4 뉴세션티켓
8 암호화된확장(TLS 1.3만 해당)
11 인증서.
12 서버 키교환하다
13 인증서 요청
14 서버 HelloDone
15 인증서 확인
16 클라이언트 키교환하다
20 끝났습니다
악수 메시지 데이터 길이
헤더를 포함하지 않고 핸드셰이크 데이터의 길이를 나타내는 3바이트 필드입니다.

하나의 레코드 내에서 여러 개의 악수 메시지를 결합할 수 있습니다.

경보 프로토콜

이 기록은 일반적으로 일반적인 악수나 응용 프로그램 교환 중에 전송해서는 안 됩니다.그러나 이 메시지는 핸드셰이크 중에 세션이 종료될 때까지 언제든지 전송될 수 있습니다.이것이 치명적인 오류를 알리는 데 사용될 경우, 이 레코드를 보낸 후 즉시 세션이 닫히므로, 이 레코드는 이 레코드를 닫는 이유를 제공하는 데 사용됩니다.경고 수준이 경고로 플래그가 지정된 경우, 세션이 필요에 따라 충분히 신뢰할 수 없다고 판단되면 원격에서 세션을 닫기로 결정할 수 있습니다(그 전에 원격에서 자체 신호를 보낼 수도 있습니다).

알림 프로토콜의 TLS 레코드 형식
간격띄우기 바이트+0 바이트+1 바이트+2 바이트+3
바이트
0
21
바이트 수
1–4
레거시 버전 길이
(전공) (단조) 0 2
바이트 수
5–6
레벨 묘사
바이트 수
7–(p−1)
MAC(옵션)
바이트 수
p–(q−1)
패딩(블록 암호만 해당)
레벨
이 필드는 경고 수준을 나타냅니다.레벨이 치명적인 경우 발신인은 세션을 즉시 종료해야 합니다.그렇지 않으면 수신자는 치명적인 경고를 전송하고 세션을 전송한 후 즉시 세션 자체를 종료하여 세션 자체를 종료하기로 결정할 수 있습니다.Alert 레코드의 사용은 선택 사항이지만, 세션이 닫히기 전에 누락된 경우 핸드셰이크를 사용하여 세션을 자동으로 재개할 수 있습니다.
전송된 응용 프로그램이 종료된 후 세션을 정상적으로 닫으면 새 세션의 자동 재개를 방지하기 위해 최소한 Close notify Alert 유형(단순 경고 수준)으로 경고해야 합니다.전송 계층을 효과적으로 닫기 전에 보안 세션의 정상적인 종료를 명시적으로 시그널링하는 것은 공격(보안 데이터의 수신자가 예상할 수 있는 사전 결정된 길이 또는 지속 시간을 본질적으로 가지지 않는 경우, 보안 전송된 데이터를 잘라내려는 시도와 같이)을 방지하거나 탐지하는 데 유용합니다.
경고 수준 유형
코드 레벨타입 접속상태
1 경고문 연결이나 보안이 불안정할 수 있습니다.
2 치명적인 연결 또는 보안이 손상되거나 복구할 수 없는 오류가 발생했습니다.
묘사
이 필드는 발송되는 알림 유형을 나타냅니다.
경고 설명 유형
코드 묘사 레벨타입 메모
0 닫기알림 경고/
10 예기치 않은 메시지 치명적인
20 불량 기록 MAC 치명적인 잘못된 SSL 구현이거나 FTPS 서버의 FTP 방화벽 규칙과 같은 페이로드가 변조되었을 수 있습니다.
21 암호 해독 실패 치명적인 TLS 전용, 예약됨
22 레코드오버플로 치명적인 TLS 전용
30 압축 해제 실패 치명적인
40 악수 실패 치명적인
41 인증서없음 경고/ SSL 3.0만, 예약됨
42 불량인증서 경고/
43 지원되지 않는 인증서 경고/ 예: 인증서는 서버 인증 사용만 활성화되어 있으며 클라이언트 인증서로 표시됨
44 인증서 취소됨 경고/
45 인증서가 만료됨 경고/ 서버 인증서가 만료되었는지 확인 또한 표시된 체인의 인증서가 만료되지 않았는지 확인합니다.
46 인증서 알 수 없음 경고/
47 매개변수가 잘못되었습니다. 치명적인
48 알 수 없는 CA(인증 기관) 치명적인 TLS 전용
49 액세스 거부됨 치명적인 TLS만 해당 – 예를 들어 클라이언트 인증서가 제공되지 않았지만(TLS: 공백 인증서 메시지 또는 SSLv3: 인증서 없음 경고), 서버는 인증서가 필요하도록 구성되어 있습니다.
50 디코딩 오류 치명적인 TLS 전용
51 암호 해독 오류 경고/ TLS 전용
60 수출제한 치명적인 TLS 전용, 예약됨
70 프로토콜 버전 치명적인 TLS 전용
71 보안부족 치명적인 TLS 전용
80 내부오류 치명적인 TLS 전용
86 부적절한 폴백 치명적인 TLS 전용
90 사용자 취소됨 치명적인 TLS 전용
100 재협상 불가 경고문 TLS 전용
110 지원되지 않는 확장명 경고문 TLS 전용
111 인증서를 가져올 수 없음 경고문 TLS 전용
112 인식할수없는이름 경고/ TLS만 해당, 클라이언트의 Server Name Indicator에서 서버가 지원하지 않는 호스트 이름을 지정했습니다.
113 잘못된 인증서 상태 응답 치명적인 TLS 전용
114 잘못된 인증서 해시 값 치명적인 TLS 전용
115 알 수 없는 PSK ID(TLS-PSKTLS-SRP에 사용됨) 치명적인 TLS 전용
116 인증서 필요 치명적인 TLS 버전 1.3만
120 또는 255 응용프로그램 프로토콜 없음 치명적인 TLS 버전 1.3만

ChangeCipherSpec 프로토콜

ChangeCipherSpec 프로토콜의 TLS 레코드 형식
간격띄우기 바이트+0 바이트+1 바이트+2 바이트+3
바이트
0
20
바이트 수
1–4
레거시 버전 길이
(전공) (단조) 0 1
바이트
5
CCS 프로토콜 유형
CCS 프로토콜 유형
현재 1개뿐입니다.

응용프로토콜

응용 프로그램 프로토콜의 TLS 레코드 형식
간격띄우기 바이트+0 바이트+1 바이트+2 바이트+3
바이트
0
23
바이트 수
1–4
레거시 버전 길이
(전공) (단조) (비트 15-8) (비트 7–0)
바이트 수
5–(m−1)
어플리케이션 데이터
바이트 수
m–(p−1)
MAC(옵션)
바이트 수
p–(q−1)
패딩(블록 암호만 해당)
길이
응용프로그램 데이터 길이(프로토콜 헤더 제외, MAC 및 패딩 트레일러 포함)
SHA-256 기반 HMAC의 경우 32바이트, SHA-1 기반 HMAC의 경우 20바이트, MD5 기반 HMAC의 경우 16바이트입니다.
패딩
변수 길이, 마지막 바이트에 패딩 길이가 포함되어 있습니다.

이름 기반 가상 서버 지원

응용 프로그램 프로토콜 관점에서 TLS는 하위 계층에 속하지만 TCP/IP 모델이 너무 조잡하여 표시할 수 없습니다.이는 TLS 핸드셰이크가 일반적으로(STARTTLS 경우는 제외) 응용 프로그램 프로토콜이 시작되기 전에 수행된다는 것을 의미합니다.애플리케이션 계층에서 제공하는 이름 기반 가상 서버 기능에서는 서버가 클라이언트 Hello 메시지 직후에 인증서를 선택하여 전송해야 하므로 공동 호스팅하는 모든 가상 서버가 동일한 인증서를 공유합니다.이는 모든 고객 간에 동일한 인증서를 공유하거나 고객마다 다른 IP 주소를 사용하는 것을 의미하기 때문에 호스팅 환경에서는 큰 문제가 됩니다.

X.509에서 제공하는 두 가지 해결 방법이 있습니다.

  • 모든 가상 서버가 동일한 도메인에 속한 경우 와일드카드 인증서를 사용할 수 있습니다.[170]문제가 될 수도 있고 그렇지 않을 수도 있는 느슨한 호스트 이름 선택 외에 와일드카드 인증서를 일치시키는 방법에 대한 일반적인 합의는 없습니다.사용하는 응용프로그램 프로토콜이나 소프트웨어에 따라 다른 규칙이 적용됩니다.[171]
  • 제목에 있는 모든 가상 호스트 이름 추가AltName 확장명입니다.가장 큰 문제는 새로운 가상 서버를 추가할 때마다 인증서를 재발급해야 한다는 것입니다.

서버 이름을 제공하기 위해 RFC 4366 TLS(Transport Layer Security) Extensions를 사용하면 클라이언트는 확장 클라이언트 Hello 메시지에 SNI(Server Name Indication Extension)를 포함할 수 있습니다.이 확장자는 클라이언트가 접속할 이름을 즉시 서버에 알려주기 때문에 서버는 클라이언트에게 보낼 적절한 인증서를 선택할 수 있습니다.

또한 RFC 2817HTTP/1.1 업그레이드 헤더를 통해 HTTP를 TLS로 업그레이드하여 이름 기반 가상 호스팅을 구현하는 방법을 문서화합니다.일반적으로, 이것은 (URI 공간의 이탈을 방지하고 사용되는 포트의 수를 줄이는) 주 "http" URI 체계 내에서 HTTP over TLS를 안전하게 구현하기 위한 것이지만, 현재 이를 지원하는 구현은 거의 없습니다.[citation needed]

기준

1차 표준

(D)의 현재 승인된 버전TLS는 버전 1.3이며 다음에 명시되어 있습니다.

  • RFC 8446: "TLS(Transport Layer Security) 프로토콜 버전 1.3".
  • RFC 9147: "DTLS(Datagram Transport Layer Security) 프로토콜 버전 1.3"

현재의 표준은 현재 구식으로 간주되는 이전 버전을 대체합니다.

  • RFC 5246: "TLS(Transport Layer Security) 프로토콜 버전 1.2".
  • RFC 6347: "데이터그램 전송 계층 보안 버전 1.2"
  • RFC 4346: "TLS(Transport Layer Security) 프로토콜 버전 1.1".
  • RFC 4347" "데이터그램 전송 계층 보안"
  • RFC 2246: "TLS 프로토콜 버전 1.0".
  • RFC 6101: "보안 소켓 계층(SSL) 프로토콜 버전 3.0"
  • 인터넷 초안(1995): "SSL 프로토콜"

확장자

다른 RFC들은 그 후 확장 (D)TLS.

(D)로 확장TLS 1.3은 다음과 같습니다.

  • RFC 9367: "전송 계층 보안(TLS) 프로토콜 버전 1.3을 위한 GOST 암호 스위트"

(D)로 확장TLS 1.2는 다음과 같습니다.

  • RFC 5288: "TLS용 AES Galois Counter Mode (GCM) 암호 스위트".
  • RFC 5289: "SHA-256/384 및 AES Galois Counter Mode(GCM)를 사용하는 TLS 타원 곡선 암호 스위트".
  • RFC 5746: "TLS(Transport Layer Security) 재협상 지시 확장"
  • RFC 5878: "TLS(Transport Layer Security) Authorization Extensions".
  • RFC 5932: "TLS용 동백 암호 스위트"
  • RFC 6066: "TLS(Transport Layer Security) 확장: 확장 정의"는 서버 이름 표시와 OCSP 스테이플링을 포함합니다.
  • RFC 6091: "TLS(Transport Layer Security) 인증에 OpenPGP 키 사용"
  • RFC 6176: "Secure Sockets Layer (SSL) Version 2.0 금지"
  • RFC 6209: "전송 계층 보안(TLS)에 ARIA 암호 스위트 추가".
  • RFC 6347: "데이터그램 전송 계층 보안 버전 1.2".
  • RFC 6367: "TLS(Transport Layer Security)에 카멜리아 암호 스위트 추가".
  • RFC 6460: "TLS(Transport Layer Security)를 위한 스위트 B 프로파일".
  • RFC 6655: "TLS(Transport Layer Security)를 위한 AES-CCM 암호 스위트".
  • RFC 7027: "Eliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)".
  • RFC 7251: "TLS용 AES-CCM 타원 곡선 암호화(ECC) 암호 스위트"
  • RFC 7301: "TLS(Transport Layer Security) Application-Layer Protocol Negotiation Extension"
  • RFC 7366: "전송 계층 보안(TLS) 및 데이터그램 전송 계층 보안(DTLS)을 위한 암호화-그때-MAC".
  • RFC 7465: "RC4 암호 스위트 금지".
  • RFC 7507: "프로토콜 다운그레이드 공격 방지를 위한 TLS 폴백 시그널링 암호 집합 값(SCSV)"입니다.
  • RFC 7568: "Secure Sockets Layer Version 3.0의 성능 저하".
  • RFC 7627: "TLS(Transport Layer Security) 세션 해시 및 확장 마스터 비밀 확장".
  • RFC 7685: "TLS(Transport Layer Security) 클라이언트 Hello 패딩 확장".
  • RFC 9189: "전송 계층 보안(TLS) 프로토콜 버전 1.2를 위한 GOST 암호 스위트"

(D)로 확장TLS 1.1은 다음을 포함합니다.

  • RFC 4366: "TLS(Transport Layer Security) Extensions"는 특정 확장 집합과 일반 확장 메커니즘을 모두 설명합니다.
  • RFC 4492: "전송 계층 보안(TLS)을 위한 타원 곡선 암호학(ECC) 암호 스위트".
  • RFC 4680: "보충 데이터를 위한 TLS 악수 메시지".
  • RFC 4681: "TLS 사용자 매핑 확장".
  • RFC 4785: "전송 계층 보안(TLS)을 위한 NULL 암호화와 함께 사전 공유 키(PSK) 암호 슈트".
  • RFC 5054: "TLS 인증을 위해 SRP(Secure Remote Password) 프로토콜 사용"TLS-SRP 암호 제품군을 정의합니다.
  • RFC 5077: "서버측 상태 없이 전송 계층 보안(TLS) 세션 재개".
  • RFC 5081: "TLS(Transport Layer Security) 인증을 위해 OpenPGP Keys 사용", RFC 6091에 의해 폐지되었습니다.
  • RFC 5216: "EAP-TLS 인증 프로토콜"

TLS 1.0의 확장 기능은 다음과 같습니다.

  • RFC 2595: "IMAP, POP3 및 ACAP와 TLS 사용"서버와 클라이언트가 인터넷을 통해 인증된 개인 통신을 제공하기 위해 전송 계층 보안을 사용할 수 있도록 IMAP, POP3 및 ACAP 서비스에 대한 확장을 지정합니다.
  • RFC 2712: "전송 계층 보안(TLS)에 Kerberos Cipher Suite 추가".이 메모에 정의된 40비트 암호 모음은 암호 모음 코드가 이미 할당되었다는 사실을 문서화하기 위한 목적으로만 표시됩니다.
  • RFC 2817: "HTTP/1.1 내 TLS로 업그레이드"에서는 HTTP/1.1의 업그레이드 메커니즘을 사용하여 기존 TCP 연결을 통해 TLS(Transport Layer Security)를 시작하는 방법을 설명합니다.따라서 보안되지 않은 HTTP 트래픽과 보안된 HTTP 트래픽이 동일한 잘 알려진 포트를 공유할 수 있습니다(이 경우 https: 443이 아닌 http: 80에서).
  • RFC 2818: "HTTP Over TLS"는 보안 트래픽과 안전하지 않은 트래픽을 다른 '서버 포트'를 사용하여 구분합니다.
  • RFC 3207: "SMTP over Transport Layer Security를 위한 SMTP 서비스 확장"SMTP 서버와 클라이언트가 전송 계층 보안을 사용하여 인터넷을 통해 인증된 개인 통신을 제공할 수 있도록 SMTP 서비스에 대한 확장을 지정합니다.
  • RFC 3268: "TLS를 위한 AES 암호 소송".기존의 대칭 암호에 AES(Advanced Encryption Standard) 암호 모음을 추가합니다.
  • RFC 3546: "TLS(Transport Layer Security) 확장"은 세션 초기화 동안 프로토콜 확장을 협상하기 위한 메커니즘을 추가하고 일부 확장을 정의합니다.RFC 4366에 의해 쓸모없게 되었습니다.
  • RFC 3749: "Transport Layer Security Protocol Compression Methods"는 압축 방법에 대한 프레임워크와 DEFLATE 압축 방법을 명시합니다.
  • RFC 3943: "Lempel-Ziv-Stac(LZS)을 사용한 TLS(Transport Layer Security) 프로토콜 압축"
  • RFC 4132: "TLS(Transport Layer Security)에 카멜리아 암호 스위트 추가".
  • RFC 4162: "전송 계층 보안(TLS)에 SEED 암호 스위트 추가".
  • RFC 4217: "TLS로 FTP 보안".
  • RFC 4279: "TLS(Pre-Shared Key Cypersuites for Transport Layer Security)"는 TLS 프로토콜을 위한 세 세트의 새로운 암호 모음을 추가하여 사전 공유 키를 기반으로 한 인증을 지원합니다.

정보성 RFC

  • RFC 7457: "TLS(Transport Layer Security) 및 DTLS(Datagram TLS)에 대한 알려진 공격 요약"
  • RFC 7525: "TLS(Transport Layer Security)와 DTLS(Datagram Transport Layer Security)의 안전한 사용을 위한 권장사항"

참고 항목

참고문헌

  1. ^ 예를 들면
  2. ^ a b Lawrence, Scott; Khare, Rohit (May 2000). "Upgrading to TLS Within HTTP/1.1". Internet Engineering Task Force. doi:10.17487/RFC2817. Retrieved 15 December 2018.
  3. ^ "SSL/TLS in Detail". TechNet. Microsoft Docs. October 8, 2009. Retrieved 2021-10-24.
  4. ^ a b Hooper, Howard (2012). CCNP Security VPN 642-648 Official Cert Guide (2 ed.). Cisco Press. p. 22. ISBN 9780132966382.
  5. ^ a b Spott, Andrew; Leek, Tom; et al. "What layer is TLS?". Information Security Stack Exchange.
  6. ^ a b c d e f E. Rescorla (August 2018). The Transport Layer Security (TLS) Protocol Version 1.3. IETF TLS workgroup. doi:10.17487/RFC8446. RFC 8446. 제안된 표준.RFC 5077, 52466961을 폐지하고 RFC 57056066을 업데이트합니다.
  7. ^ Rescorla, Eric; Modadugu, Nagendra (April 2006). Datagram Transport Layer Security. doi:10.17487/RFC4347. RFC 4347.
  8. ^ Rescorla, Eric; Modadugu, Nagendra (January 2012). Datagram Transport Layer Security Version 1.2. doi:10.17487/RFC6347. RFC 6347.
  9. ^ Titz, Olaf (2001-04-23). "Why TCP Over TCP Is A Bad Idea". Retrieved 2015-10-17.
  10. ^ Honda, Osamu; Ohsaki, Hiroyuki; Imase, Makoto; Ishizuka, Mika; Murayama, Junichi (October 2005). "Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency". In Atiquzzaman, Mohammed; Balandin, Sergey I (eds.). Performance, Quality of Service, and Control of Next-Generation Communication and Sensor Networks III. Vol. 6011. Bibcode:2005SPIE.6011..138H. CiteSeerX 10.1.1.78.5815. doi:10.1117/12.630496. S2CID 8945952.
  11. ^ RFC 4347 § 4
  12. ^ Rescorla, Eric; Tschofenig, Hannes; Modadugu, Nagena (April 21, 2022). "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3".
  13. ^ "AnyConnect FAQ: tunnels, reconnect behavior, and the inactivity timer". Cisco. Retrieved 26 February 2017.
  14. ^ "Cisco InterCloud Architectural Overview" (PDF). Cisco Systems.
  15. ^ "OpenConnect". OpenConnect. Retrieved 26 February 2017.
  16. ^ "ZScaler ZTNA 2.0 Tunnel". ZScaler.
  17. ^ "f5 Datagram Transport Layer Security (DTLS)". f5 Networks.
  18. ^ "Configuring a DTLS Virtual Server". Citrix Systems.
  19. ^ "WebRTC Interop Notes". Archived from the original on 2013-05-11.
  20. ^ a b c d e Bright, Peter (17 October 2018). "Apple, Google, Microsoft, and Mozilla come together to end TLS 1.0". Retrieved 17 October 2018.
  21. ^ a b c d "Here is what is new and changed in Firefox 74.0 Stable - gHacks Tech News". www.ghacks.net. 10 March 2020. Retrieved 2020-03-10.
  22. ^ a b c d "TLS 1.0 and TLS 1.1 - Chrome Platform Status". chromestatus.com. Retrieved 2020-03-10.
  23. ^ a b c d e T. Dierks; E. Rescorla (August 2008). The Transport Layer Security (TLS) Protocol Version 1.2. IETF TLS workgroup. doi:10.17487/RFC5246. RFC 5246. 제안된 표준, 구식입니다.RFC 8446에 의해 폐지됨; RFC 3268, 43464366을 폐지함; RFC 4492를 업데이트함.
  24. ^ a b "Using TLS to protect data". www.ncsc.gov.uk. Archived from the original on July 21, 2021. Retrieved August 24, 2022.
  25. ^ "TLS 1.3: One Year Later". IETF. Archived from the original on July 8, 2020. Retrieved August 24, 2022.
  26. ^ "Creating TLS: The Pioneering Role of Ruth Nelson".
  27. ^ Woo, Thomas Y. C.; Bindignavle, Raghuram; Su, Shaowen; Lam, Simon S. (June 1994). SNP: An interface for secure network programming (PDF). Proceedings USENIX Summer Technical Conference.
  28. ^ Messmer, Ellen. "Father of SSL, Dr. Taher Elgamal, Finds Fast-Moving IT Projects in the Middle East". Network World. Archived from the original on 31 May 2014. Retrieved 30 May 2014.
  29. ^ Greene, Tim. "Father of SSL says despite attacks, the security linchpin has lots of life left". Network World. Archived from the original on 31 May 2014. Retrieved 30 May 2014.
  30. ^ a b Oppliger, Rolf (2016). "Introduction". SSL and TLS: Theory and Practice (2nd ed.). Artech House. p. 13. ISBN 978-1-60807-999-5. Retrieved 2018-03-01 – via Google Books.
  31. ^ "THE SSL PROTOCOL". Netscape Corporation. 2007. Archived from the original on 14 June 1997.
  32. ^ 레스콜라 2001
  33. ^ "POODLE: SSLv3 vulnerability (CVE-2014-3566)". Archived from the original on 5 December 2014. Retrieved 21 October 2014.
  34. ^ "Security Standards and Name Changes in the Browser Wars". Retrieved 2020-02-29.
  35. ^ Laura K. Gray (2015-12-18). "Date Change for Migrating from SSL and Early TLS". Payment Card Industry Security Standards Council blog. Retrieved 2018-04-05.
  36. ^ "Changes to PCI Compliance are Coming June 30. Is Your Ecommerce Business Ready?". Forbes. Retrieved 2018-06-20.
  37. ^ T. Dierks; E. Rescorla (April 2006). The Transport Layer Security (TLS) Protocol Version 1.1. IETF TLS workgroup. doi:10.17487/RFC4346. RFC 4346. 역사적인.RFC 5246에 의해 폐지됨; RFC 2246을 폐지함.
  38. ^ a b c "Transport Layer Security Parameters - Cipher Suites". Internet Assigned Numbers Authority (IANA). Retrieved 2022-12-16.
  39. ^ "Twitter will deprecate support for TLS 1.0, TLS 1.1 on July 15". Hashed Out by The SSL Store. 2019-07-12. Retrieved 14 June 2021.
  40. ^ Mackie, Kurt. "Microsoft Delays End of Support for TLS 1.0 and 1.1 -". Microsoft Certified Professional Magazine Online.
  41. ^ "TLS 1.2 FAQ – Knowledge Base". Answers.psionline.com. Retrieved 20 February 2022.
  42. ^ "Differences between TLS 1.2 and TLS 1.3 (#TLS13)". WolfSSL. 2019-09-18. Archived from the original on 2019-09-19. Retrieved 2019-09-18.
  43. ^ "NSS 3.29 release notes". Mozilla Developer Network. February 2017. Archived from the original on 2017-02-22.
  44. ^ "Enable TLS 1.3 by default". Bugzilla@Mozilla. 16 October 2016. Retrieved 10 October 2017.
  45. ^ "Firefox — Notes (60.0)". Mozilla. Retrieved 2018-05-10.
  46. ^ "ProxySG, ASG and WSS will interrupt SSL connections when clients using TLS 1.3 access sites also using TLS 1.3". BlueTouch Online. 16 May 2017. Archived from the original on 12 September 2017. Retrieved 11 September 2017.
  47. ^ 설리번 2017.
  48. ^ Thomson & Pauly 2021, A.6. TLS.
  49. ^ Thomson & Pauly 2021, 3.3. 활성 사용 변조.
  50. ^ "TLS 1.3 IETF 100 Hackathon". Archived from the original on 2018-01-15.
  51. ^ a b IETF – Internet Engineering Task Force (2017-11-12), IETF Hackathon Presentations and Awards, archived from the original on 2021-10-28, retrieved 2017-11-14
  52. ^ "Hurrah! TLS 1.3 is here. Now to implement it and put it into software". Retrieved 2018-03-28.
  53. ^ IETF - Internet Engineering Task Force (2018-07-15), IETF102-HACKATHON-20180715-1400, archived from the original on 2021-10-28, retrieved 2018-07-18
  54. ^ "wolfSSL TLS 1.3 BETA Release Now Available". info@wolfssl.com. 11 May 2017. Retrieved 11 May 2017.
  55. ^ "TLS 1.3 PROTOCOL SUPPORT". info@wolfssl.com.
  56. ^ "TLS 1.3 Draft 28 Support in wolfSSL". info@wolfssl.com. 14 June 2018. Retrieved 14 June 2018.
  57. ^ "OpenSSL 1.1.1 Is Released". Matt Caswell. 11 Sep 2018. Retrieved 19 Dec 2018.
  58. ^ "Protocols in TLS/SSL (Schannel SSP)". Microsoft Docs. May 25, 2022. Retrieved 21 February 2023.
  59. ^ Hoffman-Andrews, Jacob (2019-02-26). "ETS Isn't TLS and You Shouldn't Use It". Electronic Frontier Foundation. Retrieved 2019-02-27.
  60. ^ TS 103 523-3 - V1.1.1 - CYBER; Middlebox Security Protocol; Part 3: Profile for enterprise network and data centre access control (PDF). ETSI.org. Archived (PDF) from the original on November 14, 2018.
  61. ^ Cory Doctorow (February 26, 2019). "Monumental Recklessness". Boing Boing. Archived from the original on February 27, 2019.
  62. ^ Rea, Scott (2013). "Alternatives to Certification Authorities for a Secure Web" (PDF). RSA Conference Asia Pacific. Archived (PDF) from the original on 7 October 2016. Retrieved 7 September 2016.
  63. ^ "Counting SSL certificates". Archived from the original on 16 May 2015. Retrieved 20 February 2022.
  64. ^ Raymond, Art (3 August 2017). "Lehi's DigiCert swallows web security competitor in $1 billion deal". Deseret News. Retrieved 21 May 2020.
  65. ^ "Market share trends for SSL certificate authorities". W3Techs. Retrieved 21 May 2020.
  66. ^ Ryan Singel (March 24, 2010). "Law Enforcement Appliance Subverts SSL". wired.com. Archived from the original on April 12, 2014.
  67. ^ Seth Schoen (March 24, 2010). "New Research Suggests That Governments May Fake SSL Certificates". EFF.org. Archived from the original on March 25, 2010.
  68. ^ P. Eronen, Ed. (December 2005). Eronen, P; Tschofenig, H (eds.). "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)". Internet Engineering Task Force. doi:10.17487/RFC4279. RFC 4279. Archived from the original on 5 September 2013. Retrieved 9 September 2013.
  69. ^ D. Taylor, Ed. (November 2007). "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". Internet Engineering Task Force. doi:10.17487/RFC5054. RFC 5054. Archived from the original on December 7, 2014. Retrieved December 21, 2014.
  70. ^ Gothard, Peter (31 July 2013). "Google updates SSL certificates to 2048-bit encryption". Computing. Incisive Media. Archived from the original on 22 September 2013. Retrieved 9 September 2013.
  71. ^ "The value of 2,048-bit encryption: Why encryption key length matters". SearchSecurity. Archived from the original on 2018-01-16. Retrieved 2017-12-18.
  72. ^ Sean Turner (September 17, 2015). "Consensus: remove DSA from TLS 1.3". Archived from the original on October 3, 2015.
  73. ^ RFC 8422
  74. ^ RFC 5288, 5289
  75. ^ RFC 6655, 7251
  76. ^ RFC 6367
  77. ^ RFC 5932, 6367
  78. ^ a b RFC 6209
  79. ^ RFC 4162
  80. ^ "On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN" (PDF). 2016-10-28. Archived (PDF) from the original on 2017-04-24. Retrieved 2017-06-08.
  81. ^ "NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised)" (PDF). 2007-03-08. Archived from the original (PDF) on June 6, 2014. Retrieved 2014-07-03.
  82. ^ a b c Qualys SSL Labs. "SSL/TLS Deployment Best Practices". Archived from the original on 4 July 2015. Retrieved 2 June 2015.
  83. ^ RFC 5469
  84. ^ RFC 7905
  85. ^ "Http vs https". Archived from the original on 2015-02-12. Retrieved 2015-02-12.
  86. ^ a b c d 2022년 5월 7일 기준.
  87. ^ a b ivanr (19 March 2013). "RC4 in TLS is Broken: Now What?". Qualsys Security Labs. Archived from the original on 2013-08-27. Retrieved 2013-07-30.
  88. ^ a b c Bodo Möller, Thai Duong & Krzysztof Kotowicz. "This POODLE Bites: Exploiting The SSL 3.0 Fallback" (PDF). Archived (PDF) from the original on 2014-10-14. Retrieved 2014-10-15.
  89. ^ "Internet Explorer 11 has retired and is officially out of support—what you need to know". June 15, 2022. Retrieved 2022-06-15.
  90. ^ "Internet Explorer 11 desktop app support ended for certain versions of Windows 10". Retrieved 2022-06-17.
  91. ^ "Java Secure Socket Extension (JSSE) Reference Guide". Oracle Help Center. Retrieved 2021-12-24.
  92. ^ Georgiev, Martin; Iyengar, Subodh; Jana, Suman; Anubhai, Rishita; Boneh, Dan; Shmatikov, Vitaly (2012). The most dangerous code in the world: validating SSL certificates in non-browser software. Proceedings of the 2012 ACM conference on Computer and communications security (PDF). Association for Computing Machinery. pp. 38–49. ISBN 978-1-4503-1651-4. Archived (PDF) from the original on 2017-10-22.
  93. ^ Audet, F. (2009). The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP). doi:10.17487/RFC5630. RFC 5630.
  94. ^ Sheffer, Y.; Holz, R.; Saint-Andre, P. (2015). Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). doi:10.17487/RFC7457. RFC 7457.
  95. ^ "CVE – CVE-2009-3555". Archived from the original on 2016-01-04.
  96. ^ Rescorla, Eric (2009-11-05). "Understanding the TLS Renegotiation Attack". Educated Guesswork. Archived from the original on 2012-02-11. Retrieved 2009-11-27.
  97. ^ "SSL_CTX_set_options SECURE_RENEGOTIATION". OpenSSL Docs. 2010-02-25. Archived from the original on 2010-11-26. Retrieved 2010-11-18.
  98. ^ "GnuTLS 2.10.0 released". GnuTLS release notes. 2010-06-25. Archived from the original on 2015-10-17. Retrieved 2011-07-24.
  99. ^ "NSS 3.12.6 release notes". NSS release notes. 2010-03-03. Archived from the original on March 6, 2012. Retrieved 2011-07-24.
  100. ^ A. Langley; N. Modadugu; B. Moeller (2010-06-02). "Transport Layer Security (TLS) False Start". Internet Engineering Task Force. IETF. Archived from the original on 2013-09-05. Retrieved 2013-07-31.
  101. ^ Gruener, Wolfgang. "False Start: Google Proposes Faster Web, Chrome Supports It Already". Archived from the original on 2010-10-07. Retrieved 2011-03-09.
  102. ^ Smith, Brian. "Limited rollback attacks in False Start and Snap Start". Archived from the original on 2011-05-04. Retrieved 2011-03-09.
  103. ^ Dimcev, Adrian. "False Start". Random SSL/TLS 101. Archived from the original on 2011-05-04. Retrieved 2011-03-09.
  104. ^ Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin; Preneel, Bart (2012). A cross-protocol attack on the TLS protocol. Proceedings of the 2012 ACM conference on Computer and communications security (PDF). Association for Computing Machinery. pp. 62–72. ISBN 978-1-4503-1651-4. Archived (PDF) from the original on 2015-07-06.
  105. ^ "SMACK: State Machine AttaCKs". Archived from the original on 2015-03-12.
  106. ^ Goodin, Dan (2015-05-20). "HTTPS-crippling attack threatens tens of thousands of Web and mail servers". Ars Technica. Archived from the original on 2017-05-19.
  107. ^ Leyden, John (1 March 2016). "One-third of all HTTPS websites open to DROWN attack". The Register. Archived from the original on 1 March 2016. Retrieved 2016-03-02.
  108. ^ a b "More than 11 million HTTPS websites imperiled by new decryption attack". Ars Technica. March 2016. Archived from the original on 2016-03-01. Retrieved 2016-03-02.
  109. ^ Thai Duong & Juliano Rizzo (2011-05-13). "Here Come The ⊕ Ninjas". Archived from the original on 2014-06-03.
  110. ^ Goodin, Dan (2011-09-19). "Hackers break SSL encryption used by millions of sites". The Register. Archived from the original on 2012-02-10.
  111. ^ "Y Combinator comments on the issue". 2011-09-20. Archived from the original on 2012-03-31.
  112. ^ "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures". 2004-05-20. Archived from the original on 2012-06-30.
  113. ^ Ristic, Ivan (Sep 10, 2013). "Is BEAST Still a Threat?". Archived from the original on 12 October 2014. Retrieved 8 October 2014.
  114. ^ "Chrome Stable Release". Chrome Releases. 2011-10-25. Archived from the original on 2015-02-20. Retrieved 2015-02-01.
  115. ^ "Attack against TLS-protected communications". Mozilla Security Blog. Mozilla. 2011-09-27. Archived from the original on 2015-03-04. Retrieved 2015-02-01.
  116. ^ Smith, Brian (2011-09-30). "(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets-76)".
  117. ^ MSRC (2012-01-10). Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584). Security Bulletins (Technical report). MS12-006. Retrieved 2021-10-24 – via Microsoft Docs.
  118. ^ Ristic, Ivan (Oct 31, 2013). "Apple Enabled BEAST Mitigations in OS X 10.9 Mavericks". Archived from the original on 12 October 2014. Retrieved 8 October 2014.
  119. ^ Goodin, Dan (2012-09-13). "Crack in Internet's foundation of trust allows HTTPS session hijacking". Ars Technica. Archived from the original on 2013-08-01. Retrieved 2013-07-31.
  120. ^ Fisher, Dennis (September 13, 2012). "CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions". ThreatPost. Archived from the original on September 15, 2012. Retrieved 2012-09-13.
  121. ^ a b Goodin, Dan (1 August 2013). "Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages". Ars Technica. Condé Nast. Archived from the original on 3 August 2013. Retrieved 2 August 2013.
  122. ^ Leyden, John (2 August 2013). "Step into the BREACH: New attack developed to read encrypted web data". The Register. Archived from the original on 5 August 2013. Retrieved 2 August 2013.
  123. ^ P. Gutmann (September 2014). "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". Internet Engineering Task Force. doi:10.17487/RFC7366. Archived from the original on 2015-05-12.
  124. ^ Langley, Adam (December 8, 2014). "The POODLE bites again". Archived from the original on December 8, 2014. Retrieved 2014-12-08.
  125. ^ "ssl - Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune". Serverfault.com. Retrieved 20 February 2022.
  126. ^ Pouyan Sepehrdad; Serge Vaudenay; Martin Vuagnoux (2011). "Discovery and Exploitation of New Biases in RC4". In Alex Biryukov; Guang Gong; Douglas R. Stinson (eds.). Selected Areas in Cryptography: 17th International Workshop, SAC 2010, Waterloo, Ontario, Canada, August 12-13, 2010, Revised Selected Papers. Lecture Notes in Computer Science. Vol. 6544. pp. 74–91. doi:10.1007/978-3-642-19574-7_5. ISBN 978-3-642-19573-0.
  127. ^ Green, Matthew (12 March 2013). "Attack of the week: RC4 is kind of broken in TLS". Cryptography Engineering. Archived from the original on March 14, 2013. Retrieved March 12, 2013.
  128. ^ AlFardan, Nadhem; Bernstein, Dan; Paterson, Kenny; Poettering, Bertram; Schuldt, Jacob. "On the Security of RC4 in TLS". Royal Holloway University of London. Archived from the original on March 15, 2013. Retrieved March 13, 2013.
  129. ^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (8 July 2013). "On the Security of RC4 in TLS and WPA" (PDF). Information Security Group. Archived (PDF) from the original on 22 September 2013. Retrieved 2 September 2013.
  130. ^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (15 August 2013). On the Security of RC4 in TLS (PDF). 22nd USENIX Security Symposium. p. 51. Archived (PDF) from the original on 22 September 2013. Retrieved 2 September 2013. Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical
  131. ^ Goodin, Dan (15 July 2015). "Once-theoretical crypto attack against HTTPS now verges on practicality". Ars Technical. Conde Nast. Archived from the original on 16 July 2015. Retrieved 16 July 2015.
  132. ^ "Mozilla Security Server Side TLS Recommended Configurations". Mozilla. Archived from the original on 2015-01-03. Retrieved 2015-01-03.
  133. ^ "Security Advisory 2868725: Recommendation to disable RC4". Microsoft. 2013-11-12. Archived from the original on 2013-11-18. Retrieved 2013-12-04.
  134. ^ "Ending support for the RC4 cipher in Microsoft Edge and Internet Explorer 11". Microsoft Edge Team. September 1, 2015. Archived from the original on September 2, 2015.
  135. ^ Langley, Adam (Sep 1, 2015). "Intent to deprecate: RC4".
  136. ^ Barnes, Richard (Sep 1, 2015). "Intent to ship: RC4 disabled by default in Firefox 44". Archived from the original on 2011-01-22.
  137. ^ a b John Leyden (1 August 2013). "Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack". The Register. Archived from the original on 1 August 2013. Retrieved 1 August 2013.
  138. ^ "BlackHat USA Briefings". Black Hat 2013. Archived from the original on 30 July 2013. Retrieved 1 August 2013.
  139. ^ Smyth, Ben; Pironti, Alfredo (2013). Truncating TLS Connections to Violate Beliefs in Web Applications. 7th USENIX Workshop on Offensive Technologies (report). Archived from the original on 6 November 2015. Retrieved 15 February 2016.
  140. ^ AlFardan, Nadhem; Paterson, Kenneth G (2012). Plaintext-recovery attacks against datagram TLS (PDF). Network and distributed system security symposium (NDSS 2012). Archived from the original on 2012-01-18.{{cite conference}}: CS1 maint : URL(링크) 부적합
  141. ^ Goodin, Dan (26 July 2016). "New attack bypasses HTTPS protection on Macs, Windows, and Linux". Ars Technica. Condé Nast. Archived from the original on 27 July 2016. Retrieved 28 July 2016.
  142. ^ Goodin, Dan (August 24, 2016). "HTTPS and OpenVPN face new attack that can decrypt secret cookies". Ars Technica. Archived from the original on August 24, 2016. Retrieved August 24, 2016.
  143. ^ "Why is it called the 'Heartbleed Bug'?". The Washington Post. 2014-04-09. Archived from the original on 2014-10-09.
  144. ^ "Heartbleed Bug vulnerability [9 April 2014]". Comodo Group. Archived from the original on 5 July 2014.
  145. ^ Bleichenbacher, Daniel (August 2006). "Bleichenbacher's RSA signature forgery based on implementation error". Archived from the original on 2014-12-16.
  146. ^ "BERserk". Intel Security: Advanced Threat Research. September 2014. Archived from the original on 2015-01-12.
  147. ^ Goodin, Dan (February 19, 2015). "Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections". Ars Technica. Archived from the original on September 12, 2017. Retrieved December 10, 2017.
  148. ^ Valsorda, Filippo (2015-02-20). "Komodia/Superfish SSL validation is broken". Filippo.io. Archived from the original on 2015-02-24.
  149. ^ a b Goodin, Dan (26 May 2016). ""Forbidden attack" makes dozens of HTTPS Visa sites vulnerable to tampering". Ars Technica. Archived from the original on 26 May 2016. Retrieved 26 May 2016.
  150. ^ Clark Estes, Adam (February 24, 2017). "Everything You Need to Know About Cloudbleed, the Latest Internet Security Disaster". Gizmodo. Archived from the original on 2017-02-25. Retrieved 2017-02-24.
  151. ^ Diffie, Whitfield; van Oorschot, Paul C; Wiener, Michael J. (June 1992). "Authentication and Authenticated Key Exchanges". Designs, Codes and Cryptography. 2 (2): 107–125. CiteSeerX 10.1.1.59.6682. doi:10.1007/BF00124891. S2CID 7356608. Archived from the original on 2008-03-13. Retrieved 2008-02-11.
  152. ^ "Discussion on the TLS mailing list in October 2007". Archived from the original on 22 September 2013. Retrieved 20 February 2022.
  153. ^ "Protecting data for the long term with forward secrecy". Archived from the original on 2013-05-06. Retrieved 2012-11-05.
  154. ^ Bernat, Vincent (28 November 2011). "SSL/TLS & Perfect Forward Secrecy". Archived from the original on 2012-08-27. Retrieved 2012-11-05.
  155. ^ "SSL Labs: Deploying Forward Secrecy". Qualys.com. 2013-06-25. Archived from the original on 2013-06-26. Retrieved 2013-07-10.
  156. ^ Ristic, Ivan (2013-08-05). "SSL Labs: Deploying Forward Secrecy". Qualsys. Archived from the original on 2013-09-20. Retrieved 2013-08-31.
  157. ^ a b Langley, Adam (27 June 2013). "How to botch TLS forward secrecy". imperialviolet.org. Archived from the original on 8 August 2013.
  158. ^ a b Daignière, Florent. "TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL" (PDF). Matta Consulting Limited. Archived (PDF) from the original on 6 August 2013. Retrieved 7 August 2013.
  159. ^ a b Daignière, Florent. "TLS "Secrets": What everyone forgot to tell you…" (PDF). Matta Consulting Limited. Archived (PDF) from the original on 5 August 2013. Retrieved 7 August 2013.
  160. ^ L.S. Huang; S. Adhikarla; D. Boneh; C. Jackson (2014). "An Experimental Study of TLS Forward Secrecy Deployments". IEEE Internet Computing. 18 (6): 43–51. CiteSeerX 10.1.1.663.4653. doi:10.1109/MIC.2014.86. S2CID 11264303. Archived from the original on 20 September 2015. Retrieved 16 October 2015.
  161. ^ "Protecting data for the long term with forward secrecy". Archived from the original on 2014-02-12. Retrieved 2014-03-07.
  162. ^ Hoffman-Andrews, Jacob. "Forward Secrecy at Twitter". Twitter. Archived from the original on 2014-02-16. Retrieved 2014-03-07.
  163. ^ a b c Durumeric, Zakir; Ma, Zane; Springall, Drew; Barnes, Richard; Sullivan, Nick; Bursztein, Elie; Bailey, Michael; Halderman, J. Alex; Paxson, Vern (5 September 2017). "The Security Impact of HTTPS Interception". NDSS Symposium. doi:10.14722/ndss.2017.23456. ISBN 978-1-891562-46-4.
  164. ^ a b 이러한 인증서는 현재 X.509이지만 RFC 6091에서도 OpenPGP 기반 인증서의 사용을 지정합니다.
  165. ^ "tls - Differences between the terms "pre-master secret", "master secret", "private key", and "shared secret"?". Cryptography Stack Exchange. Retrieved 2020-10-01.
  166. ^ Chris (2009-02-18). "vsftpd-2.1.0 released – Using TLS session resume for FTPS data connection authentication". Scarybeastsecurity. blogspot.com. Archived from the original on 2012-07-07. Retrieved 2012-05-17.
  167. ^ Rescorla, Eric (August 2018). "The Transport Layer Security (TLS) Protocol Version 1.3". IETF RFC Editor.
  168. ^ Valsorda, Filippo (23 September 2016). "An overview of TLS 1.3 and Q&A". The Cloudflare Blog.
  169. ^ Wildcard SSL Certificate overview, archived from the original on 2015-06-23, retrieved 2015-07-02
  170. ^ Named-based SSL virtual hosts: how to tackle the problem (PDF), archived (PDF) from the original on 2012-08-03, retrieved 2012-05-17

인용작품

추가열람

외부 링크