☰

SSLv3 관련 CBC 암호 제거

tag-icon • tag-icon ssl openssl
SSLv3 관련 CBC 암호 제거

SSLv3를 사용해야 하는 레거시 애플리케이션이 있으므로 POODLE 취약점에 대한 임시 솔루션으로 SSLv3 특정 CBC 암호를 비활성화해야 합니다. OPENSSL 문서를 참조한 후에는 SSLv3과 TLSV1 사이에 다음과 같은 공유 암호가 있는 것 같습니다.

  • SSL_DHE_RSA_WITH_DES_CBC_SHA
  • DHE-RSA-DES-CBC-SHA
  • TLS_DHE_RSA_WITH_DES_CBC_SHA
  • DHE-RSA-DES-CBC-SHA

내 질문은 예를 들어 비활성화하는 방법이 있습니까?DHE-RSA-DES-CBC-SHA특히 SSLv3에만 적용되며 이 조치가 TLSv1에 영향을 미치나요?

OPENSSL과 함께 nginx, Varnish 및 Apache를 사용하고 있습니다.

답변1

이 구성은 웹 서버에서 수행되어야 합니다. OpenSSL을 사용하면 프로그래밍 방식으로 암호를 지정할 수만 있습니다.SE 답변.

Apache와 nginx(웹 캐시 Varnish는 SSL을 지원하지 않음)를 사용하고 있다고 말씀하셨기 때문에 이 페이지는 BEAST를 대상으로 하지만 동일한 문제에 대해 설명하고 있는 것으로 나타났습니다.

  1. Apache-Nginx 및 OpenSSL 구성
  2. 웹 서버의 OpenSSL 암호화 제품군 강화

이것은 다음에 관한 것입니다.SSL 종료varnish가 콘텐츠를 캐시할 수 있게 해줍니다:


매우 중요함 추신:

PS1 - 잊지 말고 사용하세요HSTS
PS2 - 암호화된 연결 내에서 생성된 쿠키에는 항상 "보안" 플래그를 설정합니다. 이를 잊어버리는 것은 공격자에게 정보를 유출하는 매우 쉬운 방법입니다.

답변2

정식 답변은 다음과 같습니다.https://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability제외하는 것을 선호합니다.규약암호화가 아닌 SSLv3.

사전에, 귀하가 명명한 두 개의 서로 다른 암호 제품군은 원래 DES를 사용하고 이를 다시 명명했습니다.단일 DES, 그리고모든 프로토콜 버전에서 안전하지 않음. 원래 DES는 10년 전에 교체되고 철회되었습니다. (보다 정확하게 FIPS46-3은 2001년에 FIPS197 AES로 대체된 후 2005년에 철회되었으며, 단일 DEA가 아닌 삼중 DEA만 2004년에 승인되었지만 표준은 아닌 SP800-67로 다시 게시되었습니다.) 이는 LOW로 분류됩니다. openssl의 암호 구성에서 EXPORT(심지어 덜 안전함) 및 eNULL(완전히 안전하지 않음)과 함께절대오래된 화성 착륙선처럼 업그레이드, 교체 또는 프런트엔드가 불가능한 심각하게 노후된 시스템을 처리해야 하는 경우가 아니라면 구성하는 것이 좋습니다.

귀하의 질문에 실제로 SSLv3 관련 CBC 암호는 없습니다.비-SSLv3 것들. openssl에서 허용되는 암호 모음 및 프로토콜의 구성은 별개이며 거의 독립적입니다. AFAICS의 유일한 제약은 새로운 TLSv1.2 기능(인증된 암호화 GCM 또는 SHA-2 해시)을 사용하는 암호를 이전 프로토콜에서 선택할 수 없다는 것과 SSLv2에서 사용되는 몇 가지 암호는 이미 안전하지 않기 때문에 SSLv3+ 코드가 할당되지 않는다는 것입니다. 1996년에는 SSL3+에서 사용할 수 없습니다. 심지어표준에 따르면 암호의 유일한 차이점은SSL3과 TLS1 또는 1.1 사이는 다음과 같습니다.

  • 40비트 EXPORT 암호는 1.1에서 공식적으로 삭제되었지만 openssl은 확장 기능으로 1.1과 1.2에서 여전히 이를 지원합니다. 그러나 그것들은 안전하지 않았으며 1990년대로 시간 여행을 떠나서 법적 제한이 적용되지 않는 한 사용해서는 안 됩니다.일부그럼 장소.

  • "암호화는 무기다" 기간 동안 미국 정부를 달래기 위해 추가되었으며 NSA 외에는 누구도 사용하지 않은 Fortezza 키 교환이 TLS1에 의해 삭제되었습니다. openssl에서는 구현되지 않습니다.어느규약.

  • ECC 암호의 첫 번째 배치https://www.rfc-editor.org/rfc/rfc4492ClientHello의 확장에 의존하기 때문에 TLS1+에만 공식적으로 적용됩니다.https://www.rfc-editor.org/rfc/rfc3546확장의 경우 SSL3을 수정할 수 없지만 openssl >=1.0.0(또는 조정된 경우 일부 0.9.8)은 확장을 기본값으로 "제한 없음"으로 처리하여 SSL3에서 구현합니다. 고의적으로 최근의 openssl을 수정한 것 외에는 그렇지 않을 것입니다. 이것이유용한 암호 차이만 있을 수 있습니다.RSA 인증서 및 개인 키를 가정하면 ECDHE-RSA를 사용할 수 있으며 TLS1+에서만 작동하기를 바랍니다.

이것이 명령줄 openssl ciphers -v [$cipherstring]유틸리티가 SSLv3을 대부분의 암호에 대한 "버전"으로 표시하는 이유입니다. 이는 SSLv3 이상을 의미합니다.

TL-DR:SSL3 전용 클라이언트가 ECC 암호를 협상하지 않는 경우(그리고 최신 클라이언트는 그럴 수 있지만 대부분의 아주 오래된 클라이언트는 아마도 협상하지 않을 것임) 및 모든 TLS1+ 클라이언트~하다(훨씬 덜 확실함) RSA 인증서 및 개인 키의 일반적인 경우를 가정하면 ECDHE-RSA-(3DES 또는 AES)-CBC를 활성화하고 DHE-RSA-anything-CBC 및 RSA-anything-CBC를 비활성화할 수 있습니다. 이는 또한 완벽한 순방향 비밀성을 제공합니다.

원하는 경우 PFS 여부에 관계없이 모든 SSL3+에 대해 RC4를 활성화할 수도 있지만 거기에도 우려 사항이 있습니다.

귀하의 "레거시 애플리케이션"은 웹입니까, 아니면 다른 것입니까? 웹이 절반 수준의 브라우저를 얻을 수 없다면? 맞춤형 앱이 공격자 데이터 이후에 동일한 민감한 데이터를 반복적으로 재전송하도록 할 수 없다면 애초에 "물 수 있는" 것이 아닙니다.

관련 정보