É possível definir um SSLProtocol no Apache para um único VirtualHost (poodle)?

13

Estou tentando testar um patch para a vulnerabilidade poodle que envolve a desativação do SSLv3 no meu servidor web. Para testar isso em um ambiente de não produção primeiro, estou configurando o SSLProtocol em um VirtualHost para um servidor de teste diferente. Minha configuração é mais ou menos assim:

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

No entanto, mesmo após reiniciar o apache, meu site de teste ainda é reivindicado como vulnerável. Isso deve funcionar? Eu estou querendo saber se eu tenho que configurá-lo na configuração global do SSL ou se há algo mais sutil que está causando a configuração para não levar e / ou trabalhar.

— Cory
fonte

16

Você pode definir o SSLProtocol apenas para o primeiro VirtualHost no arquivo de configuração. Todas as entradas subsequentes do VirtualHost herdarão essa configuração da primeira entrada e ignorarão silenciosamente sua própria configuração devido a um bug do OpenSSL .

Há um relatório de bug correspondente para mod_ssl , mas conforme descrito no relatório de bug, o problema precisa ser resolvido no OpenSSL (o certificado é herdado, mas não os protocolos).

Os conjuntos de cifras devem ser configurados independentemente para cada VirtualHost, caso contrário, você terminará com a lista padrão, incluindo muitas cifras inseguras. Além disso, esteja ciente de que os clientes mais antigos que não oferecem suporte à Server Name Indication (SNI) sempre usarão o host padrão (a menos que seja bloqueadoSSLStrictSNIVHostCheck ), o que pode confundir seu teste.

Em resumo, você deve poder especificar conjuntos de códigos e certificados personalizados para cada host virtual, mas até que o erro seja corrigido, não espere um comportamento correto com protocolos personalizados para cada host virtual.

Encontrei esse problema com o Apache 2.4 e modssl com o OpenSSL 1.0.1k, e espero que o Apache 2.2 esteja sujeito aos mesmos problemas.

Atualização (outubro de 2016): O bug do OpenSSL foi marcado como resolvido em 13 de outubro de 2016. No entanto, fazia parte de um fechamento em massa de problemas abertos e, embora uma 'correção parcial' tenha sido fornecida, o problema nunca foi totalmente resolvido.

Atualização (abril de 2018): O bug OpenSSL reenviado agora tem um patch disponível (a partir de 9 de abril de 2018). Esse patch alterará o comportamento das instâncias do Apache configuradas com vários hosts virtuais SNI:

Rejeitar conexões não conformes ao vhost SSLProtocol

Isso foi desenvolvido e testado com 2.4.27 e em produção com essa versão. O patch foi modificado para 2.4.33 e levemente testado.

Isso verifica a versão da conexão com o SSLProtocol configurado para o host virtual correspondente com base no SNI. Como a conexão é feita inicialmente com o SSLProtocol configurado para o host padrão da porta, o host padrão deve incluir todos os protocolos que serão suportados por qualquer host virtual.

Esse patch adiciona um status de retorno adicional de APR_EMISMATCH à função init_vhost para que o retorno de chamada ssl_callback_ServerNameIndication registrado no OpenSSL possa retornar um alerta fatal SSL_AD_PROTOCOL_VERSION. Pretende-se produzir a mesma resposta ao ClientHello como ter um SSLProtocol especificado que não inclua a versão em questão. Como o retorno de chamada SNI é chamado durante o processamento do ClientHello e antes que uma resposta seja produzida, parece fazer exatamente isso.

Se você de repente vir mensagens do seguinte formato:

Rejecting version [version] for servername [hostname]

Em seguida, verifique novamente o SSLProtocolseu host padrão.

— vallismortis
fonte

As informações adicionais adicionadas pelo @anx a respeito SSLStrictSNIVHostChecksão muito apreciadas. No entanto, também deve ser notado a partir da documentação citou que se definido como em qualquer outra máquina virtual, SNI clientes inconscientes não estão autorizados a aceder a este host virtual específico .

— vallismortis

5

Você pode ter protocolos SSL diferentes para cada Vhost se eles estiverem ouvindo em um IP diferente.

Exemplo com um host específico que permite TLSv1 e todos os outros que permitem apenas TLSv1.1 e TLSv1.2 - e um que permite apenas 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>

— BitLegacy01
fonte

Além disso, se você precisar apenas para fins de teste, poderá usar outra porta em vez de outro IP, por exemplo, porta HTTPS alternativa comum 8443.

— Esa Jokinen

0

Se você estiver usando o Server Name Indication (SNI) com seu vhost, na verdade, não poderá definir várias versões SSL.

No entanto, se você estiver usando um servidor dedicado, provavelmente poderá adicionar outro endereço IP ao seu servidor. Dessa maneira, você poderá usar uma versão SSL diferente por IP. Você apenas precisa alterar as configurações do vhost conforme o IP esperado: 443.

— tryp
fonte

-2

Ou você pode usar:

SSLProtocol TLSv1 TLSv1.1 TLSv1.2

Fui testado em muitos servidores e funciona para mim! Você pode testar seu site neste site

— Rodrigo Moreno
fonte

4

Essa linha SSLProtocol só parece estar funcionando porque o Apache não se queixa. Na realidade, apenas o SSLProtocol na primeira entrada do VirtualHost é usado.

— vallismortis