Questão Como faço para corrigir / solucionar vulnerabilidade SSLv3 POODLE (CVE-2014-3566)?


Depois de Ataque de besta e Bug Heartbleedagora ouvi falar de uma nova vulnerabilidade em SSL / TLS chamada POODLE. Como me protejo de ser explorado?

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

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


158
2017-10-14 23:49


origem


Mais informações podem ser encontradas aqui Vulnerabilidade "Poodle" SSL3 - Braiam
@Braiam Sim, eu sei, o brilhante Thomas de novo! No entanto, essa é uma sessão de perguntas e respostas muito criptográfica. Este Q & A no AU deve fornecer informações práticas e orientadas ao Ubuntu. :-) - gertvdijk
Hã? Como você espera uma solução mais prática do que "Se você não instalar os patches, Níðhöggr irá devorar o seu baço". - Braiam
@Braiam Primeiro de tudo: não há patch (leia minha resposta). Eu acho que Thomas está se referindo a aparelhos ao invés de hospedagem de servidor web DIY-Ubuntu. Aparelhos como balanceadores de carga geralmente oferecem atualizações de firmware para alterar as configurações padrão ou oferecem funcionalidade para configurá-lo. No entanto, no Ubuntu, tudo depende do usuário / administrador. - gertvdijk
Na verdade, existem: os fornecedores podem desabilitar / remover todos os códigos relacionados ao SSLv3, portanto, você não precisa tocar em nada. - Braiam


Respostas:


Informação de fundo

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 feita 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 anunciado que menos de 0,09% de seus visitantes ainda confiam no SSLv3.

Solução simples: desabilite o SSLv3.

O Ubuntu fornece alguma atualização?

Sim, via usn-2385-1 com a adição do recurso SCSV, mas isso não atenua completamente o problema já que ele não desativa 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.

Ainda assim VOCÊ tem que tomar medidas para desabilitar 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 SSL não-HTTPS que não é muito vulnerável, então eu suponho que mantenedores não farão isso e somente este 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 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 apenas SSLv3, então seu navegador realmente não tem escolha e precisa conversar com o servidor usando SSLv3, que é vulnerável sem nenhum ataque de downgrade.

Se você tiver que acessar algum servidor que ofereça TLSv1 + e SSLv3 também (o que é desencorajado) e você quer ter certeza de que sua conexão não será rebaixada para SSLv3 por um atacante, então ambos o servidor e o cliente precisam desse 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 desabilito o SSLv3?

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

São apenas servidores ou clientes 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 desabilitar o SSLv3 agora para a segurança de seus usuários.

Como usuário, você deve desativar o SSLv3 no seu navegador agora para proteger-se ao visitar sites que ainda suportam o SSLv3.

Este OpenSSL / GnuTLS / browser é 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 Liberação de segurança do OpenSSL, mas leia abaixo (Mas eu realmente preciso de suporte ao SSLv3 ... para a razão X, Y, Z!) por que você deveria se concentrar em desabilitar 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. Nós podemos ter alguma magia iptables regra você pode usar!

Minha postagem no blog: Como derrubar o SSLv3 em 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 atual vetor de ataque, 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 o torna 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).

Provavelmente, um invasor só é capaz de roubar os cabeçalhos de texto simples, como cookies de sessão, para executar seqüestro de sessão. Uma restrição adicional é a necessidade de um completo (ativo) Ataque MitM.

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 Guia do servidor TLS da Mozilla. E teste com Teste de laboratórios SSL 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 a razão X, Y, Z! O que agora?

Bem, há um patch que contorna o ataque de downgrade de clientes com capacidade de TLSv1, chamado de SSLv3 Fallback Protection. 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 comunicado de Segurança do Ubuntu usn-2385-1.

Big catch: Ambos os clientes e servidores precisam deste 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 aposente o SSLv3 na sua rede por enquanto. Esforce-se para atualizar os padrões de segurança e descartar o SSLv3.

Ouvi falar do suporte do 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 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> -ssl3
    

    Se a conexão for bem-sucedida, o sslv3 está ativado. Se falhar, está desativado. Quando falhar, 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 cipherscan. Clone / faça o download do binário e execute-o:

    ./cipherscan myhostname.tld
    

    Deveria não liste qualquer coisa com SSLv3 na coluna 'protocols'.


Navegador Firefox

Aberto about:config, encontrar security.tls.version.min e defina o valor para 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 (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.desktop arquivo, por exemplo

sudo nano /usr/share/applications/google-chrome.desktop

Editar todas as linhas começando com Exec= 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: talvez seja necessário repetir essa atualização todos os pacotes do google-chrome, sobrescrevendo isso .desktop arquivo de inicialização. Um navegador Google Chrome ou Chromium com SSLv3 desativado por padrão ainda não foi anunciado no momento da gravação.


Servidor Apache HTTPD

Se você estiver executando um servidor da web Apache que atualmente permite o 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, você pode querer considerar melhorar a configuração do ciphersuite para o seu servidor web como explicado em 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 ex.

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 publicamente, teste-o usando Ferramenta de laboratórios SSL da Qualys.


Servidor Nginx

Se você estiver executando o Nginx, apenas 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 querer considerar melhorar a configuração do ciphersuite para o seu servidor web como explicado em 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 ex.

sudo service nginx restart

Referência: Documentação Nginx

Agora teste: se seu site estiver disponível publicamente, teste-o usando Ferramenta de laboratórios SSL 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 a 1.4.28 permitem desativar o SSLv2 APENAS. Por favor, note que o Ubuntu 12.04 LTS e anteriores instalam no melhor modo o lighttpd v1.4.28 e, portanto, uma simples correção não está disponível para essas distribuições.  Portanto, essa correção só deve ser usada 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: http://download.opensuse.org/repositories/server:/http/Debian_6.0

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

Edite seu /etc/lighttpd/lighttpd.conf para adicionar as seguintes linhas após o ssl.engine = "enable" diretiva

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

Então você deve reiniciar o serviço lighttpd com um sudo service lighttpd restart e execute um teste de handshake ssl3, conforme descrito nas seções anteriores, para garantir que a alteração foi implementada com êxito.

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


SMTP do postfix

Para "SSL oportunista" (política de criptografia não aplicada e simples também é aceitável), você não precisa alterar nada. Mesmo 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 'SSL obrigatório' já configurado, basta adicionar / alterar o smtpd_tls_mandatory_protocols configuração 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ê 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

Enviar correio

(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 no LOCAL_CONFIG seção 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

Pombinha

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 remendar 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 /etc/courier/imapd-ssl arquivo 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

SSL é suportado em HAProxy> = 1.5.

Edite o /etc/haproxy.cfg arquivar e encontrar o seu bind linha. Acrescentar 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 o TLSv1.0 ou (com> = 2.3.3) como opção o TLSv1.2 e, portanto, não é afetado pelo POODLE.


Fantoche

O Puppet usa SSL sobre 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, a melhor prática é apenas desabilitar o SSLv3.

Minha recomendação é usar o stephenrjohnson / puppetmodule Módulo Puppet para configurar o seu mestre Puppet em que Eu matei SSLv3 algum tempo atrás.


210
2017-10-14 23:49



Esta resposta foi criada muito rapidamente após o lançamento público da vulnerabilidade. Pode haver erros lá ainda - como sempre, sinta-se à vontade para editar / melhorar. - gertvdijk
Configuração Nginx não deve ter dois pontos após a diretiva ssl_protocols - Michelle
Tudo bem, para o Firefox eu acredito esta é o que está acontecendo. - fuglede
Este post de blog da Mozilla Security sugere a instalação este complemento em vez de ajustar as preferências manualmente. - legoscia
@muru Aqui está um ponto de partida para matar o SSLv3 no nível do firewall. blog.g3rt.nl/take-down-sslv3-using-iptables.html - gertvdijk


Pode não ser específico do Ubuntu, mas para contornar o vulnerabilidade do Poodle no Node.js você pode definir o secureOptions para require('constants').SSL_OP_NO_SSLv3 quando você cria um servidor https ou tls.

Vejo https://gist.github.com/3rd-Eden/715522f6950044da45d8 para informação adicional


4
2017-10-15 08:59



IMO você não deve expor HTTP (S) com Node / Python / Ruby ou qualquer coisa assim diretamente. Coloque um HTTPd decente na frente dele como o Apache / Nginx / ... - gertvdijk
Sim, você não deveria estar expondo diretamente. As linguagens não são tão boas com o HTTP da camada tcp, mas elas se agitam fazendo soquetes. Deixe o nginx lê-lo de um soquete. :-) - jrg♦
Isso não mereceu um voto baixo. Há muitos casos em que o tls é usado além de hospedar um servidor http. - psanford
@gertvdijk & jrg O Node.js não é um idioma. É uma estrutura para criar aplicativos de rede escaláveis. E como você afirma que você deve colocar o Node.js atrás de um servidor Apache (e até chamá-lo de "decente") já deixa claro que você não tem absolutamente nenhuma idéia do que está falando. Declarar que eles não são bons com o tpc / http é obviamente um viés pessoal. Por favor, apenas fique no tópico instável da tecnologia de votação infantil que você não entende. - 3rdEden
@ 3rdEden Bem, talvez meu comentário tenha sido um pouco generalizador, mas aqui estão algumas notas que gostaria de fazer. 1) Eu não downvote, 2) meu comentário foi um gentil 'IMO', 3) Talvez seja apenas o meu fundo em segurança, mas eu aprendi que não se deve expor uma estrutura de aplicação diretamente para 80/443 para o mundo em Produção. (a menos que para fins de demonstração). 4) Não vejo como o seu post é uma 'resposta' para a pergunta do visitante geral do Ask Ubuntu; é muito específico para um determinado caso específico de implementações do Node.js. - gertvdijk


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

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


0
2018-02-27 14:45





Desde POODLE Vulnerabilidade é uma falha de design no próprio protocolo e não um erro de implementação, não haverá patches. A única maneira de atenuar isso é desabilitar o SSLv3 no servidor apache. Adicione as linhas abaixo em ssl.conf e faça uma reinicialização graciosa 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"

-1
2017-10-15 22:55



-1 para incluir RC4 e ECDSA não funcional, pois a maioria das pessoas possui certificados RSA. Por favor, apenas leia como configurar seu servidor corretamente. wiki.mozilla.org/Security/Server_Side_TLS - gertvdijk
@gertvdijk Eu concordo com você sobre a RC4, mas não faz mal incluir suítes ECDSA. É inofensivo se você tiver apenas um certificado RSA e poupar o trabalho de corrigir sua configuração se, posteriormente, você obtiver um certificado ECDSA. - Matt Nordhoff
@MattNordhoff É justo, mas o que quero dizer é que não são deixados muitos códigos para uma configuração baseada em certificados RSA. Ele funcionará na maioria dos navegadores, mas um pode enfrentar problemas de compatibilidade. - gertvdijk
Definitivamente, livre-se do RC4 desta lista, isso não é seguro. Fique com o restante, se puder. O 3DES é fraco, mas eu o transformei em um lugar específico para compatibilidade. Eu odeio fazer isso já que é fraco, mas pelo menos não está realmente quebrado ... - Brian Knoblauch