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

157

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.

gertvdijk
fonte
2
Mais informações podem ser encontradas aqui Vulnerabilidade SSL3 "Poodle"
Braiam 15/10/14
1
@Braiam Sim, eu sei, o brilhante Thomas novamente! No entanto, essa é uma pergunta e resposta muito criptográfica. Este Q&A na AU deve fornecer informações práticas e orientadas ao Ubuntu. :-)
gertvdijk 15/10
10
Hã? Como você espera uma solução mais prática do que "Se você não instalar os patches, o Níðhöggr devorará o baço".
Braiam 15/10/14
2
@ Braiam Primeiro de tudo: não há patch (leia minha resposta). Eu acho que Thomas está se referindo a aparelhos, em vez de hospedagem de servidores DIY-Ubuntu. Aparelhos como balanceadores de carga geralmente oferecem atualizações de firmware para alterar as configurações padrão ou oferecem funcionalidade para poder configurá-lo. No entanto, no Ubuntu, tudo depende do usuário / administrador.
gertvdijk
Na verdade, existe: os fornecedores podem desativar / remover todo o código relacionado ao SSLv3; portanto, você não precisa tocar em nada.
Braiam 15/10

Respostas:

209

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.

gertvdijk
fonte
7
Esta resposta foi criada muito rapidamente após o lançamento público da vulnerabilidade. Pode haver erros ainda - como sempre, fique à vontade para editar / melhorar.
gertvdijk
1
Nginx configuração não deve ter dois pontos após directiva ssl_protocols
Michelle
1
Tudo bem, para o Firefox, acredito que é isso que está acontecendo.
Fuglede
4
Esta postagem do blog Mozilla Security sugere a instalação desse complemento em vez de ajustar as preferências manualmente.
legoscia
1
@ muru Aqui está o começo para eliminar o SSLv3 no nível do firewall. blog.g3rt.nl/take-down-sslv3-using-iptables.html #
gertvdijk 15/10
4

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

3rdEden
fonte
1
Na 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 Apache / Nginx / ...
gertvdijk
Sim, você não deveria estar expondo diretamente. Os idiomas não são tão bons com o HTTP da camada TCP, mas são ótimos para soquetes. Deixe o nginx lê-lo de um soquete. :-)
jrg
4
Isso não merecia um voto negativo. Existem 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 a criação de aplicativos de rede escaláveis. E como você afirma que 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. Afirmar que eles não são bons com tpc / http é obviamente um viés pessoal. Por favor, permaneça no tópico, não em relação à tecnologia de votação infantil que você não entende.
3Eden
@ 3rdEden Bem, talvez minha observação tenha sido um pouco generalizada, mas aqui estão algumas anotações que eu gostaria de fazer. 1) Não fiz votos negativos, 2) meu comentário foi gentil 'IMO', 3) Talvez seja apenas minha formação em segurança, mas aprendi que não se deve expor uma estrutura de aplicativos diretamente ao mundo 80/443 em 80/443. Produção. (a não ser para fins de demonstração). 4) Não vejo como sua postagem é uma 'resposta' para a pergunta do visitante geral do Ask Ubuntu; é apenas muito, muito específico, para um determinado caso específico de implantação do Node.js.
gertvdijk
0

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.

PrgWiz
fonte
-1

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"
Lal Krishna
fonte
1
-1 para incluir RC4 e ECDSA não funcional, já que a maioria das pessoas possui certificados RSA. Por favor, leia apenas como configurar seu servidor corretamente. wiki.mozilla.org/Security/Server_Side_TLS
gertvdijk 15/10
2
@gertvdijk Concordo com você sobre o RC4, mas não custa incluir suítes ECDSA. É inofensivo se você tiver apenas um certificado RSA e poupar o problema de corrigir sua configuração se você mais tarde obtiver um certificado ECDSA.
Matt Nordhoff
@MattNordhoff É justo, mas o que quero dizer é que não restam muitas cifras para uma configuração regular baseada em certificado RSA. Funcionará na maioria dos navegadores, mas pode haver problemas de compatibilidade.
gertvdijk
Definitivamente, se livrar do RC4 desta lista, isso não é seguro. Fique com o restante, se puder. O 3DES é fraco, mas ativei isso em um local específico para compatibilidade. Eu odeio fazê-lo, pois é fraco, mas pelo menos não está realmente quebrado ...
Brian Knoblauch 21/11