Reindirizzare https su un altro https

Ho cercato su Google questa domanda e ironicamente non riesco a trovare una risposta concreta. Ho risposto a questa domanda da solo in passato, e ora non riesco a ricordare la mia spiegazione.

Diverse volte all'anno, qualcuno mi chiederà di farlo. Vorrei indicarli a una sorta di articolo rispettabile che spiega questo.

Voglio prendere l'URL su https://www.example.com/ e reindirizzare il traffico su https://www.example2.com/ .

Credo che ciò dovrebbe essere tecnicamente possibile, ma non è auspicabile. Cosa c'è di sbagliato in questo metodo? I browser riceveranno un popup di sicurezza poiché li sto reindirizzando a un altro sito? Qualcuno può fornire un link ad una documentazione rispettabile che spiega questo?

Puoi farlo, entrambi i siti devono avere un certificato SSL valido. In questo modo i browser non visualizzeranno un popup di sicurezza. Se entrambi i siti esistono sullo stesso server, tuttavia, entrambi i domini devono essere ospitati da indirizzi IP diversi.

Un web server esamina l'intestazione "Host" nella richiesta HTTP per vedere quale sito deve servire. La negoziazione SSL avviene prima dell'invio della richiesta HTTP, quindi a quel punto il server Web non è in grado di dire quale sito Web verrà visualizzato. Invierà sempre lo stesso certificato al browser.

Esistono due modi per aggirare questo:

• Possedere un certificato con caratteri jolly per * .example.com, in modo che tutti i sottodomini possano condividere lo stesso certificato.
• Esegui ogni sito SSL con un indirizzo IP diverso. In questo modo, il server Web sa quale certificato SSL può inviare al browser, controllando l'indirizzo IP che ha ricevuto la connessione in entrata.

Nota che è perfettamente possibile collegare più indirizzi IP alla stessa scheda di rete, è solo che hai bisogno di un secondo indirizzo IP disponibile nel tuo spazio degli indirizzi IP.

Aggiornamento: al giorno d'oggi, è possibile eseguire più siti SSL su un singolo IP. Per abilitarlo, configura il supporto SNI sul tuo server web. La maggior parte dei browser moderni (tranne Windows XP e Android 2) lo supporta.

Non l'ho mai provato, quindi non parlo per esperienza concreta, ma dovrebbe funzionare. Dovrai disporre di un certificato SSL valido per https://www.example.com poiché il nome host è crittografato nell'intestazione HTTP in modo che il tuo server non sappia reindirizzare fino a quando non viene decrittografato. Dopodiché dovrebbe reindirizzare come una normale richiesta HTTP.

Perché questo sarebbe indesiderato?

Ad esempio, Big Bank e Little Bank gestiscono entrambi i siti su https per offrire ai clienti una sensazione felice e sicura. Big Bank acquista Little Bank. Ad un certo punto il personale IT imposterà un reindirizzamento per https://www.littlebank.com su https://www.bigbank.com . Questo è un motivo legittimo per reindirizzare da https a https.

Questo dovrebbe funzionare bene.

L'unica disconnessione che ritengo sia presente nelle risposte attuali che potrebbero presentarti è che in una qualsiasi di queste circostanze, un vero reindirizzamento (ovvero: il browser viene reimpostato su www.example2.com) andrà bene, ma se mascheri questo in modo tale che il browser stillthinks è puntato verso www.example.com quando in realtà è stato inviato a www.example2.com, questo è dove vedrete avvisi di protezione, proprio perché si potrebbe cercare di falsificare l'utente.

La versione breve è un normale reindirizzamento dovrebbe andare bene, il mascheramento degli indirizzi probabilmente ti lascerà con molte spiegazioni da fare.

A quanto pare, questo problema può essere risolto su un livello di trasporto. Supponiamo che tu abbia un record DNS A per example.com che punta a 192.168.0.1. Quando si digita https://example.com in un browser, il PC ha stabilito una connessione TCP a un server con IP 192.168.0.1, in cui alcuni processi sono in ascolto sulla porta 443. Cosa succede se allo stesso tempo il server (che non sta provando a entrare nei dettagli dei dati inviati su questa sessione TCP come l'avvio della negoziazione SSL) stabilisce una connessione TCP a 192.168.0.2 (un altro server con DNS A example2.com che punta ad esso. L'utulità Linux del proxy HA installata sul primo server potrebbe risolvere questo problema con una configurazione del genere:

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

Ma ciò causerà un errore del certificato SSL a meno che il tuo server web example2.com non mostri un certificato SSL con CN = example2.com e SAN = example.com, ad esempio.

Oppure potresti impostare un orizzonte slpit DNS quando gli utenti perstective example.com ed example2.com si risolvono in 192.168.0.1.