Conflito entre domínios fornecidos SNI e HTTP

22

Recentemente, mudei um site WordPress com uma pequena loja de um provedor de hospedagem para um servidor executando o Ubuntu Server 12.04.2 LTS e Apache 2.2.22. Eu preciso de SSL para a loja. Eu configurei alguns vhosts simples em um novo IP para o servidor, um vinculando a porta 80 do IP específico e o outro vinculando a porta 443. Ambos têm ServerName www.example.come ServerAlias example.comna configuração do vhost. Eu tenho SSLStrictSNIVHostCheck off.

O site está muito lento, mas está funcionando. Estou recebendo o seguinte nos meus logs de erros.

[Error] Hostname example.com provided via SNI and hostname www.example.com provided via HTTP are different

Espero que a lentidão esteja relacionada à mensagem acima. Alguma idéia de por que isso está aparecendo e o que posso fazer sobre isso?

apache-2.2 virtualhost

— flickerfly
fonte

24

Veja o seu log de acesso (não o log de erros). Com a hora e a data do erro, você poderá identificar a solicitação incorreta e descobrir o agente do usuário. No meu caso, era um bot:

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2)"

Meu servidor responde com HTTP 400: Solicitação incorreta.

A menos que eu esteja enganado, nas negociações de TLS, o cliente envia o nome do host duas vezes: uma vez ANTES da conexão SSL ser estabelecida no SNI (Server Name Indication) e uma vez APÓS a solicitação HTTP real. Se os nomes dos servidores não corresponderem, isso indicaria um cliente danificado e não deve ter nada a ver com a configuração do servidor.

Talvez eles consertem o bot algum dia, enquanto isso você provavelmente poderá ignorá-lo. Duvido que isso possa causar lentidão no host, a menos que as solicitações tenham uma taxa muito alta.

— Arno Schäfer
fonte

11

Talvez esse erro tenha sido evocado intencionalmente por alguns clientes para testar vulnerabilidades do seu servidor. Descobri que uma solicitação de researchscan367.eecs.umich.eduacionou o erro em um servidor que mantenho. Nesse caso, é bom que o erro ocorra.

Fiquei curioso sobre o tipo de ataque possível e fiz esta pergunta no Security Stack Exchange: Que tipo de ataque é impedido pelo código de erro do Apache2 AH02032?

— jknappen - Restabelecer Monica
fonte

1

Parece um problema do cliente à primeira vista ... Qual navegador está causando esse problema?

A mensagem sugere que o nome do host que o cliente envia durante a configuração das conexões SSL não é o mesmo que o cliente envia na solicitação HTTPS quando a camada SSL estiver ativa.

— alxgomz
fonte

Não sei o que está causando isso. O erro não relata informações do cliente. Só sei que estou vendo isso regularmente. Eu esperava que o ServerAlias fosse suficiente para torná-lo feliz, pois, em teoria, o servidor sabe que www.domain.com e domain.com são equivalentes.

— Flickerfly

@ flickerfly Sim, este é um cliente com erros e você não pode fazer muito a menos que possa identificá-lo.

— Michael Hampton

2

Ok, apenas desabilitei o SNI removendo a diretiva NameBasedVirtualHost da porta 443. Acho que não preciso disso neste momento. Eu acho que isso deveria funcionar.

— perfil completo

1

No meu caso, a criação de um novo host virtual com um sublinhado foi o problema. Eu tenho um certificado SSL curinga.

Não funcionou:

<VirtualHost *:443>
        SSLEngine on
        ServerName sub_domain.example.com
        Redirect / https://www.example.com/restofmyredirectlink
</VirtualHost>

Embora o Apache tenha reiniciado com êxito, eu recebi erros HTTP 400. No log de erros:

[Wed Sep 05 11:28:00.349960 2018] [ssl:error] [pid 19906:tid 140392626808576] AH02031: Hostname sub_domain.example.com provided via SNI, but no hostname provided in HTTP request

Mas remover o sublinhado funcionou:

<VirtualHost *:443>
        SSLEngine on
        ServerName subdomain.example.com
        Redirect / https://www.example.com/restofmyredirectlink
</VirtualHost>

— MS Berends
fonte

1

Bem-vindo ao ServerFault. Colocar sublinhados em nomes de host é contra as RFCs e quebrará de várias maneiras. stackoverflow.com/questions/2180465/…

— chicks

1

Exatamente! É por isso que agora também está aqui como referência.

— MS Berends

0

Verifique seu arquivo / etc / hosts para ver se você está atribuindo o nome de domínio a um endereço IP local (interno). Não se esqueça de reiniciar o daemon do cache do serviço de nomes após alterar o serviço etc / hosts nscd restart

— Jim Da Otter
fonte