Como corrijo a vulnerabilidade do SSLv3 POODLE (CVE-2014-3566)?

Após o ataque do BEAST e o bug do Heartbleed , agora ouvi falar de uma nova vulnerabilidade no SSL / TLS chamada POODLE . Como me protejo contra ser explorado?

• Apenas servidores ou clientes são afetados?
• Isso é específico do OpenSSL / GnuTLS?
• Que tipo de serviços são afetados? Apenas HTTPS ou também IMAPS, SMTPS, OpenVPN, etc.?

Por favor, mostre-me exemplos de como evitar essa vulnerabilidade.

Informação de fundo

O SSL foi projetado para proteger o nível de transporte na Internet. Para 'the web', também conhecido como HTTP, você o conhece como HTTPS, mas também é usado para outros protocolos de aplicativos. O SSLv2 foi o primeiro protocolo de segurança de transporte amplamente usado, mas foi considerado inseguro pouco tempo depois. Os sucessores SSLv3 e TLSv1 são amplamente suportados agora. O TLSv1.1 e o TLSv1.2 são mais recentes e também ganham muito suporte. A maioria, se não todos os navegadores lançados a partir de 2014, têm suporte para isso.

A recente descoberta pelos engenheiros do Google indica 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. A CloudFlare anunciou que menos de 0,09% dos visitantes ainda dependem do SSLv3.

Solução simples: desative o SSLv3.

O Ubuntu fornece alguma atualização?

Sim, via usn-2385-1 com a adição do recurso SCSV, mas não atenua completamente o problema , pois não desativa o SSLv3 e o patch funcionará apenas se os dois lados da conexão tiverem sido corrigidos. Você o receberá por meio de atualizações regulares de segurança no seu gerenciador de pacotes.

Portanto, você ainda precisa tomar medidas para desativar o SSLv3 (é configurável). Versões futuras de clientes / navegadores desativarão o SSLv3 provavelmente. Por exemplo, o Firefox 34 fará isso.

Desabilitar o SSLv3 completamente por padrão no Ubuntu no nível de implementação provavelmente também quebrará algumas coisas lá para uso SSL não HTTPS que não é tão vulnerável, então presumo que os mantenedores não farão isso e apenas 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 está:

POODLE mostra que o SSLv3 com cifras CBC está quebrado, a implementação do SCSV não altera isso. O SCSV apenas garante que você não faça o downgrade de algum protocolo TLS para nenhum protocolo TLS / SSL inferior, conforme necessário, com o ataque Man-in-the-Middle necessário para os casos habituais.

Se você precisar acessar algum servidor que não ofereça TLS, mas apenas SSLv3, seu navegador não terá uma opção e precisará conversar com o servidor usando SSLv3, que fica vulnerável sem nenhum ataque de downgrade.

Se você tiver que acessar algum servidor que oferece TLSv1 + e SSLv3 também (que não é recomendado) e você quer ter certeza de sua conexão não será rebaixado para SSLv3 por um atacante, em seguida, tanto o servidor eo cliente precisará 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 apenas SSLv3.

Ok, então como desabilito o SSLv3?

Veja abaixo nas seções específicas do aplicativo: Firefox, Chrome, Apache, Nginx e Postfix estão cobertos por enquanto.

Apenas servidores ou clientes são afetados?

A vulnerabilidade existe se o servidor e o cliente aceitarem SSLv3 (mesmo que ambos sejam 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 agora para se proteger ao visitar sites que ainda oferecem suporte a SSLv3.

Esse navegador é OpenSSL / GnuTLS / específico?

Não. É um erro de protocolo (design), não um erro de implementação. Isso significa que você não pode corrigi-lo (a menos que esteja alterando o design do antigo SSLv3).

E sim, há uma nova versão de segurança do OpenSSL , mas leia abaixo ( Mas eu realmente preciso de suporte ao SSLv3 ... pelo motivo X, Y, Z! ) Sobre por que você deveria se concentrar em desabilitar completamente o SSLv3.

Posso matar o SSLv3 no nível da rede (firewall)?

Bem, sim, provavelmente. Coloquei isso em um post separado para mais reflexões e trabalho. Podemos ter alguma iptablesregra mágica que você pode usar!

Minha postagem no blog: Como remover o SSLv3 na sua rede usando o iptables para 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 sem formatação enviado ao servidor usando Javascript sendo executado na máquina da vítima. Este 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 + visível nos recursos de handshake), mas os navegadores desejam ser compatíveis com versões anteriores e o fazem. A combinação com o controle de texto sem formatação e a maneira específica como um cabeçalho HTTP é construído torna-o explorável.

Conclusão: desative o SSLv3 para HTTPS agora , desative o SSLv3 para outros serviços na sua próxima janela de serviço.

Qual o impacto? Preciso revogar e gerar novamente meu certificado de servidor? (Como com Heartbleed)

Não, você não precisa alternar 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 da sessão nem a chave do certificado).

É provável que um invasor seja capaz de roubar os cabeçalhos de texto sem formatação, como cookies de sessão, para executar o seqüestro de sessão . Uma restrição adicional é a necessidade de um ataque MitM completo (ativo) .

Há mais alguma coisa que eu possa fazer para melhorar minha configuração SSL em geral?

Como usuário, além de desativar o SSLv3 no seu navegador, na verdade não. Bem, 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 . Realmente não é tão difícil obter 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 SSLv3 ... pelo motivo X, Y, Z! O que agora?

Bem, há um patch que contorna o ataque de downgrade de clientes compatíveis com TLSv1, chamado SSLv3 Fallback Protection. A propósito, também melhorará a segurança do TLSv1 + (o ataque de downgrade é mais difícil / impossível). Ele é oferecido como backport de uma versão mais recente do OpenSSL no aviso de segurança do Ubuntu, usn-2385-1 .

Grande problema: clientes e servidores precisam desse patch para funcionar. Portanto, na minha opinião, enquanto estiver atualizando clientes e servidores, você deve apenas atualizar para o TLSv1 + de qualquer maneira.

No entanto, por favor, apenas aposente o SSLv3 na sua rede por enquanto. Esforce-se na atualização dos padrões de segurança e apenas evite 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 melhorar a segurança no TLSv1 +, então sim, eu recomendo que você o instale. O Ubuntu fornece uma atualização para esse recurso no usn-2385-1 . Você o receberá por meio de atualizações regulares de segurança no seu gerenciador de pacotes.

Teste de vulnerabilidade para sites hospedados em particular (por exemplo, intranet / offline).

Seus servidores são vulneráveis ​​simplesmente se suportarem SSLv3. Várias opções aqui:

• Com o OpenSSL s_client:

  openssl s_client -connect <server>:<port> -ssl3
  

  Se a conexão for bem-sucedida, o sslv3 estará ativado. Se falhar, está desativado. Quando falha, você deve ver algo como:

  error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
  

• Usando nmap:

  nmap --script ssl-enum-ciphers -p 443 myhostname.tld
  

  Deve sair ' SSLv3: No supported ciphers found'. Ajuste para o seu nome de host / porta.

• Usando o cipherscan . Clone / faça o download do binário e execute-o:

  ./cipherscan myhostname.tld
  

  Deve não listar qualquer coisa com SSLv3 sob a coluna 'protocolos'.

Navegador Firefox

Abra about:config, encontre security.tls.version.mine defina o valor como 1. Em seguida, reinicie o navegador para eliminar todas as conexões SSL abertas.

O Firefox da versão 34 em diante desabilita o SSLv3 por padrão e, portanto, não requer nenhuma ação ( fonte ). No entanto, no momento em que escrevo, 33 acaba de ser lançado e 34 está marcado para 25 de novembro.

Google Chrome (Linux)

Edite o /usr/share/applications/google-chrome.desktoparquivo, 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

Feche o navegador completamente (os aplicativos Chrome podem manter seu navegador ativo em segundo plano!).

Nota: pode ser necessário repetir isso a cada atualização do pacote google-chrome, substituindo esse .desktoparquivo do iniciador. Um navegador do Google Chrome ou Chromium com SSLv3 desativado por padrão ainda não foi anunciado no momento da redação.

Servidor HTTPD Apache

Se você estiver executando um servidor Web Apache que atualmente permita SSLv3, será necessário 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, considere melhorar a configuração do ciphersuite para o seu servidor da Web, conforme explicado no guia do servidor TLS da Mozilla . 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: se seu site estiver disponível ao público, teste-o usando a ferramenta SSL Labs da Qualys .

Servidor Nginx

Se você estiver executando o Nginx, inclua a seguinte linha na sua configuração entre as outras diretivas SSL:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Enquanto você está nisso, considere melhorar a configuração do ciphersuite para o seu servidor da Web, conforme explicado no guia do servidor TLS da Mozilla . 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 SSL Labs da Qualys .

Servidor web Lighttpd

As versões do Lighttpd> 1.4.28 suportam uma opção de configuração para desativar o SSLv2 e v3. As versões do Lighttpd anteriores à 1.4.28 permitem que você desabilite o SSLv2 SOMENTE. Observe que o Ubuntu 12.04 LTS e versões anteriores instalam na melhor das hipóteses o lighttpd v1.4.28 e, portanto, uma correção simples não está disponível para essas distribuições. Portanto, essa 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 openSUSE: http://download.opensuse.org/repositories/server:/http/Debian_6.0

O pacote é destinado ao Debian 6 (squeeze), mas também funciona no 12.04 (preciso)

Edite seu /etc/lighttpd/lighttpd.confpara adicionar as seguintes linhas após a ssl.engine = "enable"diretiva

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Em seguida, reinicie o serviço lighttpd com sudo service lighttpd restartae execute um teste de handshake ssl3 conforme descrito nas seções anteriores para garantir que a alteração foi implementada com êxito.

Retirado de http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL .

Postfix SMTP

Para 'SSL oportunista' (a política de criptografia não é aplicada e a planície também é aceitável), você não precisa alterar nada. Mesmo o SSLv2 é melhor que o normal, portanto, se você precisar proteger seu servidor, deverá usar o modo 'SSL obrigatório' de qualquer maneira.

Para o modo 'SSL obrigatório' já estar configurado, basta adicionar / alterar a configuração smtpd_tls_mandatory_protocols para conexões de entrada 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ê deseja desativar o SSLv3 para criptografia oportunista também (mesmo que seja desnecessário conforme explicado acima), faça o seguinte:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

e reinicie o Postfix:

sudo service postfix restart

Enviar correio

(Edição não confirmada por usuário anônimo, não estou familiarizado com o Sendmail, verifique.)

Essas opções estão configuradas na LOCAL_CONFIGseção do seusendmail.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 /etc/dovecot/local.conf(ou um novo arquivo /etc/dovecot/conf.d):

ssl_protocols = !SSLv2 !SSLv3

e reinicie o Dovecot:

sudo service dovecot restart

Para versões mais antigas, você precisará corrigir o código fonte .

Courier-imap (imapd-ssl)

O Courier-imap permite o SSLv3 por padrão no Ubuntu 12.04 e outros. Você deve desativá-lo e usar STARTTLS para forçar o TLS. Edite seu /etc/courier/imapd-sslarquivo de configuração 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

O SSL é suportado no HAProxy> = 1.5.

Edite o /etc/haproxy.cfgarquivo e encontre sua bindlinha. 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> = 2.3.3) opcionalmente TLSv1.2 e, portanto, não é afetado pelo POODLE.

Fantoche

O Puppet usa SSL sobre HTTPS, mas não é usado por clientes de 'navegadores', apenas agentes Puppet que não são vulneráveis ​​ao vetor de ataque mostrado. No entanto, é recomendável apenas desativar o SSLv3.

Minha recomendação é usar o módulo Puppet stephenrjohnson / puppetmodule para configurar seu mestre Puppet no qual matei o SSLv3 há algum tempo.

Pode não ser específico do ubuntu, mas, para contornar a vulnerabilidade do Poodle no Node.js, você pode configurá secureOptions- require('constants').SSL_OP_NO_SSLv3lo quando criar um servidor https ou tls.

Consulte https://gist.github.com/3rd-Eden/715522f6950044da45d8 para obter informações adicionais

A "correção" para o correio desativa tls 1.1 e tls 1.2. Não parece haver uma maneira de executar o courier com tls 1.1 ou superior. Uma varredura PCI no seu servidor pode voltar com a recomendação:

Configure os servidores SSL / TLS para usar apenas o TLS 1.1 ou TLS 1.2, se suportado. Configure os servidores SSL / TLS para suportar apenas conjuntos de criptografia que não usam cifras de bloco.

Como a vulnerabilidade POODLE é uma falha de design no próprio protocolo e não um bug de implementação, não haverá correções. A única maneira de mitigar isso é desativar o SSLv3 no servidor apache. Adicione as linhas abaixo ao ssl.conf e faça uma reinicialização do apache.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"