Início / server / Perguntas / 772901
Accepted
jarvis
Asked: 2016-04-26 20:16:28 +0800 CST

421 Solicitação mal direcionada usando HTTP/2 e SAN SSL

  • 772

Estou executando o Apache 2.4.20 no Ubuntu e tenho o SSL configurado. Eu tenho um certificado SAN SSL e www.example.com e www2.example.com estão compartilhando o mesmo certificado.

Estou recebendo um erro 421 Misdirected Request quando incluo o seguinte:

Protocols h2 h2c http/1.1
H2Upgrade on
H2Direct
H2WindowSize 128000

Os sites funcionam normalmente se eu os remover.

Estou recebendo o erro se NO MESMO NAVEGADOR, www.example.com e www2.example.com são abertos. Se eu for para www.example.com primeiro, ele será carregado corretamente. Recebo o erro quando carrego um segundo site desse certificado SAN SSL, como www2.example.com . Não importa qual site eu vá primeiro. Ele sempre responde com o 421 Misdirected Request no segundo site.

O que há de errado com meu uso das diretivas HTTP/2? (Eles estão no VirtualHost a propósito)

Ou há um problema com as implementações HTTP/2 e SAN SSL?

E se for importante, www.example.com e www2.example.com estão no mesmo servidor hospedado na AWS.

Obrigado.

EDITAR:

Eu também tentei as configurações abaixo com os mesmos resultados.

Protocols h2 http/1.1
H2Direct
H2WindowSize 128000

Na configuração SSL

<IfModule mod_ssl.c>

    SSLRandomSeed startup builtin
    SSLRandomSeed startup file:/dev/urandom 512
    SSLRandomSeed connect builtin
    SSLRandomSeed connect file:/dev/urandom 512

    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl .crl

    SSLPassPhraseDialog  exec:/usr/share/apache2/ask-for-passphrase

    SSLSessionCache     shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
    SSLSessionCacheTimeout  300

    SSLOpenSSLConfCmd DHParameters "/path/dhparams.pem"

    SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

    SSLHonorCipherOrder on

    SSLCompression Off
    SSLSessionTickets Off

    SSLUseStapling On
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
    SSLStaplingCache shmcb:${APACHE_RUN_DIR}/ssl_stapling(32768)

    SSLProtocol all -SSLv3

    SSLInsecureRenegotiation Off
    SSLStrictSNIVHostCheck Off

</IfModule>

No VirtualHost

<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ServerAdmin [email protected]
    ServerName www.example.com
    DocumentRoot /path/path

    Protocols h2 http/1.1
    H2Direct on
    H2WindowSize 128000

    SSLEngine on
    SSLCACertificateFile /path/cert.crt
    SSLCertificateFile /path/cert.crt
    SSLCertificateKeyFile /path/key.key

    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

    <Directory /path/path>
        AllowOverride None
        Require all granted
    </Directory>

 </VirtualHost>
</IfModule>
ssl https amazon-web-services apache-2.4 ubuntu-14.04

2 respostas

  1. Best Answer

    Este foi um problema real para mim. Mas encontrei a resposta aqui .

    Múltiplos hosts e solicitações mal direcionadas

    Muitos sites usam o mesmo certificado TLS para vários hosts virtuais. O certificado tem um nome curinga, como '*.example.org' ou carrega vários nomes alternativos. Os navegadores que usam HTTP/2 reconhecerão isso e reutilizarão uma conexão já aberta para esses hosts.

    Embora isso seja ótimo para o desempenho, tem um preço: esses vhosts precisam de mais cuidado em sua configuração. O problema é que você terá várias solicitações para vários hosts na mesma conexão TLS. E isso impossibilita a renegociação, visto que o padrão HTTP/2 proíbe.

    Portanto, se você tiver vários hosts virtuais usando o mesmo certificado e quiser usar HTTP/2 para eles, precisará garantir que todos os vhosts tenham exatamente a mesma configuração SSL. Você precisa do mesmo protocolo, cifras e configurações para verificação do cliente.

    Se você misturar as coisas, o Apache httpd irá detectá-lo e retornar um código de resposta especial, 421 Misdirected Request, para o cliente.

    Eu tenho 3 VirtualHosts compartilhando o mesmo certificado. Ambos são configurados usando minha configuração SSL "padrão". O último tinha uma configuração especial, pois não precisava que o último fosse compatível com muitos navegadores, então usei cifras mais modernas e apenas o protocolo SSL mais recente. Aquele VirtualHost "especial" em particular estava recebendo o 421.

    Se eu desabilitar o Protocolo h2 http/1.1, isso resolveria o problema, mas eu não queria desabilitar isso.

    Depois de usar a mesma configuração em todos os VirtualHost compartilhando o mesmo certificado, o problema foi corrigido .

    • 5

  2. Encontrei esse problema hoje e fiquei um pouco confuso no começo, porque não usei nenhuma cifra diferente, etc., então não consegui entender o que realmente era a nota "se você misturar as coisas" da resposta acima. Bem, descobriu-se que não é suficiente se SSLCertificateFile e SSLCertificateKeyFile tiverem o mesmo conteúdo e se os arquivos forem cópias idênticas um do outro. Essas definições de configuração devem apontar para o mesmo arquivo! Eu suspeito que seja, porque não é o navegador que realmente vê um problema (como inicialmente pensei que fosse o caso), mas o Apache já está detectando que a configuração não é a mesma e bloqueia qualquer solicitação HTTP2 preventivamente porque espera que o navegador vai ter um problema se realmente entregou a página (o que provavelmente pode muito bem acontecer). O Apache também está gravando um erro correspondente em seu arquivo de log ("Hostname www.example.com fornecido via SNI e hostname www2.example.com fornecido via HTTP não possui configuração SSL compatível"). Este teste de compatibilidade de configuração parece ser bastante simples e não se importa com o fato de que o certificado é de fato o mesmo. Provavelmente, ele apenas percebe os diferentes nomes de arquivos/caminhos e depois hesita.

    • 2

relate perguntas