푸들 : 서버에서 SSL V3를 비활성화하는 것이 실제로 해결책입니까?

나는 푸들 취약점에 대해 하루 종일 읽었으며 지금은 보안과 수익에 대해 약간 혼란 스럽습니다.

서버에서 SSL V3을 비활성화하면 (SSL V2 및 V3은 프로토콜을 지원하지 않지만 SSL V3는 서버와 HTTPS를 연결할 수없는 Apache 클라이언트 (브라우저)에 대해 비활성화됩니다.

따라서 클라이언트와 서버 모두 TLS 1.1 1.2와 통신해야하는 상황입니다.

그들 중 하나가 SSL V3을 사용하고 다른 하나가 더 낮은 버전을 지원하지 않으면 어떻게됩니까? SSL에 연결되지 않았습니다.

Firefox에 대한 업데이트가 거의 없었습니다. 아마도 우리가 일반적으로 옵션에서 해야하는 방식으로 SSL V3을 비활성화했을 것입니다. 이렇게하면 모든 연결이 더 낮은 버전 및 TLS에 강제로 적용됩니다.

그러나 SSL V3를 비활성화하면 실제로이 문제에 대한 해결책입니까?

먼저, 정리해 봅시다 :

• TLS가 SSL을 대체했습니다. TLS 1.0이 출시되었으며 SSL 3.0에 대한 업데이트입니다.

  TLS 1.2> TLS 1.1> TLS 1.0> SSL 3.0> SSL 2.0> SSL 1.0

• 3.0 이전의 SSL 버전은 한동안 심각한 보안 취약점으로 알려져 있으며 최신 클라이언트 및 서버에서 지원하지 않거나 지원하지 않습니다. SSL 3.0은 곧 같은 방식으로 진행될 것입니다.

• 현재 사용되는 프로토콜 중에서 "푸들"은 완화 할 방법이없는 SSL 3.0에 가장 큰 영향을 미칩니다. 거기에있다 유사한 공격 일부 TLS 1.0 및 1.1에 대한 구현 소프트웨어가 최신 버전인지 확인 - 사양이 허용하는가.

이제 "푸들"이 최신 클라이언트 및 서버에서도 위험이되는 이유는 클라이언트가 폴백 메커니즘을 구현했기 때문입니다. 모든 서버가 최신 버전을 지원하는 것은 아니므로 클라이언트는 서버가 지원하는 서버를 찾을 때까지 최신 버전 (TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0)에서 각 버전을 순서대로 시도합니다. 이것은 암호화 된 통신이 시작 되기 전에 발생 하므로 MITM (Man-in-the-Middle) 공격자는 서버가 상위 버전을 지원하더라도 브라우저를 이전 버전으로 되돌릴 수 있습니다. 이를 프로토콜 다운 그레이드 공격이라고합니다.

특히 "푸들"의 경우 클라이언트와 서버 모두 SSL 3.0을 지원하는 한 MITM 공격자가이 프로토콜을 강제로 사용할 수 있습니다.

따라서 SSL 3.0을 비활성화하면 두 가지 영향이 있습니다.

• 더 높은 버전을 지원하는 클라이언트는 취약한 버전으로 넘어가도록 속일 수 없습니다 ( TLS Fallback SCSV 는 프로토콜 다운 그레이드 공격을 방지하기 위해 새로 제안 된 메커니즘이지만 모든 클라이언트와 서버에서 아직 지원하지는 않습니다). SSL 3.0을 사용하지 않으려는 이유입니다. 대부분의 고객이이 범주에 속할 가능성이 있으며 이는 유리합니다.

• TLS를 전혀 지원 하지 않는 클라이언트 (다른 사람들이 언급했듯이 XP의 IE6은 HTTPS에 여전히 사용되는 유일한 것임)는 암호화 된 연결을 통해 전혀 연결할 수 없습니다. 이것은 아마도 사용자층의 작은 부분 일 것이므로이 소수를 수용하는 최신의 대다수의 보안을 희생 할 가치가 없습니다.

평가가 정확합니다. SSL 3을 비활성화하면 클라이언트는 최신 프로토콜을 사용하여 서버에 연결해야합니다. SSL 3 프로토콜에 결함이 있으며 "패치"가 없습니다. SSL 3을 사용하지 않는 것이 유일한 솔루션입니다.

이 시점에서 많은 사이트에서 SSL 3을 사용하지 않도록 설정했기 때문에 이전 브라우저 사용자가 업그레이드해야하는 것이 사실상 불가피합니다. 사용자 에이전트 문자열을 로깅한다고 가정하면 로그를 검토하고 SSL 3 비활성화에 대한 정보를 바탕으로 결정을 내릴 수 있다고 가정합니다. 사이트 방문자 중 소수만이 새로운 프로토콜을 처리 할 수없는 브라우저를 사용하고있을 가능성이 높습니다.

[fwiw-cloudflare는 SSLv3에 따라 1.12 %의 사용자가 IE6 XP 사용자임을보고합니다.]

예, SSL3을 비활성화하면 TLS를 지원하지 않는 사용자가 웹 사이트에 액세스 할 수 없습니다.

그러나 실용적인 관점에서 해당 범주에 속하는 브라우저를 살펴보십시오. Chrome과 Firefox는 모두 TLS를 지원하며이 버그로 인해 SSL3 지원도 완전히 중단됩니다. IE는 IE7부터 지원했습니다. 지원되지는 않지만 여전히 전 세계적으로 사용되는 유일한 브라우저는 IE6이며 여전히 사용되는 유일한 이유는 두 가지 이유입니다.

1. XP 버전이 깨져 있고 Chrome 또는 Firefox를 사용하지 않는 사람
2. 브라우저 선택에 관한 제한이있는 회사 또는 정부 정책을 가진 사람.

이 두 경우 모두 IE6는 원래 설치와 함께 제공되는 기본 Windows XP 브라우저이므로 사용됩니다. 또한, IE6이 여전히 세계 시장 점유율이 작은 이유는 중국의 많은 사용자 때문입니다.

간단히 말해, 다음 세 가지 질문이 있습니다.

1. 상당한 중국 사용자층이 있습니까?
2. 귀하의 웹 사이트는 구식이며 고장이 나더라도 IE6을 지원합니까?
3. 귀하의 웹 사이트는 정부 또는 회사에서 브라우저 선택 제한이있는 제품입니까?

이 3 가지 중 하나라도 해당되면 대체 솔루션을 찾아야합니다. 3 개가 모두 거짓이면 비활성화하고 완료하십시오. 그리고 대체 솔루션이 필요한 경우 여전히 IE6를 사용하는 13 세 브라우저에서 전환하는 사용자층의 일부를 설득하기 위해 최선을 다하고 있습니까?

귀하 의 질문에 " Apache "와 " browsers "가 언급 되어 있지만 제목이 더 일반적입니다.

Evan과 다른 사람들이 지적한 것처럼이 문제는 HTTPS에 대해 모두 분류되어 있습니다. 그러나 서버가 암호화 할 수있는 여러 가지 다른 프로토콜이 있으며, TLS 지원은 해당 클라이언트 기반에서 훨씬 나쁩니다 (오늘 아침 IMAP / S 서버에서 "SSL3 없음"을 지시 할 때 알았 음).

답은 " 암호화 된 서비스에 따라 달라지며 클라이언트가 사용자 기반에서 TLS를 지원 " 하는 것이 두렵습니다 .

편집 : 예, 그게 내 요점이지만 동의합니다. sslv3 해제는 서비스별로 수행됩니다. 예를 들어, 비둘기장에서 전원을 끄는 방법은

ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

에서 dovecot.conf. 더 큰 문제는 대부분의 브라우저가 sslv3의 손실을 용인하지만 다른 서비스의 클라이언트는 훨씬 덜 용인되는 것처럼 보입니다. 오늘 아침에 비둘기장에서 전원을 껐을 때 사용자의 약 절반이 고장났습니다. K-9 메일과 Win7에서 Outlook을 실행하는 Android 전화는 내가 아는 두 가지이지만 내 로그에서 더 많은 것을 볼 수 있습니다.

SSLv3을 끄는 것은 여전히 ​​유효한 솔루션 일뿐만 아니라 유일한 솔루션입니다. 하지만 다칠 것입니다.

편집 2 : dave_thompson_085 덕분에 dovecot에서 SSLv3 암호를 비활성화하면 SSLv3 프로토콜뿐만 아니라 TLSv1.0 및 TLSv1.1도 비활성화됩니다. 이전 프로토콜에는없는 암호가 없기 때문입니다. Dovecot (적어도, 내가 실행중인 버전을 포함하는 이전 버전)은 암호 모음이 아닌 프로토콜을 구성하는 기능이 부족한 것으로 보입니다. 이것은 아마도 그렇게 많은 고객을 해친 이유를 설명합니다.

SSLv3를 사용 하지 않는 것이 가장 좋은 해결책이지만 이것이 유일한 해결책이라는 데 동의하지 않습니다. CloudFlare에서 설명한 것처럼 SSLv3 사용량은 매우 적 으므로 대부분의 관리자는이를 끄는 데 아무런 문제가 없습니다.

SSLv3에 대한 사양 요구 사항이 있거나 Windows XP에서 IE6를 지원해야하거나 매우 오래된 소프트웨어를 지원해야하는 경우 다른 완화 방법이 있습니다.

이를 완화하고 SSLv3을 유지하는 방법은 RC4를 사용하고 OpenSSL 1.0.1j에서 제공하는 TLS 대체 SCSV를 지원하는 것입니다. 푸들에 대한 qualys post에서 RC4는 "아무도 언급하고 싶지 않은 확실한 안전하지 않은 스트림 암호"입니다.

이것은 mail.google.com에서 Google이하는 일이며 블로그 항목에도 설명되어 있습니다. http://googleonlinesecurity.blogspot.se/2014/10/this-poodle-bites-exploiting-ssl-30.html

원래의 질문에 근거하여 대화에서 한 가지 세부 사항이 누락되었다는 점에 유의하는 것이 좋습니다. TLS 1.0은 SSL 3.1이라고도합니다. 따라서 원본 포스터는 구성을 확인해야합니다. v3.0 또는 v3.1을 실행하고 있습니까?

대부분의 경우와 마찬가지로 대답은 "의존적"입니다. TLS를 지원하지 않는 "일반적인"사용법의 유일한 브라우저는 IE6입니다. 안타깝게도 여러 보고서에 따르면 IE6이 전체 HTTP 요청의 몇 퍼센트 정도일 수 있다고합니다 ( http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html 참조 ) . 좋은 소식은 북미 지역에서는 미국에서는 비교적 드물다는 것입니다. 안전을 위해 www 로그에서 사용자 에이전트 통계를 확인해야합니다. 필자의 경우 IE6 UA 지문이 너무 적어서 모두 테스트 도구에서 나온 것으로 가정했습니다.

ssllab의 테스터로 웹 사이트를 테스트하여 다양한 에이전트의 반응을 확인할 수 있습니다.

https://www.ssllabs.com/ssltest/

TL; DR-SSLv3이 종료되었습니다. 긴 라이브 TLS.