Delegado SSL do proxy reverso do Apache httpd para backend

Question

Normalmente, o uso do Apache como proxy reverso é feito para fazer o descarregamento de SSL e, portanto, o Apache manipula todo o material SSL e o servidor backend apenas gerencia o http simples. Mas é possível fazer o oposto? Eu não estou falando de SSLProxy onde o Apache e o backend se comunicam através de https. Quero que meu back-end negocie SSL com o cliente.

Um pouco sobre porque eu preciso disso:
Estou trabalhando com autenticação de certificado de cliente e, quando a autenticação falha, o usuário obtém uma página de erro não amigável ao navegador específica. Então, estamos criando uma página de diagnóstico para mostrar ao usuário por que a autenticação falhou. Esta página deve permitir qualquer certificado para que possamos verificar a si mesmo e descobrir o que está errado.
Primeiro, tentamos a configuração optional_no_ca no Apache, mas ela ainda faz algumas verificações como a data de expiração. Conseguimos fazê-lo funcionar com o Tomcat (também foi útil fazê-lo com Java).

Por enquanto, a única solução viável parece configurar um segundo servidor (físico) com o tomcat como front. Mas parece pesado apenas para renderizar uma página.

    

Answer 1

Você não pode passar exatamente isso. Mas há alguns hacks que você pode usar se estiver disposto a mudar seu back-end. O certificado do cliente é apresentado como parte da negociação TLS, que, por definição, não pode ser transmitida.

Você pode, por exemplo, fazer com que o Apache analise o certificado e propague os detalhes do certificado (autenticado) usando diretivas como RequestHeader set SSL_CLIENT_S_DN "%{SSL_CLIENT_S_DN}s" . Veja aqui um exemplo .

Claro, para usar isso para autenticação, você precisaria restringir o acesso ao back-end e usar o TLS entre o proxy e o back-end.

    

Answer 2

O Apache não pode fazer isso. Se você quiser um proxy entre os dois, mas sem operações TLS, seu proxy é essencialmente um túnel TCP.

Um tempo atrás, quando eu queria fazer algo parecido, me deparei com sniproxy . Parece-me que pode fazer o que quiser. Se você precisar do Apache para outras partes do seu site, poderá executar o Apache atrás do sniproxy. Tenha em mente que, devido à maneira como o SNI em SSL / TLS funciona, você não pode executar vários back-ends no mesmo nome de host. Use algo como www.example.com no Apache e app.example.com para o aplicativo de certificado de cliente. Essa é a solução que eu recomendaria se você tivesse apenas um endereço IP disponível.

Outra alternativa é simplesmente executar um proxy TCP, por exemplo, usando o HAproxy, ou simplesmente executar o aplicativo diretamente em um endereço IP dedicado. Nesta situação, no entanto, você perde a possibilidade de executar vários sites no mesmo endereço IP. (sem possibilidade de vhosts). Esta é a solução que eu recomendaria se você tivesse vários endereços IP disponíveis.

    

Answer 3

Se eu entendi bem o seu problema, vejo outra solução não relacionada a proxy:

por padrão, o cliente é acessado na página de diagnóstico (não é necessário certificado), o que torna um plano de fundo, consulta AJAX à zona protegida. Dependendo do resultado da consulta, o JavaScript redireciona para a página protegida ou mostra uma mensagem, explicando que algo está errado no certificado.

    

Answer 4

A essência do https é garantir que o cliente e o servidor se encontrem acima da camada de rede, portanto, o apache não pode fazer proxy HTTP para https no back-end.

Além do sniproxy, que eu vejo em outra resposta, eu sugeriria haproxy . É um rápido Proxy TCP com muitos recursos.