Minha primeira intenção foi encontrar uma Autoridade Certificadora Confiável pública que permitisse a inspeção SSL, no servidor proxy Squid, de forma automática, gratuita e, preferencialmente, sem qualquer intervenção por parte dos clientes ou administradores de rede. Infelizmente, já adianto que não é possível utilizar uma Autoridade Certificadora Confiável pública para assinar os certificados temporários (fake) gerados pelo SSL-Bump, mesmo tendo posse da chave privada (dificilmente será autorizado) – há um entendimento comum de que isto comprometeria ainda mais a segurança na Internet.
As soluções gratuitas que mais chamaram minha atenção foram: StartSSL e LetsEncrypt.
O projeto que despertou meu interesse rapidamente foi o LetsEncrypt. Graças ao protocolo ACME (suportado nativamente pelos navegadores mais atuais), o processo é automatizado, inteligente e extremamente simples. O projeto foi iniciativa de um grupo especializado em segurança na Internet (ISRG) e conta com patrocínio de empresas como: Mozilla, Akamai, Cisco, EFF, Facebook, Chrome e etc.
O processo de instalação e emissão do certificado é espantosamente simples, mas sua aplicação pode causar certa confusão, principalmente na configuração de servidores proxy.
O certificado gerado é para validação de domínio e, até o presente momento, não suporta coringa (wildcard), porém o suporte já está previsto para o início de 2018. Sendo assim, é necessário criar um certificado por domínio ou múltiplos domínios (são referências FQDN – nome completo).
“Vale ressaltar que o certificado expirará após 90 dias. Mas, não se preocupe, a solução permite agendar a renovação automática.“
Se você não está familiarizado com certificados digitais, recomendo a seguinte leitura:
https://www.secnet.com.br/blog/o-que-e-certificado-ssl-o-guia-definitivo
Conforme exposto em outros artigos, Ubuntu é a distribuição que costumamos utilizar como referência. Portanto, o processo de instalação descrito, logo a seguir, é baseado na documentação oficial do certbot para Ubuntu 16.
$ sudo apt-get update $ sudo apt-get install software-properties-common $ sudo add-apt-repository ppa:certbot/certbot $ sudo apt-get update $ sudo apt-get install certbot
Apesar de simples, existem diferentes opções para a geração dos certificados – ambas via ferramenta certbot. Todas as etapas são tratadas, pela ferramenta, como um processo de instalação, gerenciado por diferentes plugins, como: apache, webroot, nginx, standalone ou manual.
Para gerar o certificado é preciso comprovar autoridade sobre o domínio em questão. A validação pode ser feita por HTTP, HTTPS ou DNS. Os plugins permitem diferenciar o perfil de instalação e métodos de validação. E, através da opção preferred-challenges, podemos selecionar o método preferencial (http-01, tls-sni-01 ou dns-01).
Para evitar que a configuração do servidor sofra qualquer ajuste imprevisto, recomendo optar entre os plugins manual ou standalone.
Geralmente, optamos pelo plugin manual, selecionando a validação por DNS. Neste caso, logo que solicitado (“Press Enter to Continue“), o administrador precisará criar um registro de DNS (TXT) para prosseguir.
– Confiram um exemplo com o plugin manual:
root@srvlinux:~# certbot certonly --manual -d proxy.seu.dominio --preferred-challenges dns-01 --- Saving debug log to /var/log/letsencrypt/letsencrypt.log Obtaining a new certificate Performing the following challenges: dns-01 challenge for proxy.seu.dominio ------------------------------------------------------------------------------- NOTE: The IP of this machine will be publicly logged as having requested this certificate. If you're running certbot in manual mode on a machine that is not your server, please ensure you're okay with that. Are you OK with your IP being logged? ------------------------------------------------------------------------------- (Y)es/(N)o: y ------------------------------------------------------------------------------- Please deploy a DNS TXT record under the name _acme-challenge.proxy.seu.dominio with the following value: fmQ...zPAg Before continuing, verify the record is deployed. ------------------------------------------------------------------------------- Press Enter to Continue Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/proxy.seu.dominio/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/proxy.seu.dominio/privkey.pem Your cert will expire on 2017-12-10. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
– Assim que o código for exibido, o registro de DNS pode ser mapeado da seguinte maneira (no Bind9):
_acme-challenge.proxy.seu.dominio. 300 IN TXT "fmQ...zPAg"
“Caso encontre dificuldade, certifique-se de que o servidor esteja acessível remotamente e tente a validação através do plugin standalone. Vale lembrar que, por padrão, a ferramenta irá instanciar um socket na porta 443 (ou 80, se especificado via preferred-challanges). Logo, se houver algum serviço ouvindo nesta porta, primeiro será necessário finalizar o serviço em questão.“
Não há muito mistério, a obtenção do certificado é bastante simples.
A ferramenta openssl permitirá analisar o certificado gerado, por exemplo:
root@srvlinux:~# openssl x509 -in /etc/letsencrypt/live/proxy.seu.dominio/cert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:51:1e:d3:13:1a:d3:af:93:b3:c3:fd:3b:bb:a3:30:b3:13
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: Sep 12 17:49:00 2017 GMT
Not After : Dec 11 17:49:00 2017 GMT
Subject: CN=proxy.seu.dominio
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
...
Conforme informado anteriormente, os certificados expirarão após 90 dias. É possível utilizar o mesmo comando para atualizar ou recriar os certificados, mas o ideal é incluir uma nova entrada no cron, executando a ferramenta certbot com a opção renew.
A chamada pode ser programada através de um script no diretório /etc/cron.weekly ou via crontab:
root@srvlinux:~# crontab -e 0 1 * * 1 /usr/bin/certbot renew --quiet > /var/log/cerbot.log
Confiram outras referências:
https://imasters.com.br/infra/seguranca/certificado-ssl-gratuito-com-o-lets-encrypt/?trace=1519021197
https://seginfo.com.br/2015/12/09/guia-passo-a-passo-para-instalar-o-certificado-ssl-gratuito-da-lets-encrypt-no-seu-site-2/
https://consortiumlibrary.org/blogs/mcrobinson/blog/tag/lets-encrypt/
Agora, a pergunta que não quer calar:
É possível utilizar este certificado no Squid?
TALVEZ, dependerá da necessidade. Se o objetivo for viabilizar inspeção SSL a resposta é NÃO, pois o ssl-bump funcionará apenas com certificados autoassinados e a chave privada da Lets-encrypt é restritiva. Mas, como os certificados são emitidos para validação de domínio (FQDN), podemos utilizá-los em configurações de proxy reverso. Outra alternativa é a configuração como proxy SSL. É evidente que, em ambos os casos, o maior benefício – e talvez o único – é a possibilidade de proteger os dados trafegados (encriptando o conteúdo) na Internet (proxy reverso) ou rede local (proxy SSL).
Resumindo: este certificado não poderá ser utilizado para assinar outros domínios.
“Para inspeção SSL deve-se trabalhar obrigatoriamente com certificado autoassinado“
Encontrei um blog demonstrando a configuração da porta HTTPS (opção https_port):
http://sckghost.blog.51cto.com/4762240/1939793
Olhando o passo a passo do blog parece simples, não? Nem tudo é o que parece (risos)!
Na prática, o que foi demonstrado no blog acima foi a configuração de um proxy SSL (https_port, sem opção ssl-bump). O único benefício será a encriptação do conteúdo de navegação (criptografando o tráfego entre os clientes e o servidor proxy), mas as conexões SSL continuarão sendo processadas via método CONNECT. Percebam que, para controle de acesso ou conteúdo, não muda nada.
Ainda assim, a configuração demonstrada impõe dificuldades adicionais nos clientes…
A maioria dos navegadores permite a configuração de proxy por tipo de protocolo, porém, o tipo de proxy padrão é HTTP (mesmo que a escolha do protocolo seja SSL/HTTPS ou FTP, por exemplo) – isto inclui também configurações com detecção automática de proxy (WPAD). Um cliente HTTP não será capaz de negociar o certificado com o servidor e retornará erro de conexão. Por esta razão, você não poderá especificar a porta HTTPS do Squid diretamente na opção de configuração manual de proxy do navegador.
Neste caso, você precisaria instalar nos navegadores alguma extensão compatível com proxy SSL, como o FoxProxy para o navegador Firefox – basta ativar, na configuração de endereço e porta do FoxProxy, a opção proxy SSL. Diante da relação custo x benefício, não vejo muito sentido deste tipo de configuração em redes corporativas.
Por outro lado, a inspeção SSL oferece diferentes tipos de vantagem, como: capacidade de identificar URLs completas, filtragem de conteúdo e cache. Aliás, tenho percebido que pouquíssimos sites não trabalham sob HTTPS – em termos de segurança é um ótimo sinal. Atualmente, quase toda referência ao Google é encriptada, até mesmo uma simples busca.
Para maiores informações quanto a configuração do ssl-bump:
http://linuxfirewall.com.br/linuxwp/instalacao-e-configuracao-do-squid-basico-parte-44/
No Comments Yet