OpenSSL - OpenSSL
 | |
 | |
| Utvikler (er) | OpenSSL -prosjektet |
|---|---|
| Første utgivelse | 1998 |
| Stabil utgivelse | 3.0.0 (7. september 2021 ) [±] |
| Oppbevaringssted | |
| Skrevet inn | C , Assembly , Perl |
| Type | kryptografi bibliotek |
| Tillatelse | OpenSSL -lisens, v3.0 byttet til Apache License 2.0 |
| Nettsted | www |
OpenSSL er en programvare bibliotek for applikasjoner som sikker kommunikasjon over datanettverk mot avlytting eller behov for å identifisere partiet i den andre enden. Det er mye brukt av Internett -servere , inkludert de fleste HTTPS -nettsteder .
OpenSSL inneholder en åpen kildekode- implementering av SSL- og TLS- protokollene. Kjernen bibliotek skrevet i programmeringsspråket C , implementerer grunnleggende kryptografiske funksjoner og gir ulike nyttefunksjoner. Omslag som tillater bruk av OpenSSL -biblioteket på en rekke dataspråk er tilgjengelig.
OpenSSL Software Foundation (OSF) representerer OpenSSL -prosjektet i de fleste juridiske kapasitetene, inkludert lisensavtaler for bidragsytere, administrasjon av donasjoner og så videre. OpenSSL Software Services (OSS) representerer også OpenSSL -prosjektet for støttekontrakter.
OpenSSL er tilgjengelig for de fleste Unix-lignende operativsystemer (inkludert Linux , macOS og BSD ) og Microsoft Windows .
Prosjektets historie
OpenSSL -prosjektet ble grunnlagt i 1998 for å tilby et gratis sett med krypteringsverktøy for koden som brukes på Internett. Den er basert på en gaffel av SSLeay av Eric Andrew Young og Tim Hudson, som uoffisielt avsluttet utviklingen 17. desember 1998, da Young og Hudson begge gikk på jobb for RSA Security . De første grunnleggerne var Mark Cox, Ralf Engelschall, Stephen Henson, Ben Laurie og Paul Sutton.
Fra mai 2019 besto OpenSSL -administrasjonskomiteen av 7 personer, og det er 17 utviklere med commit -tilgang (hvorav mange også er en del av OpenSSL -administrasjonskomiteen). Det er bare to heltidsansatte (stipendiater), og resten er frivillige.
Prosjektet har et budsjett på mindre enn en million USD per år og er hovedsakelig avhengig av donasjoner. Utviklingen av TLS 1.3 er sponset av Akamai.
Store versjoner utgivelser
| Versjon | Opprinnelig utgivelsesdato | Kommentar | Siste mindre versjon |
|---|---|---|---|
| 0.9.1 | 23. desember 1998 |
|
0.9.1c (23. desember 1998) |
| 0.9.2 | 22. mars 1999 |
|
0.9.2b (6. april 1999) |
| 0.9.3 | 25. mai 1999 |
|
0.9.3a (27. mai 1999) |
| 0.9.4 | 9. august 1999 |
|
0.9.4 (9. august 1999) |
| 0.9.5 | 28. februar 2000 |
|
0.9.5a (1. april 2000) |
| 0.9.6 | 24. september 2000 |
|
0.9.6m (17. mars 2004) |
| 0.9.7 | 31. desember 2002 |
|
0.9.7m (23. februar 2007) |
| 0.9.8 | 5. juli 2005 |
|
0.9.8zh (3. desember 2015) |
| 1.0.0 | 29. mars 2010 |
|
1.0.0t (3. desember 2015 ) |
| 1.0.1 | 14. mars 2012 |
|
1.0.1u (22. september 2016 ) |
| 1.0.2 | 22. januar 2015 |
|
1.0.2u (20. desember 2019 ) |
| 1.1.0 | 25. august 2016 |
|
1.1.0l (10. september 2019 ) |
| 1.1.1 | 11. september 2018 |
|
pågående utvikling |
| 3.0.0 | 7. september 2021 |
|
pågående utvikling |
|
Legende:
Gammel versjon
Eldre versjon, fortsatt vedlikeholdt
Siste versjon
Siste forhåndsversjon
Fremtidig utgivelse
|
|||
Algoritmer
OpenSSL støtter en rekke forskjellige kryptografiske algoritmer:
- Chiffer
- AES , Blowfish , Camellia , Chacha20 , Poly1305 , SEED , CAST-128 , DES , IDEA , RC2 , RC4 , RC5 , Triple DES , GOST 28147-89 , SM4
- Kryptografiske hashfunksjoner
- MD5 , MD4 , MD2 , SHA-1 , SHA-2 , SHA-3 , RIPEMD-160 , MDC-2 , GOST R 34.11-94 , BLAKE2 , Whirlpool , SM3
- Offentlig nøkkel kryptografi
- RSA , DSA , Diffie-Hellman nøkkelutveksling , elliptisk kurve , X25519 , Ed25519 , X448 , Ed448 , GOST R 34,10-2001 , SM2
( Perfekt fremoverhemmelighet støttes ved hjelp av elliptisk kurve Diffie - Hellman siden versjon 1.0.)
FIPS 140 Validering
FIPS 140 er et amerikansk føderalt program for testing og sertifisering av kryptografiske moduler. Et tidlig FIPS 140-1-sertifikat for OpenSSLs FOM 1.0 ble opphevet i juli 2006 "da det ble reist spørsmål om den validerte modulens interaksjon med ekstern programvare." Modulen ble re-sertifisert i februar 2007 før den ga etter for FIPS 140-2. OpenSSL 1.0.2 støttet bruk av OpenSSL FIPS Object Module (FOM), som ble bygget for å levere FIPS godkjente algoritmer i et FIPS 140-2 validert miljø. OpenSSL bestemte seg kontroversielt for å kategorisere 1.0.2 -arkitekturen som 'End of Life' eller 'EOL', med virkning 31. desember 2019, til tross for innvendinger om at det var den eneste versjonen av OpenSSL som for øyeblikket var tilgjengelig med støtte for FIPS -modus. Som et resultat av EOL klarte mange brukere ikke å distribuere FOM 2.0 på riktig måte og falt ut av samsvar fordi de ikke sikret Extended Support for 1.0.2 -arkitekturen, selv om FOM selv forble validert i åtte måneder videre.
FIPS Object Module 2.0 forble FIPS 140-2 validert i flere formater frem til 1. september 2020, da NIST avskrev bruken av FIPS 186-2 for Digital Signature Standard og utpekte alle ikke-kompatible modulene som 'Historisk'. Denne betegnelsen inkluderer en advarsel til føderale byråer om at de ikke skal inkludere modulen i nye anskaffelser. Alle tre OpenSSL -valideringene var inkludert i avskrivningen - OpenSSL FIPS -objektmodulen (sertifikat #1747), OpenSSL FIPS -objektmodul SE (sertifikat #2398) og OpenSSL FIPS -objektmodul RE (sertifikat #2473). Mange 'Private Label' OpenSSL-baserte valideringer og kloner opprettet av konsulenter ble også flyttet til den historiske listen, selv om noen FIPS-validerte moduler med erstatningskompatibilitet unngikk avskrivningen, for eksempel BoringCrypto fra Google og CryptoComply fra SafeLogic.
OpenSSL 3.0 gjenopprettet FIPS-modus og gjennomgikk FIPS 140-2-testing, men med betydelige forsinkelser: Innsatsen ble først startet i 2016 med støtte fra SafeLogic og ytterligere støtte fra Oracle i 2017, men prosessen har vært utfordrende. 20. oktober 2020 ble OpenSSL FIPS Provider 3.0 lagt til CMVP-implementering under testliste, noe som gjenspeilte et offisielt engasjement med et testlaboratorium for å fortsette med en FIPS 140-2-validering. Dette resulterte i en rekke sertifiseringer i de påfølgende månedene.
Lisensiering
OpenSSL var dobbeltlisensiert under OpenSSL-lisensen og SSLeay-lisensen, noe som betyr at vilkårene for begge lisensene kan brukes. OpenSSL-lisensen er Apache License 1.0 og SSLeay License har en viss likhet med en 4-klausul BSD-lisens . Siden OpenSSL -lisensen var Apache License 1.0, men ikke Apache License 2.0, krever uttrykket "dette produktet inkluderer programvare utviklet av OpenSSL Project for bruk i OpenSSL Toolkit" for å vises i reklamemateriale og eventuelle omfordelinger (seksjoner 3 og 6 i OpenSSL -lisensen). På grunn av denne begrensningen er OpenSSL -lisensen og Apache -lisensen 1.0 inkompatible med GNU GPL . Noen GPL -utviklere har lagt til et OpenSSL -unntak i lisensene som spesifikt tillater bruk av OpenSSL med systemet sitt. GNU Wget og climm bruker begge slike unntak. Noen pakker (som Deluge ) endrer eksplisitt GPL -lisensen ved å legge til en ekstra seksjon i begynnelsen av lisensen som dokumenterer unntaket. Andre pakker bruker LGPL -lisensiert GnuTLS , BSD -lisensiert botan eller MPL -lisensiert NSS , som utfører den samme oppgaven.
OpenSSL kunngjorde i august 2015 at det ville kreve at de fleste bidragsyterne signerte en Contributor License Agreement (CLA), og at OpenSSL til slutt ville bli lisensiert under vilkårene i Apache License 2.0 . Denne prosessen startet i mars 2017 og ble fullført i 2018.
September 2021 ble OpenSSL 3.0.0 utgitt under Apache License 2.0.
Bemerkelsesverdige sårbarheter
Tjenestenekt: ASN.1 -analyse
OpenSSL 0.9.6k har en feil der visse ASN.1 -sekvenser utløste et stort antall rekursjoner på Windows -maskiner, oppdaget 4. november 2003. Windows kunne ikke håndtere store rekursjoner riktig, så OpenSSL ville krasje som et resultat. Å kunne sende vilkårlig stort antall ASN.1 -sekvenser vil føre til at OpenSSL krasjer som et resultat.
Sårbarhet for stifting av OCSP
Når du oppretter et håndtrykk, kan klienten sende en feilformatert ClientHello -melding, noe som fører til at OpenSSL kan analysere mer enn slutten av meldingen. Tilordnet identifikatoren CVE - 2011-0014 av CVE -prosjektet, dette påvirket alle OpenSSL -versjoner 0.9.8h til 0.9.8q og OpenSSL 1.0.0 til 1.0.0c. Siden analysen kan føre til avlesning på feil minneadresse, var det mulig for angriperen å forårsake en DoS . Det var også mulig at noen programmer avslørte innholdet i analyserte OCSP -utvidelser, noe som førte til at en angriper kunne lese innholdet i minnet som kom etter ClientHello.
ASN.1 BIO -sårbarhet
Når du bruker Basic Input/Output (BIO) eller FILE -baserte funksjoner for å lese data som ikke er klarert i DER -format, er OpenSSL sårbart. Dette sikkerhetsproblemet ble oppdaget 19. april 2012 og ble tildelt CVE -identifikatoren CVE - 2012-2110 . Selv om det ikke direkte påvirker SSL/TLS -koden til OpenSSL, ble ikke alle applikasjoner som brukte ASN.1 -funksjoner (spesielt d2i_X509 og d2i_PKCS12) også påvirket.
SSL, TLS og DTLS klartekstgjenopprettingsangrep
Ved håndtering av CBC-chiffer-suiter i SSL, TLS og DTLS ble OpenSSL funnet sårbar for et tidsangrep under MAC-behandlingen. Nadhem Alfardan og Kenny Paterson oppdaget problemet, og publiserte funnene sine 5. februar 2013. Sårbarheten ble tildelt CVE -identifikatoren CVE - 2013-0169 .
Forutsigbare private nøkler (Debian-spesifikke)
OpenSSLs pseudo-tilfeldige tallgenerator skaffer seg entropi ved hjelp av komplekse programmeringsmetoder. For å hindre Valgrind -analyseverktøyet i å utstede tilhørende advarsler, brukte en vedlikeholder av Debian -distribusjonen en oppdatering på Debians variant av OpenSSL -pakken, som utilsiktet brøt tilfeldig tallgenerator ved å begrense det totale antallet private nøkler den kunne generere til 32 768. Den ødelagte versjonen ble inkludert i Debian-utgivelsen 17. september 2006 (versjon 0.9.8c-1), og kompromitterte også andre Debian-baserte distribusjoner, for eksempel Ubuntu . Klar til bruk exploits er lett tilgjengelig.
Feilen ble rapportert av Debian 13. mai 2008. På Debian 4.0-distribusjonen (etch) ble disse problemene løst i versjon 0.9.8c-4etch3, mens reparasjoner for Debian 5.0-distribusjonen (lenny) ble levert i versjon 0.9.8g -9.
Heartbleed
OpenSSL-versjoner 1.0.1 gjennom 1.0.1f har en alvorlig minne håndtering feil i gjennomføringen av TLS Heartbeat Extension som kan brukes til å avsløre opp til 64 KB av programmet minne med hver hjerterytme ( CVE - 2014-0160 ). Ved å lese minnet til webserveren kunne angriperne få tilgang til sensitive data, inkludert serverens private nøkkel . Dette kan gjøre det mulig for angriperne å dekode tidligere avlyttet kommunikasjon hvis krypteringsprotokollen som brukes ikke sikrer perfekt hemmelighold . Kunnskap om den private nøkkelen kan også tillate en angriper å montere et mann-i-midten-angrep mot fremtidig kommunikasjon. Sårbarheten kan også avsløre ukrypterte deler av andre brukeres sensitive forespørsler og svar, inkludert økt -informasjonskapsler og passord, som kan tillate angripere å kapre identiteten til en annen bruker av tjenesten.
Da det ble offentliggjort 7. april 2014, ble det antatt at rundt 17% eller en halv million av internettets sikre webservere sertifisert av pålitelige myndigheter hadde vært sårbare for angrepet. Heartbleed kan imidlertid påvirke både serveren og klienten.
Sårbarhet for CCS -injeksjon
Sårbarheten i CCS -injeksjonen ( CVE - 2014-0224 ) er et sikkerhetsomgåelsesproblem som skyldes en svakhet i OpenSSL -metoder som brukes for å taste inn materiale.
Denne sårbarheten kan utnyttes ved bruk av et mann-i-midten-angrep, der en angriper kan være i stand til å dekryptere og endre trafikk under transport. En ekstern ikke -godkjent angriper kan utnytte dette sikkerhetsproblemet ved å bruke et spesiallaget håndtrykk for å tvinge til bruk av svakt tastemateriale. Vellykket utnyttelse kan føre til en sikkerhetsomgåelse der en angriper kan få tilgang til potensielt sensitiv informasjon. Angrepet kan bare utføres mellom en sårbar klient og server.
OpenSSL -klienter er sårbare i alle versjoner av OpenSSL før versjonene 0.9.8za, 1.0.0m og 1.0.1h. Servere er bare kjent for å være sårbare i OpenSSL 1.0.1 og 1.0.2-beta1. Brukere av OpenSSL -servere tidligere enn 1.0.1 anbefales å oppgradere som en forholdsregel.
ClientHello sigalgs DoS
Dette sikkerhetsproblemet ( CVE - 2015-0291 ) lar alle ta et sertifikat, lese innholdet i det og endre det nøyaktig for å misbruke sårbarheten som forårsaker at et sertifikat krasjer en klient eller server. Hvis en klient kobler seg til en OpenSSL 1.0.2-server og reforhandler med en ugyldig signaturalgoritmeutvidelse, oppstår det en null-peker dereference. Dette kan forårsake et DoS -angrep mot serveren.
En Stanford Security -forsker, David Ramos, hadde en privat utnyttelse og presenterte den for OpenSSL -teamet, som deretter lappet problemet.
OpenSSL klassifiserte feilen som et problem med høy alvorlighetsgrad, og la merke til at versjon 1.0.2 ble funnet sårbar.
Viktige gjenopprettingsangrep på Diffie - Hellman små undergrupper
Dette sikkerhetsproblemet ( CVE - 2016-0701 ) lar, når noen spesielle omstendigheter er oppfylt, gjenopprette OpenSSL -serverens private Diffie - Hellman -nøkkel. En forsker fra Adobe System Security, Antonio Sanso, rapporterte privat om sårbarheten.
OpenSSL klassifiserte feilen som et problem med høy alvorlighetsgrad, og bemerket at bare versjon 1.0.2 ble funnet sårbar.
Gafler
Agglomerert SSL
I 2009, etter frustrasjoner med det opprinnelige OpenSSL API, forkledde Marco Peereboom, en OpenBSD -utvikler på den tiden, det opprinnelige API ved å lage Agglomerated SSL (assl), som gjenbruker OpenSSL API under panseret, men gir et mye enklere eksternt grensesnitt. Den har siden blitt avskrevet i lys av LibreSSL -gaffelen rundt 2016.
LibreSSL
I april 2014 i kjølvannet av Heartbleed , medlemmer av OpenBSD -prosjektet delte OpenSSL starter med 1.0.1g gren, for å skape et prosjekt som heter LibreSSL . I den første uken med beskjæring av OpenSSLs kodebase , hadde mer enn 90 000 linjer med C -kode blitt fjernet fra gaffelen.
BoringSSL
I juni 2014 kunngjorde Google sin egen gaffel med OpenSSL kalt BoringSSL. Google planlegger å samarbeide med OpenSSL- og LibreSSL-utviklere. Google har siden utviklet et nytt bibliotek, Tink, basert på BoringSSL.
Se også
- Sammenligning av TLS -implementeringer
- Sammenligning av kryptografibiblioteker
- Liste over gratis og åpen kildekode-programvarepakker
- POSSE -prosjekt
- LibreSSL
