Redirecionar https para outro https

Question

Eu estive pesquisando sobre essa questão, e ironicamente irritantemente não consigo encontrar uma resposta concreta. Já respondi a essa pergunta no passado e agora não consigo lembrar minha própria explicação.

Várias vezes por ano, alguém me pedirá para fazer isso. Eu gostaria de apontá-los para algum tipo de artigo respeitável que explica isso.

Eu quero pegar o URL no link e redirecionar o tráfego para link .

Acredito que isso seja tecnicamente possível, mas é indesejado. O que há de errado com esse método? Os navegadores receberão um pop-up de segurança, já que estou redirecionando-os para outro site? Alguém pode fornecer um link para alguma documentação respeitável que explica isso?

    

Answer 1

Você pode fazer isso, ambos os sites precisam ter um certificado SSL válido. Desta forma, os navegadores não fornecem um pop-up de segurança. No entanto, se os dois sites existirem no mesmo servidor, os dois domínios precisarão ser hospedados em endereços IP diferentes.

Um servidor da Web examina o cabeçalho "Host" na solicitação HTTP para ver o site que precisa veicular. A negociação SSL acontece antes que a solicitação HTTP seja enviada, então, nesse ponto, o servidor da Web não pode informar qual site será exibido. Ele sempre enviará o mesmo certificado para o navegador.

Existem duas maneiras de contornar isso:

• Ter um certificado curinga para * .example.com, para que todos os subdomínios possam compartilhar o mesmo certificado.
• Executar cada site SSL em um endereço IP diferente. Dessa forma, o servidor da Web sabe qual certificado SSL pode enviar para o navegador, inspecionando o endereço IP que recebeu a conexão de entrada.

Note que é perfeitamente possível anexar vários endereços IP ao mesmo adaptador de rede, mas você precisa de um segundo endereço IP disponível no seu espaço de endereço IP.

Atualização: Atualmente, você pode executar vários sites SSL em um único IP. Para habilitar isso, configure o suporte a SNI em seu servidor da web. A maioria dos navegadores modernos (exceto o Windows XP e o Android 2) suportam isso.

    

Answer 2

Eu nunca tentei isso, então não falo de experiência concreta, mas deve funcionar. Você precisará ter um certificado SSL válido para o link , pois o nome do host é criptografado dentro do cabeçalho HTTP para que o servidor não saiba redirecioná-lo até é decifrado. Depois disso, ele deve redirecionar como se fosse uma solicitação HTTP normal.

    

Answer 3

Por que isso seria indesejado?

Como exemplo, o Big Bank e o Little Bank executam sites em https para oferecer aos clientes uma sensação de segurança. O Big Bank compra o Little Bank. Em algum momento, o pessoal de TI configurará um redirecionamento para o link para link . Este é um motivo legítimo para redirecionar de https para https.

Isso deve funcionar bem.

    

Answer 4

A única desconexão que acho que está presente nas respostas atuais que podem surgir para você é que, em qualquer uma dessas circunstâncias, um redirecionamento verdadeiro (isto é: o navegador é apontado para www.exemplo2.com) ficará bem, mas se você mascara isso de tal forma que o navegador ainda pensa que está apontado em www.example.com quando na realidade você o enviou para www.example2.com, este é onde você verá avisos de segurança precisamente porque você poderia tente enganar o usuário.

A versão curta é um redirecionamento normal deve ser bom, o mascaramento de endereço provavelmente vai deixar você com muitas explicações para fazer.

    

Answer 5

Como se vê, este problema pode ser resolvido em uma camada de transporte. Digamos que você tenha um registro DNS A para example.com apontando para 192.168.0.1. Quando você digita o link em um navegador, seu PC estabelece uma conexão TCP com um servidor com IP 192.168.0.1, onde algum processo escuta na porta 443. E se ao mesmo tempo, o servidor (que não está tentando entrar em detalhes dos dados enviados por essa sessão TCP como iniciar a negociação SSL) estabelece uma conexão TCP para 192.168.0.2 (um outro servidor com DNS Um exemplo2.com apontando para ele). HA proxy linux utulity instalado no primeiro servidor pode resolver isso com uma configuração como essa:

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

Mas isso causará um erro de certificado SSL, a menos que seu servidor da web example2.com mostre um certificado SSL com CN = example2.com e SAN = example.com, por exemplo.

Ou você pode configurar um horizonte de slpit de DNS quando dos usuários perstective example.com e example2.com resolverem para 192.168.0.1.