Vários servidores HTTPS para um único site e um único IP?

Question

Suponha que eu tenha um balanceador de carga de nível TCP que transmita pacotes TCP entre um dos dois servidores HTTPS de back-end e o cliente. Para garantir que não há problemas com a criptografia, o balanceador de carga teria que manter uma tabela para garantir que o IP do cliente X sempre acesse o servidor HTTPS A e Y aterre no servidor HTTPS B, etc.

Supondo que o cliente é móvel, o que aconteceria ao mudar de, por exemplo, o protocolo de conexão de internet 3G para 1X? Neste caso, (quase certamente) causa uma mudança de endereço IP. O que o usuário experimentaria?

• Um restabelecimento da conexão SSL / TLS? (assumindo que o próximo clique do usuário era após o término do endereço IP, não haveria interrupção)
• Um intervalo completo da conexão segura? (o usuário veria um erro e teria que tentar novamente)
• Um substituto para uma versão inferior do SSL / TLS? (novamente, sem interrupção, mas e se o IP mudar novamente, voltaria ao normal ou falharia?)

Answer 1

Se você tiver um balanceador de carga com um bom entendimento de HTTP (a maioria deles), normalmente você pode configurar a 'aderência' a um determinado servidor real com base no cookie. O balanceador de carga injetará um cookie na resposta do servidor, com um valor único para cada servidor real possível. Em solicitações subsequentes para o mesmo domínio, um navegador bem comportado enviará de volta o mesmo cookie, que o balanceador de carga lerá e usará para redirecioná-lo de volta ao mesmo servidor de antes.

Dependerá da implementação do balanceador de carga específico se ele respeita o valor do cookie para diferentes endereços IP de origem ou apenas o colocará de volta no pool round-robin (ou ponderado), mas a maioria já trabalhou com apenas usaremos o cookie se existir uma configuração 'persistente'.

Seus maiores problemas virão dependendo de como você aplica seu certificado SSL. Você terá para que o balanceador de carga faça a criptografia / descriptografia SSL para que isso funcione. Se o certificado SSL for aplicado ao servidor , o balanceador de carga não poderá inspecionar os dados HTTP subjacentes no túnel criptografado, portanto, só poderá fazer o balanceamento de carga TCP (ou seja, ponderado ou redondo -robin). Se esta configuração for exigida (por exemplo, como parte de uma cláusula de contrato de criptografia de ponta a ponta), você terá que configurar regras para que um servidor seja favorecido em relação ao outro, exceto quando não estiver disponível (por exemplo, configurá-lo como um backup de failover, não um serviço de carga balanceada) - você simplesmente terá que usar o breve hit para reconectar clientes nesta instância. Você pode atenuar isso no aplicativo armazenando o estado do aplicativo / sessão em um armazenamento resiliente / redundante (banco de dados) e postando o identificador de sessão em cada solicitação (por cookie, campo de formulário oculto ou parâmetro querystring) - seja muito cuidadoso re: segurança da sessão se você fizer isso.

Outras estipulações serão aplicadas à sua aplicação de vários sites habilitados para SSL no mesmo IP. A maioria (se não todos) dos dispositivos de balanceador de carga / servidor (não) pode ligar vários certificados SSL à mesma combinação de IP / porta. Na melhor das hipóteses, um certificado curinga para *.yourdomain.example.org pode ser aplicado a um IP / porta (por exemplo, para cobrir www.yourdomain.example.org, outro.seudominio.exemplo.org) ou um certificado com várias SANs (nomes alternativos de assunto) pode ser usado (embora a maioria dos fornecedores de certificados não emita um certificado baseado em SAN com SANs para vários domínios raiz).