단일 VirtualHost (푸들)에 대해 Apache에서 SSLProtocol을 설정할 수 있습니까?


13

웹 서버에서 SSLv3를 비활성화 하는 푸들 취약점에 대한 패치를 테스트하려고 합니다. 프로덕션 환경이 아닌 환경에서이를 먼저 테스트하기 위해 다른 테스트 서버의 VirtualHost에서 SSLProtocol을 설정합니다. 내 구성은 다음과 같습니다.

<VirtualHost *:443>
    SSLEngine On
    SSLProtocol All -SSLv2 -SSLv3
    ServerName test.mysite.com
    # bunch of other stuff omitted
</VirtualHost>

그러나 아파치를 다시 시작한 후에도 테스트 사이트는 여전히 취약하다고 주장합니다. 이것이 효과가 있습니까? 전역 SSL 구성에서 설정 해야하는지 또는 설정을 취하지 않거나 작동하지 않는 미묘한 것이 있는지 궁금합니다.

답변:


16

구성 파일에서 첫 번째 VirtualHost에 대해서만 SSLProtocol을 설정할 수 있습니다. 모든 후속 VirtualHost 항목은 첫 번째 항목에서 해당 설정을 상속하며 OpenSSL 버그 로 인해 자체 설정을 자동으로 무시합니다 .

mod_ssl에 해당하는 버그 보고서가 있지만 버그 보고서에 설명 된대로 OpenSSL에서 문제를 해결해야합니다 (인증서는 상속되지만 프로토콜은 아님).

암호 제품군은 각 VirtualHost에 대해 독립적으로 설정해야합니다. 그렇지 않으면 많은 안전하지 않은 암호를 포함하여 기본 목록이 표시됩니다. 또한 SNI (Server Name Indication)를 지원하지 않는 이전 클라이언트는 항상 기본 호스트 (을 사용하여 차단SSLStrictSNIVHostCheck 하지 않은 경우)를 사용하므로 테스트를 혼란스럽게 할 수 있습니다.

요컨대, 각 가상 호스트에 대한 사용자 정의 암호 스위트 및 인증서를 지정할 수 있어야하지만 버그가 수정 될 때까지 각 가상 호스트에 대한 사용자 정의 프로토콜에 대한 올바른 동작을 기대하지는 않습니다.

Apache 2.4와 OpenSSL 1.0.1k의 modssl 에서이 문제가 발생했으며 Apache 2.2에도 동일한 문제가 발생할 것으로 예상됩니다.

업데이트 (2016 년 10 월) : OpenSSL 버그는 2016 년 10 월 13 일에 해결 된 것으로 표시되었습니다. 그러나 이는 공개 문제의 대량 폐쇄의 일부였으며 '부분 수정'이 제공되었지만 문제가 완전히 해결되지는 않았습니다.

업데이트 (2018 년 4 월) : 다시 제출 된 OpenSSL 버그에 패치가 제공됩니다 (2018 년 4 월 9 일 현재). 이 패치는 여러 SNI 가상 호스트로 구성된 Apache 인스턴스의 동작을 변경합니다.

가상 호스트 SSL 프로토콜을 준수하지 않는 연결 거부

이것은 2.4.27로 개발 및 테스트되었으며 해당 버전으로 프로덕션되었습니다. 패치는 2.4.33을 위해 수정되었으며 가볍게 테스트되었습니다.

SNI를 기반으로 일치하는 가상 호스트에 대해 구성된 SSLProtocol에 대한 연결 버전을 확인합니다. 포트의 기본 호스트에 대해 구성된 SSLProtocol을 사용하여 처음 연결되기 때문에 기본 호스트에는 모든 가상 호스트에서 지원할 모든 프로토콜이 포함되어야합니다.

이 패치는 OpenSSL에 등록 된 ssl_callback_ServerNameIndication 콜백이 치명적 경고 SSL_AD_PROTOCOL_VERSION을 리턴 할 수 있도록 APR_EMISMATCH의 추가 리턴 상태를 init_vhost 함수에 추가합니다. 이는 해당 버전을 포함하지 않는 SSLProtocol이 지정되어있는 것과 동일한 응답을 ClientHello에 생성하기위한 것입니다. SNI 콜백은 ClientHello 처리 중 및 응답이 생성되기 전에 호출되므로 정확하게 수행하는 것 같습니다.

갑자기 다음 형식의 메시지가 표시되는 경우 :

Rejecting version [version] for servername [hostname]

그런 다음 SSLProtocol기본 호스트를 다시 확인해야 합니다.


@anx SSLStrictSNIVHostCheck가 추가 한 추가 정보 는 대단히 감사합니다. 그러나 인용 된 문서 에서 다른 가상 호스트에서 on 으로 설정된 경우 SNI를 인식하지 못하는 클라이언트는이 특정 가상 호스트에 액세스 할 수 없습니다 .
vallismortis

5

각 IP 호스트가 다른 IP에서 수신 대기하는 경우 각 호스트마다 다른 SSL 프로토콜을 가질 수 있습니다.

TLSv1을 허용하는 특정 호스트와 TLSv1.1 및 TLSv1.2 만 허용하는 다른 모든 호스트와 TLSv1.2 만 허용하는 호스트가있는 예 :

<VirtualHost *:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3 -TLSv1
  ServerName test.mysite.com
  # bunch of other stuff omitted
</VirtualHost>

<VirtualHost 10.0.0.2:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3
  ServerName test2.mysite.com
</VirtualHost>

<VirtualHost 10.0.0.3:443>
  SSLEngine On
  SSLProtocol TLSv1.2
  ServerName test2.mysite.com
</VirtualHost>

또한 테스트 목적으로 만 필요한 경우 일반 대체 HTTPS 포트와 같은 다른 IP 대신 다른 포트를 사용할 수 있습니다 8443.
Esa Jokinen

0

호스트와 함께 SNI (Server Name Indication)를 사용하는 경우 실제로 여러 SSL 버전을 정의 할 수 없습니다.

그러나 전용 서버를 사용하는 경우 다른 IP 주소를 서버에 추가 할 수 있습니다. 이러한 방식으로 IP마다 다른 SSL 버전을 사용할 수 있습니다. 예상 IP : 443으로 호스트 설정을 변경하기 만하면됩니다.


-2

또는 다음을 사용할 수 있습니다.

SSL 프로토콜 TLSv1 TLSv1.1 TLSv1.2

나는 많은 서버에서 테스트를 받았으며 나를 위해 일했습니다! 이 사이트에서 사이트를 테스트 할 수 있습니다


4
이 SSLProtocol 라인 은 Apache가 그것에 대해 불평하지 않기 때문에 작동하는 것처럼 보입니다 . 실제로 첫 번째 VirtualHost 항목의 SSLProtocol 만 사용됩니다.
vallismortis
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.