Atualizar conexão HTTP para SSL / TLS


8

Atualmente, tenho um servidor que redireciona automaticamente todas as solicitações HTTP para o site HTTPS equivalente. O problema é que parece que alguns navegadores não aceitam o certificado SSL (StartSSL.com) ou não oferecem suporte ao SNI; portanto, eles recebem um aviso de certificado e o usuário não continua navegando no site.

Existe algum mecanismo que tente fazer o navegador usar HTTPS em vez de HTTP simples e quando isso não funciona (por exemplo, o certificado não é aceito ou o SNI não é suportado), ele continua usando o HTTP.

Atualmente, estou usando o Apache 2.4 com vários hosts virtuais que redirecionam a conexão HTTP Redirect / https://domain.example/.


3
Mudar de HTTPS para HTTP quando um certificado não está correto, algo que você nunca deve querer que aconteça como visitante. O fato de um certificado estar incorreto deve ser um sinal de que algo está errado; reverter para uma conexão não criptografada é a pior coisa que você pode fazer. A melhor solução que você tem é corrigir seu certificado para que ele corresponda ao seu nome de host, usando outra autoridade de certificação ou não SNI.
Teun Vink

OK, entendi. Porém, quando esperamos que exista um navegador que não suporte conexões HTTPS ou que não suporte os mecanismos de criptografia fornecidos pelo servidor. Em seguida, esse cliente não tem (no meu caso) nenhuma possibilidade de usar o site, porque eu redireciono automaticamente para o site equivalente ao HTTPS.
foxylion

No mundo de hoje, é bem possível superar essa limitação. Os sites muito importantes têm apenas comutadores para SSL. Se eles podem fazer isso, você pode fazê-lo.
MichelZ

Respostas:


15

Um navegador nunca deve fazer o downgrade por si só para http se https não funcionar, porque tudo o que um invasor precisa fazer é tornar https indisponível (por exemplo, porta de bloco 443). Portanto, a única maneira de fazer isso é instruindo o navegador a partir do servidor, por exemplo, enviando um redirecionamento http. É claro que isso deve ser enviado por uma conexão segura (caso contrário, um homem do meio pode falsificá-la), mas infelizmente é exatamente o seu problema que a conexão segura falha.

Em resumo: Não, não é possível e é melhor assim.

Aliás, todos os navegadores modernos suportam SNI, mas nem todos os aplicativos (por exemplo, aplicativos Java, etc.). Se você tiver vários domínios no servidor da Web, mas apenas um único necessário para esses aplicativos, poderá definir o certificado para esse domínio como padrão. Caso contrário, você precisará obter um certificado (mais caro) que contenha todos os domínios necessários como nomes alternativos de assunto.

Edite com outra idéia: o que você poderia tentar fazer é baixar uma imagem do seu lado como https e verificar o sucesso com um manipulador de erro na tag img. Talvez isso não acione um aviso visível ao usuário, mas apenas carregue. E se for bem-sucedido, você sabe que o acesso https é possível e redireciona o usuário.

Além disso, você deve se perguntar por que deseja oferecer https, se você também aceita o acesso com http. Existem dados que devem ser protegidos ou não. Contanto que você ofereça um substituto para http, é fácil para um invasor impor http em vez de https.


1
Muito bem afirmado.
Tim Brigham

3

Antes de tudo, deve ser possível especificar um certificado a ser usado para todos os clientes que não possuem suporte SNI. Isso significa que, de todos os domínios hospedados nesse endereço IP, você pode ter pelo menos um deles trabalhando para clientes sem SNI.

O que você poderia fazer ao redirecionar de http para https é um redirecionamento de dois estágios. O primeiro redirecionamento de http para https usa o nome de domínio, que você garantiu que funcionaria com ou sem suporte a SNI. O URL original completo teria que ser incluído, para que, a partir deste site https, você possa redirecionar para o site apropriado posteriormente.

O nome do domínio, que funciona com ou sem SNI, pode se comportar de maneira diferente, dependendo se o SNI é suportado pelo cliente. Dessa forma, você saberia que o cliente suportava o SNI antes de redirecioná-lo para um domínio, que exigia o SNI.

Como exatamente configurá-lo no Apache será um pouco difícil de entender do meu lado (já que nunca configurei o Apache com mais de um certificado). Eu acho que a maneira de fazer isso seria criar hosts virtuais baseados em nome para todos os domínios, incluindo o domínio intermediário.

Em seguida, crie um host virtual padrão para clientes sem SNI, que usa o mesmo certificado que o nome. Esses dois hosts virtuais com certificado idêntico enviarão redirecionamentos diferentes para os clientes, dependendo se eles suportam SNI.

Por fim, eu habilitaria o IPv6 no servidor. Com o IPv6, você obtém endereços IP suficientes para alocar um a cada host virtual. O mesmo conjunto de hosts virtuais pode ser o nome baseado em IPv4 e IP com base em IPv6, para que você não precise duplicar nenhuma configuração dessa maneira.

O resultado final seria uma configuração que funcione desde que o cliente suporte SNI ou IPv6. Somente os clientes que não oferecem suporte a eles terão um problema, mas você ainda poderá detectá-los e enviar ao servidor um redirecionamento diferente ou uma mensagem de erro.

Quanto aos clientes que não gostam da CA, minha única sugestão é reconhecê-los pelo agente do usuário e manipulá-los da maneira que você parecer apropriada. Verifique se você possui um link para o site https, no qual eles podem clicar, caso você inclua muitos clientes por engano.


0

Apenas um palpite: pode ser que você não tenha uma diretiva SSLCertificateChainFile na sua configuração do apache que inclua o arquivo sub.class1.server.ca.pem necessário para o StartSSL?


Não, tudo funciona bem, mas algum navegador antigo não suporta SNI ou não confia no StartSSL.com. O problema é que esses visitantes não têm possibilidade de exibir a página sem ignorar o aviso de certificado (o que não é solução).
foxylion
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.