Mettre à niveau la connexion HTTP vers SSL / TLS


8

J'ai actuellement un serveur qui redirige automatiquement toutes les requêtes HTTP vers le site HTTPS équivalent. Le problème est qu'il semble que certains navigateurs n'acceptent pas le certificat SSL (StartSSL.com) ou ne prennent pas en charge SNI, ils reçoivent donc un avertissement de certificat et l'utilisateur ne continuera pas à surfer sur le site Web.

Existe-t-il un mécanisme qui tente de faire en sorte que le navigateur utilise HTTPS au lieu de HTTP simple et lorsque cela ne fonctionne pas (par exemple, le certificat n'est pas accepté ou SNI non pris en charge), il continue à utiliser HTTP.

Actuellement, j'utilise Apache 2.4 avec plusieurs hôtes virtuels qui redirigent tous la connexion HTTP avec Redirect / https://domain.example/.


3
Passer de HTTPS à HTTP lorsqu'un certificat n'est pas correct, c'est quelque chose que vous ne devriez jamais vouloir faire en tant que visiteur. Le fait qu'un certificat soit incorrect devrait être un signe que quelque chose ne va pas, le retour à une connexion non cryptée est la pire chose que vous puissiez faire alors. La meilleure solution que vous avez est de corriger votre certificat afin qu'il corresponde à votre nom d'hôte, soit en utilisant une autre autorité de certification, soit en n'utilisant pas SNI.
Teun Vink

Ok, j'ai compris. Mais lorsque nous nous attendons à ce qu'il y ait un navigateur qui ne prend pas en charge les connexions HTTPS ou ne prend pas en charge les mécanismes de cryptage fournis par le serveur. Ensuite, ce client n'a (dans mon cas) aucune possibilité d'utiliser le site, car je redirige automatiquement vers le site équivalent HTTPS.
foxylion

Dans le monde d'aujourd'hui, il est tout à fait possible de surmonter cette limitation. Les sites très importants ont uniquement des commutateurs SSL. S'ils peuvent le faire, vous pouvez le faire.
MichelZ

Réponses:


15

Un navigateur ne devrait jamais rétrograder seul vers http si https ne fonctionne pas, car tout ce qu'un attaquant devrait faire est de rendre https indisponible (par exemple bloquer le port 443). Donc, la seule façon de le faire est de demander au navigateur du serveur de le faire, par exemple en envoyant une redirection http. Bien sûr, cela doit être envoyé via une connexion sécurisée (sinon un homme du milieu pourrait le truquer) mais malheureusement, c'est exactement votre problème que la connexion sécurisée échoue.

En résumé: non, ce n'est pas possible et c'est mieux ainsi.

BTW, tous les navigateurs modernes prennent en charge SNI, mais pas toutes les applications (par exemple les applications Java, etc.). Si vous avez plusieurs domaines sur le serveur Web, mais qu'un seul est requis par ces applications, vous pouvez définir le certificat pour ce domaine comme valeur par défaut. Sinon, vous devrez obtenir un certificat (plus cher) qui contient tous les domaines nécessaires en tant que noms alternatifs soumis.

Modifiez avec une autre idée: ce que vous pourriez essayer de faire est de télécharger une image de votre côté en tant que https et de vérifier le succès avec un gestionnaire d'erreurs sur la balise img. Peut-être que cela ne déclenche pas un avertissement visible par l'utilisateur mais échoue à la place. Et s'il réussit, vous savez que l'accès https est possible et redirigez l'utilisateur.

En dehors de cela, vous devez vous demander pourquoi vous souhaitez proposer https, si vous acceptez également l'accès avec http. Soit il y a des données qui doivent être protégées, soit elles ne le sont pas. Tant que vous proposez une solution de rechange à http, il est facile pour un attaquant d'appliquer http au lieu de https.


1
Très bien exposé.
Tim Brigham

3

Tout d'abord, il devrait être possible de spécifier un certificat à utiliser pour tous les clients ne prenant pas en charge SNI. Cela signifie que pour tous les domaines hébergés sur cette adresse IP, vous pouvez avoir au moins l'un d'entre eux travaillant pour des clients sans SNI.

Ce que vous pourriez alors faire lors de la redirection de http vers https est une redirection en deux étapes. La première redirection de http vers https utilise le nom de domaine, qui, selon vous, fonctionnerait avec ou sans prise en charge SNI. L'URL d'origine complète devrait être incluse, de sorte que depuis ce site https, vous pouvez rediriger vers le bon après.

Le nom de domaine, qui fonctionne avec ou sans SNI, peut se comporter différemment selon que SNI est pris en charge par le client. De cette façon, vous sauriez que le client prend en charge SNI avant de le rediriger vers un domaine, ce qui nécessite SNI.

Comment configurer exactement cela sur Apache va être un peu à deviner de mon côté (car je n'ai jamais configuré Apache avec plus d'un certificat). Je suppose que la façon de le faire serait de créer des hôtes virtuels basés sur le nom pour tous les domaines, y compris le domaine intermédiaire.

Créez ensuite un hôte virtuel par défaut pour les clients sans SNI, qui utilise le même certificat que celui qui utilise le nom. Ces deux hôtes virtuels avec un certificat identique, enverront une redirection différente aux clients selon qu'ils prennent en charge SNI.

Enfin, j'activerais IPv6 sur le serveur. Avec IPv6, vous obtenez suffisamment d'adresses IP que vous pouvez attribuer une à chaque hôte virtuel. Le même ensemble d'hôtes virtuels peut être basé sur IPv4 et IP sur IPv6, vous n'avez donc pas à dupliquer de configuration de cette façon.

Le résultat final serait une configuration qui fonctionne tant que le client prend en charge SNI ou IPv6. Seuls les clients qui ne prennent en charge ni l'un ni l'autre auront alors un problème, mais vous pourrez toujours les détecter et serveur une redirection différente ou un message d'erreur.

Quant aux clients qui n'aiment pas l'autorité de certification, ma seule suggestion est de les reconnaître par leur user-agent et de les gérer comme vous le jugez approprié. Assurez-vous d'avoir un lien vers le site https, sur lequel ils peuvent cliquer au cas où vous incluriez par erreur trop de clients.


0

Juste une supposition folle: se pourrait-il que vous n'ayez pas de directive SSLCertificateChainFile dans votre configuration apache qui inclut le fichier sub.class1.server.ca.pem dont vous avez besoin pour StartSSL?


Non, tout fonctionne bien, mais certains anciens navigateurs ne prennent pas en charge SNI ou ne font pas confiance à StartSSL.com. Le problème est que ces visiteurs n'ont aucune possibilité de visualiser la page sans ignorer l'avertissement de certificat (ce qui n'est pas une solution).
foxylion le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.