Redirigez https vers un autre https

J'ai cherché sur Google pour cette question et, ironiquement, je ne trouve pas de réponse concrète. J'ai répondu à cette question moi-même dans le passé, et maintenant je ne me souviens plus de ma propre explication.

Plusieurs fois par an, quelqu'un me demandera de le faire. Je voudrais leur indiquer une sorte d'article respectable qui explique cela.

Je souhaite prendre l'URL à https://www.example.com/ et rediriger le trafic vers https://www.example2.com/ .

Je pense que cela devrait être techniquement possible, mais n'est pas souhaité. Quel est le problème avec cette méthode? Les navigateurs obtiendront-ils une fenêtre contextuelle de sécurité puisque je les redirige vers un autre site? Quelqu'un peut-il fournir un lien vers une documentation respectable qui explique cela?

Vous pouvez le faire, les deux sites doivent avoir un certificat SSL valide. De cette façon, les navigateurs ne donneront pas de fenêtre contextuelle de sécurité. Cependant, si les deux sites existent sur le même serveur, les deux domaines doivent être hébergés à partir d'adresses IP différentes.

Un serveur Web regarde l'en-tête "Host" dans la requête HTTP pour voir quel site il doit servir. La négociation SSL a lieu avant l'envoi de la demande HTTP, donc à ce stade, le serveur Web ne peut pas dire quel site Web il affichera. Il enverra toujours le même certificat au navigateur.

Il existe deux façons de contourner ce problème:

• Avoir un certificat générique pour * .example.com, afin que tous les sous-domaines puissent partager le même certificat.
• Exécutez chaque site SSL à une adresse IP différente. De cette façon, le serveur Web sait quel certificat SSL il peut envoyer au navigateur, en inspectant l'adresse IP qui a reçu la connexion entrante.

Notez qu'il est parfaitement possible d'attacher plusieurs adresses IP à la même carte réseau, c'est juste que vous avez besoin d'une deuxième adresse IP disponible dans votre espace d'adressage IP.

Mise à jour: De nos jours, vous pouvez exécuter plusieurs sites SSL sur une seule IP. Pour l'activer, configurez la prise en charge SNI sur votre serveur Web. La plupart des navigateurs modernes (à l'exception de Windows XP et Android 2) le prennent en charge.

Je n'ai jamais essayé ça donc je ne parle pas d'expérience concrète, mais ça devrait marcher. Vous aurez besoin d'un certificat SSL valide pour https://www.example.com car le nom d'hôte est crypté dans l'en-tête HTTP afin que votre serveur ne sache pas rediriger jusqu'à ce qu'il soit décrypté. Après cela, il devrait rediriger comme il le ferait une demande HTTP normale.

Pourquoi serait-ce indésirable?

Par exemple, Big Bank et Little Bank gèrent tous deux des sites sur https pour donner aux clients un sentiment de sécurité heureux. Big Bank achète Little Bank. À un moment donné, les informaticiens mettront en place une redirection pour https://www.littlebank.com vers https://www.bigbank.com . Il s'agit d'une raison légitime de rediriger de https vers https.

Cela devrait bien fonctionner.

La seule déconnexion qui, selon moi, est présente dans les réponses actuelles qui peuvent vous arriver est que dans toutes ces circonstances, une véritable redirection (c'est-à-dire: le navigateur est redirigé vers www.example2.com) conviendra, mais si vous masquez cela de telle sorte que le navigateur stillthinks il est pointé sur www.example.com alors qu'en réalité vous avez envoyé à www.example2.com, c'est là que vous verrez des avertissements de sécurité précisément parce que vous pourriez essayer de falsifier l'utilisateur.

La version courte est une redirection normale devrait être bien, le masquage d'adresse va probablement vous laisser beaucoup d'explications à faire.

À son avis, ce problème peut être résolu sur une couche de transport. Supposons que vous ayez un enregistrement DNS A pour example.com pointant vers 192.168.0.1. Lorsque vous tapez https://example.com dans un navigateur, votre PC a établi une connexion TCP avec un serveur avec IP 192.168.0.1, où certains processus écoutent sur le port 443. Et si en même temps le serveur (qui n'essaie pas de entrer dans les détails des données envoyées sur cette session TCP comme le démarrage de la négociation SSL) établit une connexion TCP à 192.168.0.2 (un autre serveur avec DNS Un exemple2.com pointant vers elle. une config comme ça:

defaults
        log    global
        mode    tcp
        retries 2
        option redispatch
        option tcplog
        option tcpka
        option clitcpka
        option srvtcpka
        timeout connect 5s      
        timeout client  24h     #timeout client->haproxy(frontend)
        timeout server  60m

listen front443 192.168.0.1:443
    server back443 192.168.0.2:443

Mais cela entraînera une erreur de certificat SSL, sauf si votre serveur Web example2.com affichera un certificat SSL avec CN = example2.com et SAN = example.com, par exemple.

Ou vous pouvez configurer un horizon de fente DNS lorsque les utilisateurs perstective example.com et example2.com se résolvent en 192.168.0.1.