OpenSSL - OpenSSL
 | |
 | |
| Desenvolvedor (s) | O Projeto OpenSSL |
|---|---|
| lançamento inicial | 1998 |
| Versão estável | 3.0.0 (7 de setembro de 2021 ) [±] |
| Repositório | |
| Escrito em | C , Montagem , Perl |
| Modelo | Biblioteca de criptografia |
| Licença | Licença OpenSSL, v3.0 mudou para a licença Apache 2.0 |
| Local na rede Internet | www |
OpenSSL é uma biblioteca de software para aplicativos que protegem as comunicações em redes de computadores contra espionagem ou necessidade de identificar a parte na outra extremidade. É amplamente utilizado por servidores da Internet , incluindo a maioria dos sites HTTPS .
OpenSSL contém uma implementação de código aberto dos protocolos SSL e TLS . A biblioteca central , escrita na linguagem de programação C , implementa funções criptográficas básicas e fornece várias funções utilitárias. Wrappers que permitem o uso da biblioteca OpenSSL em uma variedade de linguagens de computador estão disponíveis.
A OpenSSL Software Foundation (OSF) representa o projeto OpenSSL na maioria das capacidades legais, incluindo contratos de licença de contribuidores, gerenciamento de doações e assim por diante. OpenSSL Software Services (OSS) também representa o projeto OpenSSL, para contratos de suporte.
O OpenSSL está disponível para a maioria dos sistemas operacionais do tipo Unix (incluindo Linux , macOS e BSD ) e Microsoft Windows .
História do projeto
O projeto OpenSSL foi fundado em 1998 para fornecer um conjunto gratuito de ferramentas de criptografia para o código usado na Internet. Ele é baseado em um fork do SSLeay de Eric Andrew Young e Tim Hudson, que encerrou não oficialmente o desenvolvimento em 17 de dezembro de 1998, quando Young e Hudson foram trabalhar para a RSA Security . Os membros fundadores iniciais foram Mark Cox, Ralf Engelschall, Stephen Henson, Ben Laurie e Paul Sutton.
Em maio de 2019, o comitê de gerenciamento do OpenSSL era composto por 7 pessoas e havia 17 desenvolvedores com acesso de commit (muitos dos quais também fazem parte do comitê de gerenciamento do OpenSSL). Existem apenas dois funcionários em tempo integral (bolsistas) e os demais são voluntários.
O projeto tem um orçamento de menos de um milhão de dólares por ano e depende principalmente de doações. O desenvolvimento do TLS 1.3 é patrocinado pela Akamai.
Lançamentos de versões principais
| Versão | Data de lançamento original | Comente | Última versão secundária |
|---|---|---|---|
| 0.9.1 | 23 de dezembro de 1998 |
|
0.9.1c (23 de dezembro de 1998) |
| 0.9.2 | 22 de março de 1999 |
|
0.9.2b (6 de abril de 1999) |
| 0.9.3 | 25 de maio de 1999 |
|
0.9.3a (27 de maio de 1999) |
| 0.9.4 | 9 de agosto de 1999 |
|
0.9.4 (9 de agosto de 1999) |
| 0.9.5 | 28 de fevereiro de 2000 |
|
0.9.5a (1 de abril de 2000) |
| 0.9.6 | 24 de setembro de 2000 |
|
0.9.6m (17 de março de 2004) |
| 0.9.7 | 31 de dezembro de 2002 |
|
0.9.7m (23 de fevereiro de 2007) |
| 0.9.8 | 5 de julho de 2005 |
|
0.9.8zh (3 de dezembro de 2015) |
| 1.0.0 | 29 de março de 2010 |
|
1.0.0t (3 de dezembro de 2015 ) |
| 1.0.1 | 14 de março de 2012 |
|
1.0.1u (22 de setembro de 2016 ) |
| 1.0.2 | 22 de janeiro de 2015 |
|
1.0.2u (20 de dezembro de 2019 ) |
| 1.1.0 | 25 de agosto de 2016 |
|
1.1.0l (10 de setembro de 2019 ) |
| 1.1.1 | 11 de setembro de 2018 |
|
desenvolvimento contínuo |
| 3.0.0 | 7 de setembro de 2021 |
|
desenvolvimento contínuo |
|
Lenda:
Versão antiga
Versão mais antiga, ainda mantida
Última versão
Versão de visualização mais recente
Lançamento futuro
|
|||
Algoritmos
OpenSSL oferece suporte a vários algoritmos criptográficos diferentes:
- Cifras
- AES , Blowfish , Camellia , Chacha20 , Poly1305 , SEED , CAST-128 , DES , IDEA , RC2 , RC4 , RC5 , Triple DES , GOST 28147-89 , SM4
- Funções criptográficas de hash
- MD5 , MD4 , MD2 , SHA-1 , SHA-2 , SHA-3 , RIPEMD-160 , MDC-2 , GOST R 34.11-94 , BLAKE2 , Whirlpool , SM3
- Criptografia de chave pública
- RSA , DSA , troca de chave Diffie – Hellman , curva elíptica , X25519 , Ed25519 , X448 , Ed448 , GOST R 34.10-2001 , SM2
(O sigilo direto perfeito é compatível com a curva elíptica Diffie – Hellman desde a versão 1.0.)
Validação FIPS 140
FIPS 140 é um programa federal dos EUA para teste e certificação de módulos criptográficos. Um dos primeiros certificados FIPS 140-1 para o FOM 1.0 do OpenSSL foi revogado em julho de 2006 "quando foram levantadas questões sobre a interação do módulo validado com software externo". O módulo foi recertificado em fevereiro de 2007 antes de dar lugar ao FIPS 140-2. O OpenSSL 1.0.2 suportava o uso do OpenSSL FIPS Object Module (FOM), que foi construído para fornecer algoritmos aprovados pelo FIPS em um ambiente validado pelo FIPS 140-2. O OpenSSL decidiu, de maneira controversa, categorizar a arquitetura 1.0.2 como 'Fim da Vida' ou 'EOL', a partir de 31 de dezembro de 2019, apesar das objeções de que era a única versão do OpenSSL disponível atualmente com suporte para o modo FIPS. Como resultado do EOL, muitos usuários não conseguiram implantar corretamente o FOM 2.0 e caíram fora da conformidade porque não asseguraram o suporte estendido para a arquitetura 1.0.2, embora o próprio FOM permanecesse validado por mais oito meses.
O FIPS Object Module 2.0 permaneceu como FIPS 140-2 validado em vários formatos até 1 de setembro de 2020, quando o NIST suspendeu o uso do FIPS 186-2 para Digital Signature Standard e designou todos os módulos não compatíveis como 'históricos'. Esta designação inclui uma advertência aos Órgãos Federais de que eles não devem incluir o módulo em quaisquer novas aquisições. Todas as três validações OpenSSL foram incluídas na descontinuação - o OpenSSL FIPS Object Module (certificado nº 1747), OpenSSL FIPS Object Module SE (certificado nº 2398) e OpenSSL FIPS Object Module RE (certificado nº 2473). Muitas validações e clones baseados em OpenSSL 'Private Label' criados por consultores também foram movidos para a Lista Histórica, embora alguns módulos validados por FIPS com compatibilidade de substituição tenham evitado a descontinuação, como BoringCrypto do Google e CryptoComply da SafeLogic.
O OpenSSL 3.0 restaurou o modo FIPS e passou por testes FIPS 140-2, mas com atrasos significativos: o esforço foi iniciado pela primeira vez em 2016 com o suporte da SafeLogic e mais suporte da Oracle em 2017, mas o processo tem sido desafiador. Em 20 de outubro de 2020, o OpenSSL FIPS Provider 3.0 foi adicionado à lista de implementação em teste CMVP, que refletiu um compromisso oficial com um laboratório de teste para prosseguir com uma validação FIPS 140-2. Isso resultou em uma série de certificações nos meses seguintes.
Licenciamento
O OpenSSL foi licenciado duas vezes sob a Licença OpenSSL e a Licença SSLeay, o que significa que os termos de qualquer uma das licenças podem ser usados. A licença OpenSSL é Apache License 1.0 e SSLeay License tem algumas semelhanças com uma licença BSD de 4 cláusulas . Como a licença OpenSSL era Apache License 1.0, mas não Apache License 2.0, ela requer que a frase "este produto inclui software desenvolvido pelo OpenSSL Project para uso no OpenSSL Toolkit" apareça em material publicitário e quaisquer redistribuições (Seções 3 e 6 de a Licença OpenSSL). Devido a esta restrição, a licença OpenSSL e a licença Apache 1.0 são incompatíveis com a GNU GPL . Alguns desenvolvedores GPL adicionaram uma exceção OpenSSL às suas licenças que permite especificamente o uso do OpenSSL com seus sistemas. GNU Wget e climm usam tais exceções. Alguns pacotes (como o Deluge ) modificam explicitamente a licença GPL adicionando uma seção extra no início da licença que documenta a exceção. Outros pacotes usam GnuTLS licenciado por LGPL , Botan licenciado por BSD ou NSS licenciado por MPL , que executam a mesma tarefa.
O OpenSSL anunciou em agosto de 2015 que exigiria que a maioria dos contribuidores assinassem um Contrato de Licença de Contribuidor (CLA) e que o OpenSSL seria eventualmente licenciado novamente de acordo com os termos da Licença Apache 2.0 . Esse processo teve início em março de 2017 e foi concluído em 2018.
Em 7 de setembro de 2021, o OpenSSL 3.0.0 foi lançado sob a licença Apache 2.0.
Vulnerabilidades notáveis
Negação de serviço: análise ASN.1
O OpenSSL 0.9.6k tem um bug em que certas sequências ASN.1 desencadeiam um grande número de recursões em máquinas Windows, descoberto em 4 de novembro de 2003. O Windows não conseguia lidar com grandes recursões corretamente, então o OpenSSL travaria como resultado. Ser capaz de enviar um grande número arbitrário de sequências ASN.1 faria com que o OpenSSL travasse como resultado.
Vulnerabilidade de grampeamento OCSP
Ao criar um handshake, o cliente poderia enviar uma mensagem ClientHello formatada incorretamente, levando à análise OpenSSL mais do que o final da mensagem. Atribuído o identificador CVE - 2011-0014 pelo projeto CVE, isso afetou todas as versões do OpenSSL 0.9.8h a 0.9.8q e OpenSSL 1.0.0 a 1.0.0c. Como a análise pode levar a uma leitura em um endereço de memória incorreto, é possível que o invasor cause um DoS . Também era possível que alguns aplicativos expusessem o conteúdo de extensões OCSP analisadas , fazendo com que um invasor fosse capaz de ler o conteúdo da memória que veio após o ClientHello.
Vulnerabilidade ASN.1 BIO
Ao usar funções básicas de entrada / saída (BIO) ou FILE para ler dados de formato DER não confiáveis , o OpenSSL fica vulnerável. Esta vulnerabilidade foi descoberta em 19 de abril de 2012 e foi atribuída ao identificador CVE CVE - 2012-2110 . Embora não afete diretamente o código SSL / TLS do OpenSSL, qualquer aplicativo que estava usando funções ASN.1 (particularmente d2i_X509 e d2i_PKCS12) também não foi afetado.
Ataque de recuperação de texto simples SSL, TLS e DTLS
Ao lidar com conjuntos de criptografia CBC em SSL, TLS e DTLS, o OpenSSL foi considerado vulnerável a um ataque de temporização durante o processamento MAC. Nadhem Alfardan e Kenny Paterson descobriram o problema e publicaram suas descobertas em 5 de fevereiro de 2013. A vulnerabilidade foi atribuída ao identificador CVE CVE - 2013-0169 .
Chaves privadas previsíveis (específicas do Debian)
O gerador de números pseudoaleatórios do OpenSSL adquire entropia usando métodos de programação complexos. Para evitar que a ferramenta de análise Valgrind emita avisos associados, um mantenedor da distribuição Debian aplicou um patch à variante do pacote OpenSSL do Debian, que inadvertidamente quebrou seu gerador de número aleatório, limitando o número total de chaves privadas que poderia gerar a 32.768. A versão quebrada foi incluída no lançamento do Debian de 17 de setembro de 2006 (versão 0.9.8c-1), também comprometendo outras distribuições baseadas no Debian, por exemplo o Ubuntu . Ready-to-use exploits estão facilmente disponíveis.
O erro foi relatado pelo Debian em 13 de maio de 2008. Na distribuição Debian 4.0 (etch), esses problemas foram corrigidos na versão 0.9.8c-4etch3, enquanto as correções para a distribuição Debian 5.0 (lenny) foram fornecidas na versão 0.9.8g -9.
Heartbleed
As versões 1.0.1 a 1.0.1f do OpenSSL têm um grave bug de manipulação de memória em sua implementação da extensão TLS Heartbeat que pode ser usada para revelar até 64 KB da memória do aplicativo a cada pulsação ( CVE - 2014-0160 ). Ao ler a memória do servidor web, os invasores podem acessar dados confidenciais, incluindo a chave privada do servidor . Isso pode permitir que os invasores decodifiquem comunicações interceptadas anteriormente se o protocolo de criptografia usado não garantir o sigilo de encaminhamento perfeito . O conhecimento da chave privada também pode permitir que um invasor monte um ataque man-in-the-middle contra qualquer comunicação futura. A vulnerabilidade também pode revelar partes não criptografadas de solicitações e respostas confidenciais de outros usuários, incluindo cookies de sessão e senhas, que podem permitir que invasores sequestrem a identidade de outro usuário do serviço.
Na sua divulgação em 7 de abril de 2014, acreditava-se que cerca de 17% ou meio milhão dos servidores da Web seguros da Internet certificados por autoridades confiáveis eram vulneráveis ao ataque. No entanto, o Heartbleed pode afetar o servidor e o cliente.
Vulnerabilidade de injeção CCS
A vulnerabilidade de injeção CCS ( CVE - 2014-0224 ) é uma vulnerabilidade de desvio de segurança que resulta de uma fraqueza nos métodos OpenSSL usados para material de chave.
Esta vulnerabilidade pode ser explorada através do uso de um ataque man-in-the-middle, onde um invasor pode ser capaz de descriptografar e modificar o tráfego em trânsito. Um invasor remoto não autenticado pode explorar esta vulnerabilidade usando um handshake especialmente criado para forçar o uso de material de chave fraca. A exploração bem-sucedida pode levar a uma condição de desvio de segurança em que um invasor pode obter acesso a informações potencialmente confidenciais. O ataque só pode ser executado entre um cliente e servidor vulneráveis .
Os clientes OpenSSL são vulneráveis em todas as versões do OpenSSL antes das versões 0.9.8za, 1.0.0m e 1.0.1h. Os servidores são considerados vulneráveis apenas no OpenSSL 1.0.1 e 1.0.2-beta1. Os usuários de servidores OpenSSL anteriores a 1.0.1 são aconselhados a atualizar como precaução.
ClientHello sigalgs DoS
Esta vulnerabilidade ( CVE - 2015-0291 ) permite que qualquer pessoa pegue um certificado, leia seu conteúdo e o modifique com precisão para abusar da vulnerabilidade, fazendo com que um certificado bloqueie um cliente ou servidor. Se um cliente se conectar a um servidor OpenSSL 1.0.2 e renegociar com uma extensão de algoritmos de assinatura inválida, ocorrerá uma desreferência de ponteiro nulo. Isso pode causar um ataque DoS contra o servidor.
Um pesquisador de segurança de Stanford, David Ramos, teve um exploit privado e o apresentou à equipe do OpenSSL, que então corrigiu o problema.
O OpenSSL classificou o bug como um problema de alta gravidade, observando que a versão 1.0.2 foi considerada vulnerável.
Ataque de recuperação de chave em pequenos subgrupos Diffie – Hellman
Esta vulnerabilidade ( CVE - 2016-0701 ) permite, quando algumas circunstâncias particulares são atendidas, recuperar a chave privada Diffie – Hellman do servidor OpenSSL. Um pesquisador da Adobe System Security, Antonio Sanso, relatou em particular a vulnerabilidade.
O OpenSSL classificou o bug como um problema de alta gravidade, observando que apenas a versão 1.0.2 foi considerada vulnerável.
Forks
SSL aglomerado
Em 2009, após frustrações com a API OpenSSL original, Marco Peereboom, um desenvolvedor do OpenBSD na época, bifurcou a API original criando SSL aglomerado (assl), que reutiliza a API OpenSSL sob o capô, mas fornece uma interface externa muito mais simples. Desde então, ele foi descontinuado devido à bifurcação do LibreSSL por volta de 2016.
LibreSSL
Em abril de 2014, na sequência da heartbleed , membros do OpenBSD projeto bifurcada OpenSSL começando com o ramo 1.0.1g, para criar um projeto chamado LibreSSL . Na primeira semana de remoção da base de código do OpenSSL , mais de 90.000 linhas de código C foram removidas da bifurcação.
BoringSSL
Em junho de 2014, o Google anunciou seu próprio fork do OpenSSL apelidado de BoringSSL. O Google planeja cooperar com os desenvolvedores OpenSSL e LibreSSL. Desde então, o Google desenvolveu uma nova biblioteca, a Tink, baseada no BoringSSL.
Veja também
- Comparação de implementações TLS
- Comparação de bibliotecas de criptografia
- Lista de pacotes de software gratuitos e de código aberto
- Projeto POSSE
- LibreSSL