Informações de plano de fundo
O SSL é projetado para proteger o nível de transporte na Internet. Para a 'web' aka HTTP, você saberá isso como HTTPS, mas também é usado para outros protocolos de aplicativo. O SSLv2 foi o primeiro protocolo de segurança de transporte amplamente utilizado, mas foi considerado inseguro não muito tempo depois. Os sucessores SSLv3 e TLSv1 são amplamente suportados agora. TLSv1.1 e TLSv1.2 são mais recentes e ganham muito suporte também. A maioria, se não todos os navegadores da Web lançados em 2014, tem suporte para isso.
A recente descoberta pelos engenheiros do Google aponta que o SSLv3 não deve mais ser usado (como o SSLv2 está obsoleto há muito tempo). Os clientes que não conseguirão se conectar ao seu site / serviço provavelmente são muito limitados. CloudFlare anunciou que menos de 0,09% de seus visitantes ainda contam com SSLv3.
Solução simples: desative o SSLv3.
O Ubuntu fornece alguma atualização?
Sim, através do usn-2385-1 com a adição do recurso SCSV, mas isso não atenua o problema completamente , já que ele não desabilita o SSLv3 e o patch só funcionará se ambos os lados da conexão tiverem sido corrigidos. Você receberá através de suas atualizações de segurança regulares em seu gerenciador de pacotes.
Portanto, ainda você precisa tomar medidas para desativar o SSLv3 (é configurável). Versões futuras de clientes / navegadores desativarão o SSLv3 mais provavelmente. Por exemplo. O Firefox 34 fará isso.
Desativar SSLv3 completamente por padrão no Ubuntu no nível de implementação provavelmente irá quebrar algumas coisas lá fora também para o uso de SSL não-HTTPS que não é muito vulnerável, então eu suponho que mantenedores não farão isso e somente esse patch SCSV será aplicado.
Por que a atualização do SCSV no OpenSSL via usn-2385-1 não atenua o problema?
Realmente, pare de fazer essas perguntas e pule alguns parágrafos e desative o SSLv3. Mas ei, se você não está convencido, aqui vai:
POODLE mostra que SSLv3 com cifras CBC está quebrado, implementar o SCSV não altera isso. O SCSV só garante que você não faça o downgrade de algum protocolo TLS para qualquer protocolo TLS / SSL mais baixo, conforme necessário, com o ataque Man-in-the-Middle necessário para os casos usuais.
Se você tiver que acessar algum servidor que não ofereça TLS, mas somente SSLv3, então seu navegador realmente não tem escolha e precisa falar com o servidor usando SSLv3, que é então vulnerável sem qualquer ataque de downgrade .
Se você precisar acessar algum servidor que ofereça TLSv1 + e SSLv3 também (o que não é recomendado) e quiser ter certeza de que sua conexão não será rebaixada para SSLv3 por um invasor, então ambos o servidor e o cliente precisa deste patch SCSV.
Para mitigar completamente o problema, a desativação do SSLv3 é suficiente e você pode ter certeza de que não será rebaixado. E você não poderá conversar com servidores somente SSLv3.
Ok, então como desativar o SSLv3?
Veja abaixo nas seções específicas da aplicação: Firefox, Chrome, Apache, Nginx e Postfix são cobertos por enquanto.
Somente servidores ou clientes são afetados?
A vulnerabilidade existe se o servidor e o cliente aceitarem SSLv3 (mesmo se ambos forem capazes de TLSv1 / TLSv1.1 / TLS1.2 devido a um ataque de downgrade).
Como administrador do servidor, você deve desativar o SSLv3 agora para a segurança de seus usuários.
Como usuário, você deve desativar o SSLv3 no seu navegador now para proteger-se ao visitar sites que ainda suportam SSLv3.
Este OpenSSL / GnuTLS / navegador é específico?
Não. É um bug de protocolo (design), não um bug de implementação. Isso significa que você não pode realmente corrigir (a menos que você esteja alterando o design do antigo SSLv3).
E sim, há um novo lançamento de segurança do OpenSSL , mas leia abaixo ( Mas eu realmente realmente precisa de suporte a SSLv3 ... para o motivo X, Y, Z! ) sobre por que você deveria se concentrar em desabilitar o SSLv3 completamente.
Posso matar o SSLv3 no nível da rede (firewall)?
Bem, sim, provavelmente. Eu coloquei isso em um post separado para mais pensamentos e trabalhos. Podemos ter alguma regra mágica iptables que você pode usar!
Minha postagem no blog: Como remover o SSLv3 da sua rede usando o iptables para o POODLE?
É relevante apenas para HTTPS ou também para IMAP / SMTP / OpenVPN e outros protocolos com suporte a SSL?
O vetor de ataque atual, como mostrado pelos pesquisadores, trabalha com o controle do texto plano enviado ao servidor usando o JavaScript sendo executado na máquina da vítima. Esse vetor não se aplica a cenários não HTTPS sem usar um navegador.
Além disso, normalmente um cliente SSL não permite que a sessão seja rebaixada para SSLv3 (tendo o TLSv1 + visto nos recursos de handshake), mas os navegadores querem ser muito retrocompatíveis e o fazem. A combinação com o controle de texto simples e a maneira específica como um cabeçalho HTTP é construído torna-o explorável.
Conclusão: desabilite o SSLv3 para HTTPS agora , desabilite o SSLv3 para outros serviços na sua próxima janela de serviço.
Qual o impacto? Preciso revogar e regenerar meu certificado de servidor? (Como no Heartbleed)
Não, você não precisa rotacionar seus certificados para isso. A vulnerabilidade expõe a recuperação de texto sem formatação dos dados da sessão, não fornece acesso a nenhum segredo (nem a chave de sessão nem a chave de certificado).
É mais provável que um invasor apenas roube os cabeçalhos de texto simples, como cookies de sessão, para executar o seqüestro de sessão . Uma restrição adicional é a necessidade de um ataque de MitM completo (ativo) .
Há mais alguma coisa que eu possa fazer para melhorar minha configuração de SSL em geral?
Como usuário, além de desabilitar o SSLv3 no seu navegador, na verdade não. Bem, apenas sempre instale as atualizações de segurança mais recentes.
Para servidores, siga o guia do servidor TLS da Mozilla . E teste com o teste SSL Labs da Qualys . Não é tão difícil conseguir uma classificação A + no seu site. Basta atualizar seus pacotes e implementar as recomendações do guia do Mozilla.
Mas eu realmente preciso de suporte ao SSLv3 ... para o motivo X, Y, Z! E agora?
Bem, há um patch que contorna o ataque de downgrade de clientes com capacidade de TLSv1, chamado de proteção contra fallback SSLv3. Isso irá melhorar a segurança do TLSv1 + também, a propósito (o ataque de downgrade é mais difícil / impossível). É oferecido como backport de uma versão mais recente do OpenSSL no usn-2385-1 . .
Grande problema: os clientes e servidores precisam desse patch para funcionar. Então, na minha opinião, enquanto você está atualizando ambos os clientes e servidores, você deve apenas atualizar para o TLSv1 + de qualquer maneira.
No entanto, por favor, apenas retire o SSLv3 na sua rede por enquanto. Coloque empenho na atualização dos padrões de segurança e apenas dispense o SSLv3.
Ouvi falar do suporte ao SCSV para eliminar o ataque de downgrade do protocolo. Eu preciso disso?
Somente se você realmente precisar do SSLv3 por algum motivo estranho, mas também melhora a segurança no TLSv1 +, então sim, eu recomendo que você o instale. O Ubuntu fornece uma atualização para esse recurso em usn-2385-1 . Você receberá através de suas atualizações de segurança regulares em seu gerenciador de pacotes.
Teste de vulnerabilidade para sites hospedados em particular (por exemplo, intranet / offline).
Seus servidores são vulneráveis simplesmente se eles suportarem SSLv3. Várias opções aqui:
-
Com o OpenSSL s_client:
openssl s_client -connect <server>:<port> -ssl3Se a conexão for bem-sucedida, o sslv3 está ativado. Se falhar, está desativado. Quando falhar, você verá algo como:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure -
Usando
nmap:nmap --script ssl-enum-ciphers -p 443 myhostname.tldDeverá produzir '
SSLv3: No supported ciphers found'. Ajuste para o seu nome de host / porta. -
Usando cipherscan . Clone / faça o download do binário e execute:
./cipherscan myhostname.tldEle deve não listar qualquer coisa com SSLv3 na coluna 'protocols'.
Navegador Firefox
Abra about:config , encontre security.tls.version.min e defina o valor como 1 . Em seguida, reinicie seu navegador para descartar quaisquer conexões SSL abertas.
O Firefox da versão 34 em diante desabilitará o SSLv3 por padrão e, portanto, não exigirá nenhuma ação ( source ). No entanto, no momento da escrita, 33 acaba de ser lançado e 34 está marcado para 25 de novembro.
Google Chrome (Linux)
Edite o arquivo /usr/share/applications/google-chrome.desktop , por exemplo,
sudo nano /usr/share/applications/google-chrome.desktop
Edite todas as linhas começando com Exec= para incluir --ssl-version-min=tls1 .
Por exemplo uma linha como
Exec=/usr/bin/google-chrome-stable %U
torna-se
Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U
Em seguida, certifique-se de fechar totalmente o navegador (os aplicativos do Google Chrome podem manter seu navegador ativo em segundo plano!).
Observação: você pode precisar repetir essa atualização todos os pacotes do google-chrome, sobrescrevendo esse arquivo .desktop launcher. Um navegador Google Chrome ou Chromium com SSLv3 desativado por padrão ainda não foi anunciado no momento da publicação.
Servidor HTTPD Apache
Se você estiver executando um servidor web Apache que atualmente permite SSLv3, você precisará editar a configuração do Apache. Nos sistemas Debian e Ubuntu, o arquivo é /etc/apache2/mods-available/ssl.conf . No CentOS e no Fedora o arquivo é /etc/httpd/conf.d/ssl.conf .Você precisará adicionar a seguinte linha à sua configuração do Apache com outras diretivas SSL.
SSLProtocol All -SSLv2 -SSLv3
Isso permitirá todos os protocolos, exceto SSLv2 e SSLv3.
Enquanto você está nisso, você pode querer considerar melhorar a configuração do ciphersuite para o seu servidor, como explicado no servidor TLS da Mozilla guia . Adicione por exemplo:
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder on
SSLCompression off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"
Em seguida, verifique se a nova configuração está correta (sem erros de digitação, etc.):
sudo apache2ctl configtest
E reinicie o servidor, por exemplo,
sudo service apache2 restart
No CentOS e no Fedora:
systemctl restart httpd
Mais informações: Documentação do Apache
Agora teste-o: se o seu site estiver disponível publicamente, teste-o usando a ferramenta Qualys SSL Labs .
Servidor Nginx
Se você estiver executando o Nginx, inclua a seguinte linha em sua configuração entre as outras diretivas SSL:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Enquanto você está nisso, você pode considerar a possibilidade de melhorar a configuração do ciphersuite para o seu servidor, conforme explicado no servidor TLS da Mozilla guia . Adicione por exemplo:
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;
E reinicie o servidor, por exemplo,
sudo service nginx restart
Referência: documentação do Nginx
Agora teste: se seu site estiver disponível publicamente, teste-o usando a ferramenta Qualys 'SSL Labs .
Servidor da Web do Lighttpd
As versões do Lighttpd & gt; 1.4.28 suportam uma opção de configuração para desativar o SSLv2 e v3. As versões do Lighttpd anteriores a 1.4.28 permitem desativar o SSLv2 APENAS. Por favor, note que o Ubuntu 12.04 LTS e anteriores instalam o melhor no lighttpd v1.4.28 e, portanto, uma simples correção não está disponível para essas distribuições. Portanto esta correção deve ser usada apenas para versões do Ubuntu maiores que 12.04.
Para o Ubuntu versão 12.04 ou Debian 6, um pacote lighttpd atualizado está disponível no repositório do openSUSE: link
O pacote é destinado ao Debian 6 (squeeze) mas funciona também no 12.04 (precisas)
Edite seu /etc/lighttpd/lighttpd.conf para adicionar as seguintes linhas após a diretiva ssl.engine = "enable"
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
Em seguida, você deve reiniciar o serviço lighttpd com sudo service lighttpd restart e realizar um teste de handshake ssl3, conforme descrito nas seções anteriores, para garantir que a alteração foi implementada com êxito.
SMTP do postfix
Para 'SSL oportunista' (a política de criptografia não é aplicada e a planície é aceitável também), não é necessário alterar nada. Mesmo o SSLv2 é melhor que simples, então se você precisar proteger seu servidor, você deve estar usando o modo 'obrigatório SSL' de qualquer maneira.
Para o modo "obrigatório SSL" já configurado, basta adicionar / alterar a configuração smtpd_tls_mandatory_protocols para a entrada conexões e smtp_tls_mandatory_protocols para conexões de saída:
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
Opcionalmente, se você quiser desabilitar o SSLv3 para criptografia oportunista (mesmo que seja desnecessário como explicado acima), faça-o assim:
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3
e reinicie o Postfix:
sudo service postfix restart
Sendmail
(Edição não verificada por usuário anônimo, não me sinto confortável com o Sendmail, por favor verifique.)
Essas opções são configuradas na seção LOCAL_CONFIG do seu sendmail.mc
LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
Dovecot
No Dovecot v2.1 +, adicione o seguinte ao seu /etc/dovecot/local.conf (ou um novo arquivo em /etc/dovecot/conf.d ):
ssl_protocols = !SSLv2 !SSLv3
e reinicie o Dovecot:
sudo service dovecot restart
Para versões mais antigas, você terá que corrigir o código-fonte .
Courier-imap (imapd-ssl)
Courier-imap permite SSLv3 por padrão no Ubuntu 12.04 e outros. Você deve desativá-lo e usar STARTTLS para forçar o TLS. Edite seu arquivo de configuração /etc/courier/imapd-ssl para refletir as seguintes alterações
IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"
Servidor HAProxy
SSL é suportado em HAProxy & gt; = 1.5.
Edite o arquivo /etc/haproxy.cfg e encontre sua linha bind . Anexar no-sslv3 . Por exemplo:
bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3
Referência: Documentação HAProxy
OpenVPN
Parece não ser afetado ( fonte ).
O OpenVPN usa TLSv1.0 ou (com & gt; = 2.3.3) como opção TLSv1.2 e, portanto, não é afetado por POODLE.
Fantoche
O Puppet usa SSL em HTTPS, mas não é usado por clientes "browser", apenas agentes Puppet que não são vulneráveis ao vetor de ataque mostrado.No entanto, é uma prática recomendada apenas desativar o SSLv3.
Minha recomendação é usar o módulo stephenrjohnson / puppetmodule Puppet para configurar seu mestre de marionetes no qual Eu matei o SSLv3 há algum tempo.