일반

SSL (및 후속 버전 인 TLS )은 TCP 위에서 직접 작동합니다 (UDP와 같은 데이터 그램 기반 프로토콜에 대한 구현도 있음). 이렇게하면 상위 계층의 프로토콜 (예 : HTTP)을 변경하지 않고 그대로 둘 수 있습니다. 보안 연결을 제공 할 때까지. SSL 계층 아래에서 HTTP는 HTTPS와 동일합니다.

SSL / TLS를 올바르게 사용하면 모든 공격자는 케이블에서 사용자가 연결된 IP와 포트, 대략적으로 전송중인 데이터의 양을 볼 수 있습니다. , 사용되는 암호화 및 압축. 그는 또한 연결을 종료 할 수 있지만, 양측은 제 3 자에 의해 연결이 중단되었음을 알 수 있습니다.

일반적인 사용에서 공격자는 사용자가 연결중인 호스트 이름도 알아낼 수 있습니다. (하지만 나머지 URL은 아님) : HTTPS 자체가 호스트 이름을 노출하지는 않지만 일반적으로 브라우저는 요청을 보낼 IP 주소를 찾기 위해 먼저 DNS 요청을해야합니다.

높음 프로토콜에 대한 수준 설명

TCP 연결을 구축 한 후 SSL 핸드 셰이크는 클라이언트에 의해 시작됩니다. 클라이언트 (브라우저 및 Windows Update 또는 PuTTY와 같은 다른 프로그램 일 수 있음)는 다양한 사양 :

• 실행중인 버전의 SSL / TLS
• 사용하려는 암호화 모음 및
• 압축 방법 사용하고자합니다.

서버는 서버와 클라이언트 모두에서 지원하는 가장 높은 SSL / TLS 버전을 식별하고 클라이언트의 옵션 중 하나 (지원하는 경우)에서 암호 모음을 선택하고 선택적으로 압축 방법을 선택합니다.

기본 설정이 완료되면 서버가 인증서를 보냅니다. 이 인증서는 클라이언트 자체 또는 클라이언트가 신뢰하는 당사자가 신뢰해야합니다. 예를 들어 클라이언트가 GeoTrust를 신뢰하는 경우 GeoTrust가 Google 인증서에 암호로 서명 되었으므로 클라이언트는 Google.com의 인증서를 신뢰할 수 있습니다.

인증서를 확인하고이 서버가 실제로 자신이 주장하는 사람 (중간 사람이 아님)임을 확신하면 키가 교환됩니다. 이것은 공개 키일 수 있습니다. ” PreMasterSecret ” 또는 단순히 아무것도 선택하지 않습니다. 이제 서버와 클라이언트 모두 대칭 암호화 ^{왜 PKE가 아닙니까?} . 클라이언트는 이제부터 모든 통신이 암호화 될 것이라고 서버에 알립니다. 암호화되고 인증 된 메시지를 서버로 보냅니다.

서버는 MAC (인증에 사용됨)이 정확하고 메시지를 올바르게 해독 할 수 있는지 확인한 다음 메시지를 반환하여 클라이언트가 확인합니다. 같이 그럼.

이제 핸드 셰이크가 완료되었으며 두 호스트가 안전하게 통신 할 수 있습니다. 자세한 내용은 technet.microsoft.com/en-us/library/cc785811 및 en.wikipedia를 참조하세요. .org / wiki / Secure_Sockets_Layer .

연결을 종료하기 위해 close_notify “경고”가 사용됩니다. 공격자가 TCP 연결을 종료 (FIN 패킷 주입)하여 연결을 종료하려고하면 양쪽 모두 연결이 부적절하게 종료되었음을 알게됩니다. 이로 인해 연결이 손상 될 수는 없으며 단지 중단 될뿐입니다.

자세한 내용

GeoTrust를 신뢰하여 Google.com을 신뢰할 수있는 이유는 무엇입니까?

웹 사이트에서 귀하와 안전하게 통신하기를 원합니다. 신원을 증명하고 공격자가 아닌지 확인하려면 서버의 공개 키 가 있어야합니다. 그러나 모든 키를 저장할 수는 없습니다. 지구상의 모든 웹 사이트에서 데이터베이스는 방대 할 것이며 업데이트는 매 시간마다 실행되어야합니다!

이에 대한 해결책은 인증 기관 (간단히 말해 CA)입니다.운영 체제 나 브라우저를 설치할 때 신뢰할 수있는 CA 목록이 함께 제공되었을 것입니다. 이 목록은 마음대로 수정할 수 있습니다. 신뢰하지 않는 사람을 제거하거나, 다른 사람을 추가하거나, 자신의 CA를 만들 수도 있습니다 (단,이 CA를 신뢰하는 유일한 사람이므로 공개 웹 사이트에는 많이 사용되지 않습니다). 이 CA 목록에는 CA의 공개 키도 저장됩니다.

Google의 서버가 인증서를 보낼 때 GeoTrust에서 서명했다고 언급합니다. GeoTrust를 신뢰하는 경우 GeoTrust가 실제로 서버의 인증서에 서명했는지 확인 (GeoTrust의 공개 키 사용) 할 수 있습니다. 인증서에 직접 서명하려면 GeoTrust에만 알려진 개인 키가 필요합니다. 이렇게하면 공격자가 인증서에 직접 서명 할 수 없으며 Google.com이라고 잘못 주장 할 수 있습니다. 인증서가 1 비트라도 수정되면 서명이 부정확하고 클라이언트가 거부합니다.

공개 키를 알고 있으면 서버에서 신원을 증명 하시겠습니까?

예. 일반적으로 공개 키는 암호화되고 개인 키는 해독됩니다. 서버의 공개 키로 메시지를 암호화하여 전송하고, 서버가 원래 메시지를 반복 할 수 있다면 키를 공개하지 않고 개인 키를 받았음을 증명 한 것입니다.

이것이 바로 그 이유입니다. 공개 키를 신뢰할 수있는 것은 매우 중요합니다. 누구나 개인 / 공개 키 쌍을 생성 할 수 있으며 공격자도 생성 할 수 있습니다. 공격자의 공개 키를 사용하고 싶지 않습니다.

If 신뢰할 수있는 CA 중 하나가 손상되면 공격자는 훔친 개인 키를 사용하여 원하는 웹 사이트의 인증서에 서명 할 수 있습니다. 공격자가 신뢰할 수있는 CA의 개인 키로 자신이 서명 한 위조 인증서를 클라이언트에 보낼 수있는 경우 클라이언트는 “공개 키가 훔친 개인 키로 서명 된 위조 인증서인지 알지 못합니다.

하지만 CA는 그들이 원하는 모든 서버를 신뢰하게 만들 수 있습니다!

예, 이것이 바로 신뢰가되는 곳입니다. in. 인증서를 원하는대로 만들지 않도록 CA를 신뢰해야합니다. Microsoft, Apple 및 Mozilla와 같은 조직이 CA를 신뢰하는 경우 CA는 감사를 받아야합니다. 다른 조직은 감사를 주기적으로 확인하여 모든 것이 제대로 실행되고 있는지 확인합니다.

인증서 발급은 등록자가 인증서가 발급 된 도메인을 소유하고 있음을 증명할 수있는 경우에만 수행됩니다.

메시지 인증을위한이 MAC은 무엇입니까?

모든 메시지는 소위 메시지 인증 코드로 서명됩니다. 또는 줄여서 MAC. 키 및 해싱 암호에 동의하는 경우 내 메시지가 나에게서 오는지 확인할 수 있고 내가 보낸 메시지인지 확인할 수 있습니다.

예 : 올바른 말 배터리 스테이플 ” 및 메시지 ” 예 “, MAC ” 58393 “를 계산할 수 있습니다. MAC과 함께이 메시지를 보내면 (이미 키를 알고 있음) 동일한 계산을 수행하고 계산 된 MAC을 내가 보낸 MAC과 일치시킬 수 있습니다.

공격자가 메시지를 수정할 수 있습니다. 그러나 열쇠를 모릅니다. 그는 정확한 MAC을 계산할 수 없으며 메시지가 인증되지 않았 음을 알게됩니다.

MAC를 계산할 때 시퀀스 번호를 포함하면 재생을 제거 할 수 있습니다. 공격 . SSL이이 작업을 수행합니다.

클라이언트가 키를 보낸 다음 설정에 사용된다고 말씀하셨습니다. 대칭 암호화. 공격자의 사용을 막는 것은 무엇입니까?

서버의 공개 키가 사용합니다. 공개 키가 실제로 서버에 속하고 다른 사람에 속하지 않음을 확인 했으므로 공개 키를 사용하여 키를 암호화 할 수 있습니다. 서버가이를 수신하면 개인 키로 복호화 할 수 있습니다. 다른 사람이 수신하면 복호화 할 수 없습니다.

또한 키 크기가 중요한 이유입니다. 공개 및 비공개 키가 클수록 클라이언트가 서버에 보내는 키를 해독하기가 더 어려워집니다.

SSL을 해독하는 방법

요약하면 :

• 사용자가 인증서 경고를 무시하면 시도해보십시오.
• 응용 프로그램은 다음에서 데이터를로드 할 수 있습니다. 변조 될 수있는 암호화되지 않은 채널 (예 : HTTP)
• HTTP에 제출하도록 HTTPS에 제출하는 보호되지 않은 로그인 페이지는 수정 될 수 있습니다.
• 패치되지 않은 애플리케이션은 BEAST 및 CRIME과 같은 공격에 취약합니다.
• 다른 방법으로 재조정 suc h는 물리적 공격으로 간주됩니다.
• 메시지 길이 및 시간과 같은 사이드 채널 을 활용합니다. 메시지를 작성했습니다.
• 양자 공격 을 기다립니다.

참고 항목 : Ivan Ristic의 SSL에 대한 많은 공격 벡터가있는 체계 ^(png)

상세 :

간단하고 직접적인 것은 없습니다. 방법; SSL은 올바르게 수행되면 안전합니다. 하지만 사용자가 인증서 경고 를 무시하면 공격자가 시도 할 수 있으며 이는 즉시 보안을 손상시킵니다. 사용자가이 작업을 수행하면 공격자는 “인증서를 위조하기 위해 CA의 개인 키가 필요하지 않으며 자신의 인증서 만 보내면됩니다.

다른 방법은 결함이있는 것입니다. 응용 프로그램 (서버 또는 클라이언트 측). 쉬운 예는 웹 사이트입니다. 웹 사이트에서 사용하는 리소스 (예 : 이미지 또는 스크립트) 중 하나가 HTTP를 통해로드되면 더 이상 기밀성을 보장 할 수 없습니다. 보안 페이지 ( 소스 )에서 비보안 리소스를 요청할 때 HTTP Referer 헤더를 보내지 마십시오. 누군가 트래픽을 도청하여 사용자의 위치를 추측 할 수 있습니다. “에서 방문하고 있습니다; 예를 들어 X, Y, Z 이미지가 한 페이지에 사용된다는 것을 알고 있다면 브라우저가 한 번에 세 개의 이미지를 요청하는 것을보고 해당 페이지를 방문하는 것으로 추측 할 수 있습니다. 또한 Javascript를로드 할 때 전체 페이지가 손상 될 수 있습니다. 공격자는 페이지의 모든 스크립트를 실행하여 예를 들어 은행 거래 대상을 수정할 수 있습니다.

이 경우 (HTTP를 통해 리소스가로드 됨) 브라우저는 혼합 콘텐츠 경고를 표시합니다. Chrome , Firefox , Internet Explorer 9

HTTP의 또 다른 트릭은 로그인 페이지가 보안되지 않고 https 페이지에 제출되는 경우입니다. ” 좋습니다. ” 개발자는 아마도 ” 이제 서버 부하를 줄이고 암호는 여전히 암호화되어 전송됩니다! ” 문제는 안전하지 않은 로그인 페이지를 수정하는 도구 인 sslstrip 입니다. 공격자가 읽을 수 있도록 어딘가에 제출합니다.

지난 몇 년 동안 TLS 재협상 취약성 a과 같은 다양한 공격이있었습니다. >, sslsniff , BEAST 및 최근에는 범죄 . 그러나 모든 일반적인 브라우저는 이러한 모든 공격으로부터 보호되므로 최신 브라우저를 실행하는 경우 이러한 취약점은 위험하지 않습니다.

마지막으로 다른 방법을 사용하여 얻을 수 있습니다. SSL이 귀하의 획득을 거부하는 정보. 사용자의 연결을 이미보고 변조 할 수있는 경우 .exe 다운로드 중 하나를 키로거로 대체하거나 단순히 해당 사용자를 물리적으로 공격하는 것이 그리 어렵지 않을 수 있습니다. 암호화는 다소 안전 할 수 있지만 사람은 인적 오류는 여전히 취약한 요소입니다. Verizon의이 백서 에 따르면 데이터 침해의 10 %는 물리적 공격과 관련이 있습니다 (3 페이지 참조). 명심해야 할 부분입니다.

댓글

• ” 키는 대칭 키로 ” 교환됩니다. 패킷 스니퍼를 가진 누군가가 액세스 할 수없는 경우 어떻게됩니까?
• @Yehosef 좋은 질문입니다! 나는 내 대답에서 그것을 설명하는 것을 잊었다. 주위를 둘러 보면 실제로 이것에 관한 질문이 있습니다. security.stackexchange.com/q/6290/10863
• @ 이와 자루 모든 CA는 첫날부터이 작업을 수행합니다. 인증서의 요점은 주어진 도메인에 대한 공개 키를 제공하는 것이고, 그것이 실제로 도메인에 적합한 키임을 증명하기 위해 서명하는 요점입니다. ‘ s Encrypt가해야 할 일을 정확히 수행합니다. 도메인 소유권을 확인하고 증명할 수있는 경우 인증서 (키로)에 서명합니다. 이제 거의 모든 브라우저 인 Let ‘ s Encrypt를 신뢰하는 모든 사용자가 해당 인증서를 신뢰합니다.
• Er, no. TLS는 실제로 TCP 위에 구현됩니다.
• 이 그래픽 SSL 핸드 셰이크 프로세스 를 발견했습니다.

SSL의 일반적인 개념은 이미 다른 질문 (예 : 이것 과 저것 ), 이번에는 자세한 내용을 살펴 보겠습니다. 세부 사항이 중요합니다. 이 답변은 다소 장황 할 것입니다.

역사

SSL은 오랜 역사와 여러 버전을 가진 프로토콜.첫 번째 프로토 타입은 주력 브라우저 인 Netscape Navigator 의 첫 번째 버전을 개발할 때 Netscape에서 나왔습니다 (이 브라우저는 모자이크 (브라우저 전쟁 초기). 새로운 경쟁자에도 불구하고 여전히 분노하고 있습니다. 버전 1은 공개 된 적이 없으므로 어떻게 생겼는지 알 수 없습니다. SSL 버전 2는 여기 에서 읽을 수있는 초안에 설명되어 있습니다. 몇 가지 약점을 가지고 있으며 그 중 일부는 다소 심각한 문제이므로 더 이상 사용되지 않으며 최신 SSL / TLS 구현에서는이를 지원하지 않습니다 (이전에는 기본적으로 비활성화 됨). 가끔 참조하는 경우를 제외하고는 SSL 버전 2에 대해 더 이상 언급하지 않겠습니다.

SSL 버전 3 ( “SSLv3″라고 부름)은 오늘날에도 여전히 작동하고 널리 지원되는 향상된 프로토콜입니다. 여전히 Netscape Communications (또는 현재 소유하고있는 사람)의 자산이지만 프로토콜은 “역사적 RFC”( RFC 6101 )로 게시되었습니다. 한편, 프로토콜은 법적 문제를 피하기 위해 새 이름 으로 표준화되었습니다. 새 이름은 TLS 입니다.

지금까지 세 가지 버전의 TLS가 제작되었으며 각각 전용 RFC : TLS 1.0 , TLS 1.1 및 TLS 1.2 . 이들은 내부적으로 서로 매우 유사하며 SSLv3를 사용하여 구현시 SSLv3 및 세 가지 TLS 버전 모두를 쉽게 지원할 수 있으며 코드의 95 % 이상이 공통됩니다. 그러나 내부적으로 모든 버전은 major.minor 형식의 버전 번호로 지정됩니다. SSLv3은 3.0이고 TLS 버전은 각각 3.1, 3.2 및 3.3입니다. 따라서 TLS 1.0이 때때로 SSL 3.1이라고 부르는 것은 당연합니다 (그리고 정확하지도 않습니다). SSL 3.0과 TLS 1.0은 몇 가지 세부 사항 만 다릅니다. TLS 1.1 및 1.2는 아직 널리 지원되지는 않지만 가능한 약점으로 인해 이에 대한 추진력이 있습니다 ( “BEAST 공격”에 대한 아래 참조). SSLv3 및 TLS 1.0은 “모든 곳”에서 지원됩니다 (IE 6.0도이를 알고 있음).

컨텍스트

SSL은 임의 데이터에 대해 안전한 양방향 터널을 제공하는 것을 목표로합니다. 인터넷을 통해 데이터를 전송하는 잘 알려진 프로토콜 인 TCP 를 고려하십시오. TCP는 IP “패킷”을 통해 작동하며 바이트에 대한 양방향 터널을 제공합니다. 모든 바이트 값에 대해 작동하며 동시에 작동 할 수있는 두 개의 스트림으로 전송합니다. TCP는 데이터를 패킷으로 분할하고,이를 확인하고, 올바른 순서로 다시 조립하는 동시에 중복을 제거하고 손실 된 패킷을 다시 보내는 힘든 작업을 처리합니다. TCP를 사용하는 응용 프로그램의 관점에서 보면 두 개의 스트림이 있고 패킷은 보이지 않습니다. 특히 스트림은 “메시지”로 분할되지 않습니다 (메시지를 원할 경우 자체 인코딩 규칙을 사용하는 것은 애플리케이션에 달려 있습니다. 이것이 바로 HTTP ).

TCP는 “사고”(예 : 불안정한 하드웨어로 인한 전송 오류, 네트워크 정체, 주어진 기지국 범위를 벗어나는 스마트 폰 사용자)가있는 경우에도 신뢰할 수 있습니다. 그러나 전송 매체에 대한 일부 액세스 권한을 가진 악의를 가진 개인 ( “공격자”)은 전송 된 모든 데이터를 읽거나 의도적으로 변경할 수 있으며 TCP는이를 보호하지 않습니다. SSL.

SSL은 신뢰할 수있는 스트림을 제공하는 TCP와 유사한 프로토콜을 통해 작동한다고 가정 합니다. SSL은 손실 된 패킷 등의 재전송을 구현하지 않습니다. 피할 수없는 방식으로 (예를 들어, 그는 케이블을 끊을 수 있음) 통신을 완전히 방해 할 수있는 권한이 있어야하므로 SSL의 역할은 다음과 같습니다.

• 탐지 (공격자가 데이터를 자동으로 변경할 수 없어야 함)
• 데이터 기밀성 보장 ( 공격자는 교환 된 데이터에 대한 지식을 얻지 않아야합니다.

SSL은 이러한 목표를 대규모 (절대적이 아닌) 범위로 수행합니다.

레코드

SSL은 계층화되고 맨 아래 계층은 레코드 프로토콜 . SSL 터널에서 전송되는 모든 데이터는 레코드 로 분할됩니다. 유선 (기본 TCP 소켓 또는 TCP 유사 매체)을 통해 레코드는 다음과 같습니다.

HH V1:V2 L1:L2 데이터

여기서 :

• HH는 레코드의 데이터 유형을 나타내는 단일 바이트입니다.네 가지 유형이 정의됩니다 : change_cipher_spec (20), 경고 (21), 핸드 셰이크 (22) 및 application_data ( 23).
• V1: V2는 2 바이트가 넘는 프로토콜 버전입니다. 현재 정의 된 모든 버전의 경우 V1의 값은 0x03이고 V2의 값은 SSLv3의 경우 0x00, TLS 1.0의 경우 0x01, TLS 1.1의 경우 0x02입니다. TLS 1.2의 경우 0x03입니다.
• L1: L2는 data의 길이 (바이트)입니다 (빅 엔디안 규칙은 사용 : 길이는 256 * L1 + L2). data의 총 길이는 18432 바이트를 초과 할 수 없지만 실제로는 해당 값에 도달 할 수도 없습니다.

따라서 레코드는 5- 바이트 헤더 뒤에 최대 18KB의 데이터가옵니다. data는 대칭 암호화 및 무결성 검사가 적용되는 곳입니다. 레코드가 방출 될 때 발신자와 수신자는 현재 적용되는 암호화 알고리즘과 키에 동의해야합니다. 이 계약은 다음 섹션에서 설명하는 핸드 셰이크 프로토콜을 통해 획득됩니다. 압축 (있는 경우)도 해당 시점에 적용됩니다.

자세한 내용에서 레코드 작성은 다음과 같이 작동합니다.

• 처음에는 전송할 바이트가 있습니다. ; 이들은 애플리케이션 데이터 또는 다른 종류의 바이트입니다. 이 페이로드 는 최대 16384 바이트로 구성되지만 그보다 적을 수 있습니다 (길이 0의 페이로드는 합법적이지만 Internet Explorer 6.0은 전혀 을 좋아하지 않음). .
• 페이로드는 현재 합의 된 압축 알고리즘으로 압축됩니다. 압축은 상태 저장이므로 이전 레코드의 내용에 따라 달라질 수 있습니다. 실제로 압축은 “null”(압축 없음) 또는 “Deflate”( RFC 3749 )이며, 후자는 현재 정중하지만 확실하게 출구를 보여줍니다. 최근의 CRIME 공격 으로 인해 웹 컨텍스트에서 문이 열렸습니다. 압축은 데이터를 줄이는 것을 목표로하지만 일부 불리한 상황에서는 반드시 데이터를 약간 확장해야합니다 ( pigeonhole 원칙 으로 인해). SSL은 최대 1024 바이트의 확장을 허용합니다. 물론, 널 압축은 절대 확장되지 않습니다 (하지만 결코 단축되지 않습니다). Deflate는 구현이 양호한 경우 최대 10 바이트까지 확장됩니다.
• 그러면 압축 된 페이로드가 변경으로부터 보호되고 암호화됩니다. 현재 암호화 및 무결성 알고리즘이 “null”이면이 단계는 작동하지 않습니다. 그렇지 않으면 MAC 가 추가 된 다음 일부 패딩 (암호화 알고리즘에 따라 다름)이 추가되고 결과가 암호화됩니다. 이러한 단계는 다시 일부 확장을 유도합니다. SSL 표준은 추가로 1024 바이트로 제한합니다 (압축 단계의 최대 확장과 결합하면 5 바이트 헤더를 추가해야하는 18432 바이트가됩니다).

MAC는 일반적으로 일반적인 해시 함수 (대부분 MD5, SHA-1 또는 SHA-256) 중 하나를 사용하는 HMAC 입니다. (SSLv3에서 이것은 “진정한”HMAC가 아니라 매우 유사하며 우리가 아는 한 HMAC만큼 안전합니다). 암호화는 CBC 모드 의 블록 암호 또는 RC4 스트림 암호를 사용합니다. 이론적으로는 다른 종류의 모드 또는 알고리즘이 사용될 수 있습니다. 예를 들어 암호화와 무결성 검사를 결합한 이러한 멋진 모드 중 하나가 사용될 수 있습니다. 일부 RFC 도 있습니다. 그러나 실제로 배포 된 구현은 아직이를 알지 못하므로 HMAC 및 CBC를 수행합니다. 결정적으로 MAC이 먼저 계산되어 데이터에 추가되고 결과가 암호화됩니다. 이것은 MAC-then-encrypt이며 실제로는 그다지 좋은 생각이 아닙니다 . MAC은 (압축 된) 페이로드와 시퀀스 번호의 연결을 통해 계산되므로 부지런한 공격자가 레코드를 교환 할 수 없습니다.

Handshake

핸드 셰이크 는 레코드 프로토콜 내에서 재생되는 프로토콜입니다. 목표는 기록에 사용할 알고리즘과 키를 설정하는 것입니다. 메시지 로 구성됩니다. 각 핸드 셰이크 메시지는 4 바이트 헤더, 메시지 유형을 설명하는 1 바이트, 메시지 길이 (빅 엔디안 규칙)로 3 바이트로 시작합니다. 연속적인 핸드 셰이크 메시지는 “handshake”유형으로 태그가 지정된 레코드와 함께 전송됩니다 (각 레코드 헤더의 첫 번째 바이트는 값 22를 가짐).

계층에 유의하십시오. 핸드 셰이크 메시지는 4 개로 완료됩니다. 바이트 헤더는 레코드로 전송되며 각 레코드에는 또한 자체 헤더가 있습니다. 또한 동일한 레코드 내에서 여러 핸드 셰이크 메시지를 보낼 수 있으며 주어진 핸드 셰이크 메시지를 여러 레코드로 분할 할 수 있습니다.핸드 셰이크 메시지를 작성하는 모듈의 관점에서 “레코드”는 바이트를 보낼 수있는 스트림 일뿐입니다. 해당 스트림이 레코드로 실제 분할되는 것을 알지 못합니다.

Full Handshake

처음에는 클라이언트와 서버가 MAC 및 널 압축없이 널 암호화를 “동의”합니다. 즉, 처음 보낼 레코드는 일반 텍스트로 전송되고 보호되지 않습니다.

핸드 셰이크의 첫 번째 메시지는 ClientHello입니다. 클라이언트가 일부 SSL을 수행 할 의도를 나타내는 메시지입니다. “클라이언트”는 상징적 인 역할입니다. “먼저 말하는 파티”를 의미합니다. 따라서 HTTPS 컨텍스트 (HTTP-within-SSL-within-TCP)에서 세 계층 모두 “클라이언트”및 “서버”라는 개념이 있으며 모두 동의합니다 (TCP 클라이언트도 SSL 클라이언트이고 HTTP 클라이언트),하지만 이는 일종의 우연입니다.

ClientHello 메시지에는 다음이 포함됩니다.

• 최대 프로토콜 클라이언트가 지원하고자하는 버전;
• “클라이언트 임의”(32 바이트, 이중 28 바이트는 강력한 암호화 숫자 생성기로 생성됨)
• ” 세션 ID “(클라이언트가 축약 된 핸드 셰이크로 세션을 재개하려는 경우 아래 참조)
• 클라이언트가 알고있는”암호화 제품군 “목록, 클라이언트 기본 설정에 따라 정렬 됨
• 클라이언트가 알고있는 압축 알고리즘 목록 (클라이언트 선호도에 따라 정렬 됨)
• 몇 가지 선택적 확장

A cipher suite 는 암호화 세트에 대한 16 비트 기호 식별자입니다. c 알고리즘. 예를 들어, TLS_RSA_WITH_AES_128_CBC_SHA 암호 모음은 0x002F 값을 가지며 “레코드는 128 비트 키로 HMAC / SHA-1 및 AES 암호화를 사용하며 키 교환은 암호화를 통해 수행됩니다. 서버의 RSA 공개 키가있는 임의의 키입니다.

서버는 ServerHello div를 사용하여 ClientHello에 응답합니다. > 다음을 포함합니다.

• 클라이언트와 서버가 사용할 프로토콜 버전
• “서버 임의”(32 바이트, 28 임의의 바이트)
• 이 연결에 대한 세션 ID
• 사용될 암호 제품군
• 사용될 압축 알고리즘

li>

• 선택적으로 일부 확장 프로그램.

전체 핸드 셰이크는 다음과 같습니다.

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(이 스키마 RFC에서 뻔뻔스럽게 복사되었습니다.)

ClientHello 및 ServerHello가 표시됩니다. 그런 다음 서버는 암호 모음 및 기타 매개 변수에 따라 달라지는 몇 가지 다른 메시지 rs :

• 인증서 : 공개 키를 포함하는 서버의 인증서. 아래에서 더 자세히 알아보세요. 이 메시지는 암호화 제품군이 인증서없이 핸드 셰이크를 요구하는 경우를 제외하고 거의 항상 전송됩니다.
• ServerKeyExchange : 인증서에있는 것이 충분하지 않은 경우 키 교환을위한 일부 추가 값. 특히 “DHE”암호 그룹은 해당 메시지가 필요한 임시 Diffie-Hellman 키 교환을 사용합니다.
• CertificateRequest : 클라이언트가 자체 인증서로 자신을 또한 식별하도록 요청하는 메시지입니다. 이 메시지에는 서버가 클라이언트 인증서의 유효성을 검사하는 데 사용할 신뢰 앵커 ( “루트 인증서”라고도 함)의 이름 목록이 포함되어 있습니다.
• ServerHelloDone : 서버가 완료되고 클라이언트가 이제 말해야 함을 나타내는 마커 메시지 (길이 0).

그러면 클라이언트가 응답해야합니다. with :

• 인증서 : 클라이언트 인증서, 만약 서버가 요청했습니다. 버전 간에는 미묘한 차이가 있습니다 (SSLv3를 사용하는 경우 클라이언트는 인증서가없는 경우이 메시지를 생략해야합니다. TLS 1.0 이상에서는 동일한 상황에서 Certificate를 전송해야합니다. 인증서 목록이 비어있는 메시지).
• ClientKeyExchange : 실제 키 교환의 클라이언트 부분 (예 : 서버 RSA 키로 암호화 된 임의의 값).
• CertificateVerify : a 디지털 서명 은 이전의 모든 핸드 셰이크 메시지에 대해 클라이언트가 계산합니다. 이 메시지는 서버가 클라이언트 인증서를 요청하고 클라이언트가이를 준수 할 때 전송됩니다. 이것은 클라이언트가 자신이 보낸 인증서에 인코딩 된 공개 키를 실제로 “소유”하고 있음을 서버에 증명하는 방법입니다.

그런 다음 클라이언트는 ChangeCipherSpec 메시지는 핸드 셰이크 메시지가 아닙니다. 자체 레코드 유형이 있으므로 자체 레코드로 전송됩니다.그 내용은 순전히 상징적입니다 (값 1의 단일 바이트). 이 메시지는 클라이언트가 새로 협상 된 암호 그룹 및 키로 전환하는 지점을 표시합니다. 그러면 클라이언트의 후속 레코드가 암호화됩니다.

완료 됨 메시지는 계산 된 암호화 체크섬입니다. 이전의 모든 핸드 셰이크 메시지 (클라이언트와 서버 모두에서). ChangeCipherSpec 이후에 방출되기 때문에 무결성 검사 및 암호화에도 적용됩니다. 서버가 해당 메시지를 수신하고 내용을 확인하면 실제로 동일한 클라이언트와 계속 대화했다는 증거를 얻습니다. 이 메시지는 핸드 셰이크가 변경되지 않도록 보호합니다 (공격자는 핸드 셰이크 메시지를 수정할 수없고 여전히 Finished 메시지 권한을 얻음).

서버는 마침내 자체 ChangeCipherSpec 다음에 Finished. 이 시점에서 핸드 셰이크가 완료되고 클라이언트와 서버가 애플리케이션 데이터를 교환 할 수 있습니다 (그대로 태그가 지정된 암호화 된 레코드에서).

기억할 사항 : 클라이언트는 제안 하지만 서버는 선택 합니다. 암호 제품군은 서버가 담당합니다. 정중 한 서버는 가능한 경우 클라이언트의 기본 설정을 따라야하지만 그렇지 않은 경우도 있고 일부는 실제로 수행합니다 (예 : BEAST에 대한 보호의 일부로).

축약 된 핸드 셰이크

전체 핸드 셰이크에서 서버는 “세션 ID”(최대 32 바이트)를 클라이언트에 보냅니다. 나중에 클라이언트가 돌아와서 ClientHello의 일부로 동일한 세션 ID를 보낼 수 있습니다. 이는 클라이언트가 이전 핸드 셰이크의 암호 모음과 키를 여전히 기억하고 있으며 이러한 매개 변수를 재사용하려고 함을 의미합니다. 서버가 또한 암호 그룹과 키를 기억하는 경우 ServerHello에서 특정 세션 ID를 복사 한 다음 축약 된 악수 :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

축약 된 악수는 더 짧습니다. 비대칭 암호화 비즈니스, 그리고 가장 중요한 것은 지연 시간 감소 입니다. 웹 브라우저와 서버는이를 많이 수행합니다. 일반적인 웹 브라우저는 완전한 핸드 셰이크를 사용하여 SSL 연결을 연 다음 동일한 서버에 대한 다른 모든 연결에 대해 축약 된 핸드 셰이크를 수행합니다. 다른 연결은 병렬로 열리는 다른 연결과 동일한 서버에 대한 후속 연결도 수행합니다. 실제로 일반적인 웹 서버는 15 초 동안 활동이 없으면 연결을 닫지 만 세션 (암호화 모음 및 키)을 훨씬 더 오래 (아마도 몇 시간 또는 며칠 동안) 기억합니다.

키 교환

SSL에서 사용할 수있는 몇 가지 키 교환 알고리즘이 있습니다. 이것은 암호 스위트에 의해 지정됩니다. 각 키 교환 알고리즘은 일부 종류의 서버 공개 키와 함께 작동합니다. 가장 일반적인 키 교환 알고리즘은 다음과 같습니다.

• RSA : 서버의 키가 RSA 유형입니다. 클라이언트는 임의의 값 ( ” 48 바이트의 pre-master secret “중 46 개는 임의 임) 서버의 공개 키로 암호화합니다. ServerKeyExchange가 없습니다.
• DHE_RSA : 서버의 키가 RSA 유형이지만 서명. 실제 키 교환은 Diffie-Hellman을 사용합니다. 서버는 DH 매개 변수 (모듈러스, 생성기)와 새로 생성 된 DH 공개 키가 포함 된 ServerKeyExchange 메시지를 보냅니다. 또한 서버는 이 메시지에 서명 합니다. 클라이언트는 새로 생성 된 DH 공개 키도 포함하는 ClientKeyExchange 메시지로 응답합니다. DH는 “사전 마스터 암호를 생성합니다. “.
• DHE_DSS : DHE_RSA와 같지만 서버에 DSS 키가 있습니다 (“DSS “는 as “DSA”). DSS는 서명 전용 알고리즘입니다.

덜 일반적으로 사용되는 키 교환 알고리즘은 다음과 같습니다.

• DH : 서버의 키는 Diffie-Hellman 유형입니다 (우리는 다음을 포함하는 인증서 에 대해 이야기하고 있습니다. DH 키). 이는 RSA 특허가 여전히 활성화되었을 때 (이는 지난 세기 동안) 행정적 방식 (미국 연방 정부가 사용을 의무화 함)에서 “인기 적”이었습니다. 관료적 추진에도 불구하고 RSA만큼 널리 배포되지는 않았습니다.
• DH_anon : DHE 제품군처럼 그러나 서버의 서명이 없습니다. 이것은 인증서가없는 암호 제품군입니다. 구성 상 중간자 공격 에 취약하므로 거의 활성화되지 않습니다.
• PSK : 사전 공유 키 암호 모음. 미리 설정된 공유 비밀을 기반으로하는 대칭 전용 키 교환입니다.
• SRP : iv id = “인 SRP 프로토콜 의 애플리케이션 2672cb5fc2 “>

이후 이전 답변 에서 SSL에 대한 긴 표현, 재미있는 부분, 즉 :

SSL에 대한 공격

SSL에 대한 많은 공격이 있었고 일부는 구현 오류를 기반으로하고 다른 일부는 실제 프로토콜 약점에 대한 공격이있었습니다.

SSL은 가장 공격받는 프로토콜 중 하나이지만 (매우 높은 프로필이기 때문에 : SSL에 대한 성공적인 애플리케이션은 연구 기사 요약에서 매우 멋지다 보인다), SSL은 또한 가장 복구 된 프로토콜 중 하나입니다.전송 프로토콜을 공격하는 알려진 모든 방법이 SSL에서 시도되었고 적절한 경우 SSL이 패치 되었기 때문에 강력하다고 간주됩니다.

버전 롤백

SSLv3 초기에는 SSLv2가 여전히 널리 사용되어 클라이언트가 일반적으로 SSLv2 호환 메시지는 SSLv3도 지원된다는 것을 나타냅니다. 그런 다음 서버는 힌트를 가져와 SSLv3 + 언어로 응답합니다 (자세한 내용은 RFC 2246 의 부록 E 참조). SSLv2에는 약점이 있었기 때문에 SSLv3을 알고있는 클라이언트와 서버가 SSLv2를 사용하여 서로 대화 할 수 있도록 준비하는 것이 공격자의 가장 큰 이익이었습니다. 이를 버전 롤백 공격 이라고합니다. 이 개념은 공식적으로 이후 버전으로도 확장됩니다.

롤백 시도를 감지하기 위해 Kludges가 추가되었습니다. Back-to-SSLv2 롤백의 경우 SSLv3 +를 알고있는 클라이언트는 RSA 암호화 단계 (SSLv2는 RSA 기반 키 교환 만 지원)에 특수 패딩을 사용해야합니다. PKCS # 1 , 암호화 될 데이터는 임의의 바이트 수로 채워 져야합니다. SSLv3 인식 클라이언트는 마지막 8 개의 패딩 바이트 각각을 고정 값 0x03으로 설정해야합니다. 그런 다음 서버는 이러한 바이트를 확인합니다. 8 개의 0x03이 발견되면 롤백이 시도되고 서버는 시도를 거부합니다 (SSLv2 전용 클라이언트는 이러한 패딩 바이트를 사용할 수있는 가능성이 255 ^-8 에 불과합니다. 운이 좋으므로 오탐은 무시할 수있는 비율로 발생합니다.

이전 버전의 SSL / TLS로 롤백하지만 SSLv3보다 오래되지 않은 경우 다른 kludge가 추가되었습니다. 사전 마스터 비밀 클라이언트가 서버의 RSA 키로 암호화하는 48 바이트 중 처음 2 바이트는 무작위가 아니지만 클라이언트가 메시지. 안타깝게도 일부 클라이언트에서는 오류가 발생했으며이 kludge는 RSA 기반 키 교환에서만 작동하므로 롤백에 대한 보호가 매우 제한되어 있습니다. 다행히 SSLv3 +에는 롤백, 즉 Finished 메시지가 작성 될 때 핸드 셰이크 메시지가 함께 해시됩니다. “이전 버전”이 너무 약해서 공격자가 핸드 셰이크 자체가 끝나기 전에 전체 암호화를 완전히 깰 수있는 경우를 제외하고는 롤백을 방지합니다. 아직 발생하지 않았습니다 (SSLv3는 여전히 상당히 강력합니다).

약한 암호 제품군

일부 표준 암호 그룹은 어떤 식 으로든 의도적으로 약합니다. 다음이 있습니다.

• 암호화가 전혀없는 일부 암호 그룹, 무결성 검사 만 있습니다. TLS_RSA_WITH_NULL_SHA;
• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5와 같은 40 비트 암호화를 사용하는 일부 암호 제품군 (암호화 제품군은 지난 세기의 엄격한 미국 수출 규정-이러한 규정은 대부분 Bill Clinton 시대 말에 해제되었습니다.
• . 56 비트 DES는 기존 기술 로 깨질 수 있지만 아마추어에게는 여전히 약간 어렵습니다 (심지어 수백 대의 대학 컴퓨터에 액세스 할 수있는 지루한 학생도 ), 그래서 저는 56 비트 DES를 “중간 강도”로 규정하는 경향이 있습니다.

이는 공격자가 클라이언트와 서버가 동의하도록 강제하는 변형 버전 롤백 공격의 길을 열어줍니다. 약한 암호 제품군에서 공격자가 클라이언트가 발표 한 암호 제품군 목록을 수정한다는 아이디어입니다. 선택한 암호 제품군이 너무 약하여 명백하게 올바른 Finished 메시지입니다. 실제로 SSLv3 +에서 사용되는 MAC (MD5를 기반으로하는 경우에도)은이를 방지 할 수있을만큼 강력합니다. 따라서 여기서는 실제로 걱정할 필요가 없습니다. 또한 여기에 실제 약점이 있다는 것이 제 의견입니다. 클라이언트 나 서버가 약한 암호 제품군을 사용하는 것을 허용하는 경우입니다.

기본적으로 최신 웹 브라우저는 이러한 약한 암호 제품군의 사용을 허용하지 않습니다.

개인 키 도용

SSL 연결이 RSA 키 교환을 사용하는 경우 공격자는 기록의 사본을 보관 한 다음 나중에 (어쩌면 폐기 된 하드 디스크 나 테이프의 모든 백업을 검사하여 몇 달 후) 개인 키의 사본을 얻은 다음이를 풀 수 있습니다. 데이터를 해독하고 해독합니다.

Perfect Forward Secrecy 는 “나중에”대응하는 것입니다. DHE 암호 그룹을 사용하여 얻을 수 있습니다. DHE 암호 스위트에서 핸드 셰이크를 풀기 위해 사용될 수있는 실제 개인 키는 서버의 RSA (또는 DSS) 개인 키가 아니라 임시 Diffie-Hellman 키입니다.일시적이기 때문에 RAM에만 존재했으며 하드 디스크에는 기록되지 않았습니다. 따라서 은밀한 도난에 훨씬 더 탄력적이어야합니다.

따라서 교훈은 일반적으로 가능하면 DHE 암호 모음을 사용하는 것입니다. 백업을 염두에두고 개인 키가 유출되지 않도록해야하지만, 적어도 DHE 제품군은 특히 키 수명이 끝난 후에 발생하는 경우 (즉, 해당 인증서가 더 이상 유효합니다).

인증서 고뇌

전체 인증서 사업은 SSL의 심각한 부분입니다.

기술적으로 SSL은 X.509와는 상당히 독립적입니다. 인증서 체인은 불투명 Blob으로 교환됩니다. 어떤 시점에서 클라이언트는 서버의 공개 키를 사용해야하지만 클라이언트는 적절하다고 판단되는 방식으로 해당 키를 “알 수 있습니다”. SSL을 사용할 수있는 특정 시나리오에서 클라이언트는 이미 서버를 알고 있습니다. “의 공개 키 (코드에 하드 코딩 됨)는 서버에서 보낸 인증서를 무시합니다. 그럼에도 불구하고 일반적인 HTTPS의 경우 클라이언트는 X.509 에 설명 된대로 서버의 인증서 체인을 확인 합니다 ( 주의를 기울여 읽으십시오.)

이는 다음과 같은 여러 공격 벡터를 생성합니다.

• 검증은 다음을 확인하는 것을 수반합니다. 인증서는 현재 날짜에 여전히 유효합니다. 클라이언트 시스템은 현재 날짜를 어떻게 알 수 있습니까? 내부 시계를 사용하고 가능하면 NTP 서버 (in 매우 보호되지 않는 방법입니다!). 클라이언트는 몇 분, 몇 시간, 며칠, 심지어 몇 년 (본 적이 있음)까지 떨어져있을 수 있으며, 어느 정도 강력한 공격자가 NTP 메시지를 조작하여 강제 할 수 있습니다. 몇 년 전에 취소 된 오래된 인증서를 사용하는 공격자입니다. 재미있는 사실에 유의하십시오. SSL “클라이언트 임의”및 “서버 임의”에는 28 개의 임의 바이트와 현지 날짜 및 시간 (4 개 이상)이 포함되어야합니다. 바이트). of time은 시간 기반 공격에 대한 대안의 일부가되었습니다. 실제로이를 확인하는 구현을 알지 못합니다.

• 2003 년경까지 Internet Explorer / Windows에서 인증서 유효성 검사 구현은 “기본 제약 조건”확장을 처리하지 않았습니다. 정확히. 그 결과 100 € 인증서를 가진 누구나 CA 역할을하고 임의로 선택한 이름과 키로 “인증서”를 발급 할 수 있습니다.

• X .509에는 해지 라는 손상 억제 기능이 포함되어 있습니다.이 기능은 암호 학적으로보기 좋게 보이지만 신뢰해서는 안되는 추방 된 인증서 목록을 게시하는 것입니다 (예 : 개인 키가 도난 당했거나 잘못된 이름). 해지는 관련 당사자 (예 : 브라우저)가 대규모 해지 목록 (수 메가 바이트 길이 일 수 있음)을 다운로드하거나 OCSP 서버 에 연락하는 데 동의하는 경우에만 작동합니다. 현대의 브라우저는 이제이를 수행하지만 약간 마지 못해 많은 사람들이 적시에 해지 상태 정보를 얻을 수없는 경우에도 연결을 수락 할 것입니다 (인간 사용자가 환자가 아니기 때문). 전반적인 상황은 수년에 걸쳐 개선되지만 상당히 느립니다.

• 일부 루트 CA는 과거에 약간의 실수를 저질렀습니다 (예 : Comodo 및 DigiNotar). 이로 인해 가짜 인증서가 발급되었습니다 (이름은 www.microsoft.com이지만 개인 키는 Microsoft의 손에 전혀 없습니다 …). 이러한 실수가 발견되고 인증서가 취소되었지만 여전히 몇 가지 불편한 질문을 제기합니다 (예 : 그러한 문제가 있었지만이를 드러내지 않은 다른 CA가 있는지, 더 나쁜 것은 알아 차리지 않았습니까?).

X.509는 알고리즘, 기술, 사양 및위원회의 매우 복잡한 조합이며 올바르게 설정하기가 매우 어렵습니다. C와 같은 보호되지 않는 프로그래밍 언어로 X.509 인증서를 “수동으로”디코딩하는 것은 버퍼 오버플로를 얻는 쉬운 방법입니다.

Bleichenbacher 공격

Daniel Bleichenbacher 는 1998 년 RSA에 대한 멋진 공격을 발견했습니다. RSA로 데이터를 암호화 할 때 (SSL의 ClientKeyExchange 메시지에서 발생하는 것처럼) 암호화 할 데이터는 순서대로 패딩 되어야합니다. RSA 모듈러스와 동일한 길이의 바이트 시퀀스를 만듭니다. 패딩은 대부분 무작위 바이트로 구성되지만 약간의 구조가 있습니다 (특히 패딩 후 처음 두 바이트는 0x00 0x02 여야 함).

복호화시 (서버에서) 패딩은 반드시 발견되고 제거됩니다. 그 당시 서버가 암호를 해독했지만 유효하지 않은 패딩을 얻었을 때 (0x00 0x02 바이트가 존재하지 않음) 경고 메시지 (SSL 사양에 따라)와 함께보고하는 반면 유효한 패딩은 서버는 겉보기에 해독 된 값을 사용하고 핸드 셰이크를 유지합니다.

이러한 종류의 것을 패딩 오라클 이라고합니다. 이를 통해 공격자는 암호화 된 사전 마스터 비밀 인 것처럼 임의의 바이트 시퀀스를 보내고 해당 시퀀스의 암호 해독이 유효한 패딩을 생성하는지 여부를 알 수 있습니다. “단순한 1 비트 정보이지만 교묘하게 만들어진”암호화 된 “문자열을 사용하여) 수백만 건의 요청으로 개인 키를 복구하는 것으로 충분합니다.

해결 방법 : 암호 해독 결과가 유효하지 않은 경우 패딩을 사용하면 서버는 임의의 사전 마스터 보안 비밀을 계속 사용합니다. 그런 다음 나중에 Finished 메시지와 함께 핸드 셰이크가 실패합니다. 현재의 모든 SSL 구현은이를 수행합니다.

패딩 오라클의 역습

패딩 오라클이 발견 된 또 다른 영역은 레코드 자체입니다. CBC 암호화 및 HMAC를 고려하십시오. 암호화 할 데이터는 먼저 MAC 처리 된 다음 결과가 암호화됩니다. CBC 암호화를 사용하는 경우 암호화 할 데이터의 길이는 블록 크기의 배수 여야합니다 (3DES의 경우 8 바이트, AES의 경우 16 바이트) 따라서 일부 구조와 함께 일부 패딩이 적용됩니다.

그 당시 (2002 년 Vaudenay가 공격을 발견했습니다), SSL 구현이 수신을 처리 할 때 d 레코드에서 다음 두 조건에 대해 다른 경고 메시지를 반환했습니다.

• 복호화시 유효한 패딩 구조를 찾을 수 없습니다.
• 복호화시, 유효한 패딩을 찾았지만 MAC이 확인되었고 일치하지 않았습니다.

이것은 패딩 오라클이며 일부 암호화 된 데이터를 복구하는 데 사용할 수 있습니다. 적극적인 공격자가 필요하지만 그렇게 어렵지는 않습니다. Vaudenay가이를 구현했으며 수정 된 SSL 구현이 두 경우 모두 동일한 경고 메시지를 반환하는 경우로 확장되었지만 두 번째 경우에는 MAC을 다시 계산하는 데 시간이 걸리기 때문에 반환하는 데 더 오래 걸렸습니다 (멋진 데모 타이밍 공격 ).

사람들이 배우지 않기 때문에 ASP.NET에서 사용 된 Microsoft의 SSL 구현은 아직 패치되지 않았습니다 .

이 페이지 를 참조하세요. SSL이 encrypt-then-MAC 를 사용했다면 이러한 문제는 피할 수 있었을 것입니다 (잘못된 레코드는 이전에 MAC 수준에서 거부되었을 것입니다. 암호 해독을 고려하더라도).

BEAST

BEAST 공격은 다시 Duong과 Rizzo, 그리고 다시 한 번 오래된 공격의 리메이크입니다 (2002 년 Philip Rogaway에서). 아이디어를 얻으려면 CBC 를 고려하세요. 이 작동 모드에서 각 데이터 블록은 먼저 이전 블록의 암호화 결과와 XOR됩니다. 그리고 이것이 암호화 된 XOR의 결과 입니다. 이것은 블록을 “무작위 화”하고 ECB 모드에서 발견되는 누출을 피하기 위해 수행됩니다. 첫 번째 블록에는 “이전”블록의 경우 첫 번째 블록에 대한 이전 블록의 역할을하는 초기화 벡터 (IV)가 있어야합니다.

공격자가 암호화 할 데이터의 일부 를 제어 할 수 있고 사용될 IV를 예측할 수 있다면 암호화 기계를 또 다른 암호 해독으로 전환 할 수 있습니다. oracle을 사용하여 다른 암호화 된 데이터 (공격자가 선택하지 않음)를 복구합니다. 그러나 SSLv3 및 TLS 1.0에서 공격자는 기록에 대한 IV를 예측할 수 할 수 있습니다 . 따라서 공격자는 구현이 이전 레코드를 빌드하고 전송 한 지점에서 대상 데이터를 “푸시”하기 위해 스트림에서 일부 데이터를 보낼 수 있어야합니다 (일반적으로 16KB 상당 누적 된 데이터), 그러나 다음 데이터 빌드를 시작하지 않았습니다.

TLS 1.1+는 TLS 1.1 (및 후속 버전)에서 레코드 당 임의 IV가 사용되기 때문에 이에 대해 보호됩니다. SSLv3 및 TLS 1.0의 경우 해결 방법은 길이가 0 인 레코드, 즉 길이가 0 인 페이로드가 있지만 MAC 및 패딩 및 암호화가있는 레코드를 보내는 것입니다. MAC은 비밀 키에서 시퀀스를 통해 계산됩니다. 그래서 이것은 난수 생성기의 역할을합니다. 불행히도 IE 6.0은 길이가 0 인 레코드에서 질식합니다. 다른 전략에는 1 / n-1 분할이 포함됩니다 ( n 바이트 레코드는 단일 바이트의 페이로드가있는 레코드와 나머지 n-1 의 레코드로 전송됩니다.) >).

또 다른 해결 방법은 가능한 경우 비 CBC 암호 제품군을 사용하도록하는 것입니다. 서버는 RC4 기반 암호 제품군이 전송 된 암호 제품군 목록에있는 경우 RC4 기반 암호 제품군을 선택합니다. 클라이언트가 CBC 기반 암호화 제품군을 선호하더라도 클라이언트. 이 도구 는 특정 서버가 그렇게 작동하는지 여부를 알려줍니다.(참고 : BEAST는 클라이언트 에 대한 공격이지만 RC4 암호화 제품군을 선택하면 서버가 부주의 한 클라이언트를 보호 할 수 있습니다.)

이 페이지 를 참조하세요. TLS 1.1은 2006 년에 출시되었지만 BEAST 공격으로 인해 브라우저 공급 업체가 최종적으로 업그레이드 할 수 있습니다.

CRIME

모든 할리우드 프랜차이즈에서 Duong과 Rizzo는 2012 년 속편의 속편을 출판했습니다. CRIME은 몇 년 전에 이론화되었지만 최근에 발표 한 데모에서만 생생하게 입증 된 유출을 악용합니다. CRIME은 BEAST 공격과 동일한 설정에서 압축을 악용합니다 (공격자는 쿠키와 같은 관심 대상 데이터도 전송되는 SSL 연결에서 자체 데이터를 보낼 수 있음). 대략적으로 말하면 공격자는 데이터에 대상 문자열에 대한 잠재적 인 값을 입력하고 일치하는 경우 압축하면 결과 레코드가 더 짧아집니다. (사전인지 적) 분석은 이 질문 을 참조하세요.

범죄는 TLS 수준 압축을 전혀 사용하지 않음으로써 방지됩니다. 지금 브라우저가하는 일. Internet Explorer와 IIS는 처음에 TLS 수준 압축을 구현하지 않았습니다. Firefox와 Chrome은이를 구현하고 올 여름 비활성화했습니다 (활동에 상당한 책임이있는 Duong과 Rizzo가 미리 경고했습니다).

CRIME은 SSL 설명 :

SSL은 이러한 목표를 광범위하게 (절대적이 아닌) 달성합니다.

실제로 암호화는 암호화 된 데이터의 길이 를 유출합니다. 이에 대한 알려진 좋은 해결책은 없습니다. 길이만으로도 많은 것을 알 수 있습니다. 예를 들어 네트워크 모니터로 SSL 연결을 관찰 할 때 스트림 내에서 “추가 핸드 셰이크”를 발견 할 수 있습니다 (각 레코드의 첫 번째 바이트가 레코드의 데이터 유형을 식별하고 암호화되지 않기 때문). 레코드의 길이 를 사용하면 클라이언트가 인증서를 제공했는지 여부를 매우 쉽게 확인할 수 있습니다.

Poodle

( 수정 : 이 섹션이 추가되었습니다. on 2014-10-15)

“Poodle”공격은 CBC 기반 암호화 제품군이있는 SSL 3.0에 특정한 결함을 악용합니다. SSL 3.0의 자주 간과되는 기능에 의존합니다. 대부분의 패딩 바이트는 무시됩니다. TLS 1.0에서는 패딩 (길이를 전체 블록 만 처리하는 CBC 암호화와 호환되도록 레코드에 추가 된 바이트)이 완전히 지정됩니다. 모든 바이트에는 특정 값이 있어야하며 수신자는이를 확인합니다. SSL 3.0에서는 패딩 바이트 콘텐츠가 무시되어 공격자가 대부분 눈에 띄지 않는 변경을 수행 할 수 있습니다. 변경은 적용되지 않는 데이터에만 영향을 주지만 BEAST와 모호하게 유사한 방식으로 복호화 오라클로 사용할 수 있습니다.

자세한 내용은 여기에서 확인할 수 있습니다. 답변 .

미래

인간은 결코 배우지 않습니다. SSL에 멋진 확장 기능을 추가해야한다는 압박이 많습니다. 처음에는 항상 좋아 보이지만 추가 문제를 유발할 수 있습니다.

예를 들어 SSL FalseStart . 주로 이는 클라이언트가 Finished 메시지를 보낸 직후 (전체 핸드 셰이크에서) 대기하지 않고 Finished 메시지. 이것은 좋은 의도의 지연 시간을 줄여줍니다. 그러나 보안 상황이 변경됩니다. 서버에서 Finished 메시지를 수신하기 전에 후자는 암시 적으로 만 인증됩니다 (클라이언트는 아직 의도 한 서버가 실제로 관련되었다는 증거가 없습니다. 모두; 보내는 모든 것이 의도 된 서버에서만 읽을 수 있다는 것을 알고 있습니다.) 이것은 영향을 미칠 수 있습니다. 예를 들어 공격자는 해당 지점까지 서버를 에뮬레이션 할 수 있으며 예를 들어 클라이언트가 CBC 기반 암호화 제품군 또는 TLS 압축을 사용하도록 할 수 있습니다. 따라서 클라이언트가 FalseStart를 구현하면 서버에서 시행 할 수있는 것처럼 BEAST 및 CRIME에 대한 보호 조치의 효율성이 감소합니다.

(Google에서 FalseStart 이번 봄, 일부 서버와의 호환성 문제 때문인 것 같습니다. 어쨌든 FalseStart는 약식 핸드 셰이크가 아닌 전체 핸드 셰이크에만 영향을 미치기 때문에 “30 % 지연 시간 감소”가 이상해 보였습니다. t 이러한 주장 된 이점을 믿으십시오. 적어도 그 정도는 아닙니다.)

댓글

• 좋은 정보를 제공하기 위해 쏟은 노력의 양 이 사이트는 정말 미쳤고 매우 훌륭합니다. 매우 감사합니다.
• tools.ietf도 참조하세요.조직 / HTML / rfc7457