Encaminhar solicitações SSL dependendo do host

Question

Estou tentando encaminhar solicitações SSL dependendo do nome do host para os daemons sub executados em minha máquina. Para conseguir esse comportamento, experimentei o nginx, que funcionará como um proxy / roteador reverso.

Meu arquivo de configuração:

# ...
location / {
    proxy_set_header Host $http_host;

    if ($host = 'hostname01.example.com') { proxy_pass https://127.0.0.1:8001; }
    if ($host = 'hostname02.example.com') { proxy_pass https://127.0.0.1:8002; }
    if ($host = 'hostname03.example.com') { proxy_pass https://127.0.0.1:8003; }
    if ($host = 'hostname04.example.com') { proxy_pass https://127.0.0.1:8004; }
    if ($host = 'hostname01.example1.com') { proxy_pass https://127.0.0.1:8005; }
    if ($host = 'hostname01.example2.com') { proxy_pass https://127.0.0.1:8006; }
    if ($host = 'hostname01.example3.com') { proxy_pass https://127.0.0.1:8007; }
    if ($host = 'hostname01.example4.com') { proxy_pass https://127.0.0.1:8008; }
    # ... 
}

No entanto, devido à natureza do SSL, o host também é criptografado. Ao tentar solicitar um URL, estou recebendo OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol . Deixar um dos daemons ouvir a porta 443 funciona bem.

É possível usar o nginx para esse tipo de configuração? Se não, existe uma ferramenta para alcançar esse comportamento?

Cada sub-serviço está usando um certificado SSL próprio. Uma ideia seria usar máquinas exclusivas para cada serviço e deixá-las ouvir o próprio 443, mas é isso que estou tentando evitar.

Alguma idéia sobre isso?

    

Answer 1

Is it possible to use nginx for this kind of setup? If no, is there a tool for achieving this behaviour?

Como você já observou, seu proxy reverso não sabe nada sobre o URI ou os cabeçalhos HTTP, pois essas informações são incluídas e criptografadas dentro do protocolo TLS. Os hosts virtuais baseados em nome não funcionariam com o TLS tão facilmente .

A única exceção notável a essa regra é a extensão Indicação do Nome do Servidor para TLS, mas isso precisaria de suporte no servidor, bem como todos clientes potenciais . NGNIX suporta SNI no lado do servidor, mas suponho que ainda precisaria terminar as conexões TLS para sua aplicação. HAproxy seria capaz de faça uma decisão de backend com base no nome de host fornecido pelo SNI sem encerrar o túnel - talvez você queira investigar isso.

Se você pudesse colocar as mãos em um único certificado que carregaria todas as combinações nome do host * .exemplo * .com ' como SAN , você pode configurar o NGNIX com este certificado para terminar todos os túneis, inspecionar os cabeçalhos e passar o tráfego dependendo dos valores como um proxy reverso. Esse tipo de solução tem a chance de ser apoiado por mais clientes em potencial , mas tem a desvantagem óbvia que o certificado precisa ser emitido novamente toda vez que você precisar adicionar ou remover um nome de host da lista.