Squid ssl_bump server_first

Question

Estou tentando testar a diretiva do Squid server_first do ssl_bump, mas não entendi como ela funciona. Tanto quanto eu entendi a diretiva ssl_bump tem três modos de trabalho:

• Nenhum: o tráfego HTTPS não é interceptado, o cliente se conecta diretamente ao servidor remoto, o squid só encaminha o tráfego.
• Cliente primeiro: O cliente se conecta ao Squid via SSL (na primeira conexão o usuário tem que aceitar o certificado SSL do Squid), e o Squid se conecta ao servidor, aceitando automaticamente seu certificado SSL. (Ou existem opções para aceitar apenas alguns certificados e recusar outros?)
• Servidor primeiro: o Squid se conecta ao servidor, aceita o certificado SSL e ...? Documentação do Squid diz:

Establish a secure connection with the server first, then establish a secure connection with the client, using a mimicked server certificate.

O que significa "certificado de servidor imitado"? O Squid produz uma cópia falsa do certificado (?) Aquela recebida do servidor remoto? Tentei configurar um ssl_bump server_first do Squid, mas toda vez que me conecto a um site HTTPS o navegador me avisa que os certificados são incompatíveis, e se eu examinar o certificado vejo que é sempre o mesmo, criado durante a instalação do Squid. ..Eu não vejo nenhuma diferença com o comportamento "Cliente primeiro", então ...

Eu sei que a interceptação de SSL não é um procedimento seguro, mas estou explicando esse recurso porque posso ser forçado a usá-lo ...

Obrigado antecipadamente.

    

Answer 1

A diferença entre o primeiro servidor e o primeiro cliente é a mensagem de erro que o usuário acaba vendo (ou não vendo)

Com o bump SSL do primeiro cliente, há três problemas:

1. O certificado SSL apresentado não corresponde ao destino; por exemplo. O cliente vê que o certificado SSL é emitido para proxy.yourdomain.com, mas o usuário está tentando visitar www.securewebsite.com. O navegador deles irá avisá-los sobre isso. (ruim)
2. O certificado SSL é de uma autoridade de certificação não confiável. Seu navegador irá avisá-los sobre isso também. (ruim)
3. Se houver um problema com o certificado SSL do servidor, não há uma boa maneira de informar o cliente. No momento em que o Squid descobre que há um erro (talvez esteja vencido, não confiável, para o site errado, etc.), o cliente já possui um certificado SSL "bom" e acha que está prestes a receber o tráfego real. O navegador deles não pode avisá-los sobre isso. (também ruim)

O bump SSL do primeiro servidor elimina o primeiro e o terceiro problemas. O segundo permanece. Aqui está um recurso decente sobre o raciocínio para usar o SSL em primeiro lugar no servidor . Aparentemente foi escrito quando o recurso ainda estava sendo desenvolvido, então não deixe o tempo futuro confundir você.

Como você mesmo gerou o certificado, e qualquer pessoa pode gerar um certificado, simplesmente ter um certificado não significa que a comunicação é segura. O certificado tem que ser de um emissor em quem você confia. Os navegadores vêm por padrão com uma lista de autoridades de certificação confiáveis. Essas CAs atestam os certificados que vendem e é assim que o seu computador confia nos certificados.

A solução para esse problema é que você precisa dizer ao seu computador para confiar no certificado que você está usando para o SSL. O procedimento é diferente para diferentes sistemas operacionais. Para os clientes Windows, você pode enviar algo através do GPO, para dispositivos móveis, você pode enviá-lo para fora com o MDM, etc.

Apenas para testes (no Windows), você pode clicar com o botão direito do mouse no certificado e escolher instalar. Caminhe pelo assistente. Em vez de deixar as janelas escolherem onde colocar o certificado, navegue e selecione Autoridades de certificação raiz confiáveis. Uma vez feito isso, o seu computador irá confiar em qualquer certificado gerado pelo seu servidor SSL-bump do squid.