Po trzech latach rozwoju i 19 wydaniach testowych wydano bibliotekę OpenSSL 3.0.0 z implementacją protokołów SSL/TLS i różnych algorytmów szyfrowania. Nowa gałąź zawiera zmiany, które psują kompatybilność wsteczną na poziomie API i ABI, ale zmiany nie wpłyną na działanie większości aplikacji, które wymagają przebudowy w celu migracji z OpenSSL 1.1.1. Poprzednia gałąź OpenSSL 1.1.1 będzie wspierana do września 2023 roku.
Istotna zmiana numeru wersji wynika z przejścia na tradycyjną numerację „Major.Minor.Patch”. Od teraz pierwsza cyfra (Major) w numerze wersji zmieni się tylko w przypadku naruszenia kompatybilności na poziomie API/ABI, a druga (Minor) ulegnie zmianie w przypadku zwiększenia funkcjonalności bez zmiany API/ABI. Aktualizacje korygujące będą dostarczane ze zmianą trzeciej cyfry (poprawka). Wybrano numer 3.0.0 bezpośrednio po 1.1.1, aby uniknąć nakładania się na aktualnie opracowywany moduł FIPS dla OpenSSL, dla którego zastosowano numerację 2.x.
Drugą ważną zmianą dla projektu było przejście z licencji podwójnej (OpenSSL i SSLeay) na licencję Apache 2.0. Poprzednia licencja zastrzeżona OpenSSL opierała się na tekście dotychczasowej licencji Apache 1.0 i wymagała wyraźnej wzmianki o OpenSSL w materiałach marketingowych podczas korzystania z bibliotek OpenSSL, a także specjalnej informacji, jeśli OpenSSL był dostarczany w ramach produktu. Te wymagania spowodowały, że stara licencja była niekompatybilna z GPL, co utrudniało używanie OpenSSL w projektach objętych licencją GPL. Aby obejść tę niezgodność, projekty GPL zmuszone były korzystać ze specjalnych umów licencyjnych, w których główny tekst GPL został uzupełniony klauzulą wyraźnie zezwalającą na powiązanie aplikacji z biblioteką OpenSSL i wspominającą, że wymagania GPL nie spełniają dotyczą łączenia z OpenSSL.
W porównaniu do gałęzi OpenSSL 1.1.1, OpenSSL 3.0.0 dodało ponad 7500 zmian naniesionych przez 350 programistów. Główne innowacje OpenSSL 3.0.0:
- Zaproponowano nowy moduł FIPS obejmujący implementację algorytmów kryptograficznych zgodnych ze standardem bezpieczeństwa FIPS 140-2 (rozpoczęcie procesu certyfikacji modułu zaplanowano na ten miesiąc, a certyfikacja FIPS 140-2 spodziewana jest w przyszłym roku). Nowy moduł jest znacznie łatwiejszy w obsłudze, a podłączenie go do wielu aplikacji nie będzie trudniejsze niż zmiana pliku konfiguracyjnego. Domyślnie moduł FIPS jest wyłączony i wymaga włączenia opcji Enable-Fips.
- libcrypto implementuje koncepcję dostawców wtykowych, która zastąpiła koncepcję silników (interfejs API ENGINE stał się przestarzały). Z pomocą dostawców możesz dodawać własne implementacje algorytmów do takich operacji jak szyfrowanie, deszyfrowanie, generowanie klucza, obliczanie MAC, tworzenie i weryfikacja podpisów cyfrowych. Możliwe jest zarówno podłączanie nowych, jak i tworzenie alternatywnych implementacji już obsługiwanych algorytmów (domyślnie dla każdego algorytmu używany jest teraz dostawca wbudowany w OpenSSL).
- Dodano obsługę protokołu zarządzania certyfikatami (RFC 4210), którego można używać do żądania certyfikatów od serwera urzędu certyfikacji, aktualizowania certyfikatów i unieważniania certyfikatów. Praca z CMP odbywa się za pomocą nowego narzędzia openssl-cmp, które obsługuje również format CRMF (RFC 4211) i wysyłanie żądań poprzez HTTP/HTTPS (RFC 6712).
- Zaimplementowano pełnoprawnego klienta protokołów HTTP i HTTPS, obsługującego metody GET i POST, przekierowywanie żądań, pracę poprzez proxy, kodowanie ASN.1 i przetwarzanie timeoutów.
- Dodano nowy EVP_MAC (API kodu uwierzytelniania wiadomości), aby ułatwić dodawanie nowych implementacji fałszywych wstawek.
- Zaproponowano nowy interfejs oprogramowania do generowania kluczy - EVP_KDF (Key Derivation Function API), który upraszcza dodawanie nowych implementacji KDF i PRF. Stare API EVP_PKEY, za pośrednictwem którego dostępne były algorytmy scrypt, TLS1 PRF i HKDF, zostało przeprojektowane w postaci warstwy zaimplementowanej na API EVP_KDF i EVP_MAC.
- Implementacja protokołu TLS zapewnia możliwość wykorzystania klienta i serwera TLS wbudowanego w jądro Linuksa w celu przyspieszenia operacji. Aby włączyć implementację TLS zapewnianą przez jądro Linuksa, musisz włączyć opcję „SSL_OP_ENABLE_KTLS” lub ustawienie „enable-ktls”.
- Dodano obsługę nowych algorytmów:
- Algorytmy generowania kluczy (KDF) to „SINGLE STEP” i „SSH”.
- Symulowane algorytmy wstawiania (MAC) to „GMAC” i „KMAC”.
- Algorytm enkapsulacji klucza RSA (KEM) „RSASVE”.
- Algorytm szyfrowania „AES-SIV” (RFC-8452).
- Dodano wywołania do API EVP z obsługą szyfrów odwrotnych wykorzystujących algorytm AES do szyfrowania kluczy (Key Wrap): „AES-128-WRAP-INV”, „AES-192-WRAP-INV”, „AES-256-WRAP- INV”, „AES-128-WRAP-PAD-INV”, „AES-192-WRAP-PAD-INV” i „AES-256-WRAP-PAD-INV”.
- Dodano obsługę algorytmów pożyczania tekstu szyfrowanego (CTS) do interfejsu API EVP: „AES-128-CBC-CTS”, „AES-192-CBC-CTS”, „AES-256-CBC-CTS”, „CAMELLIA-128-CBC -CTS”, „CAMELLIA-192-CBC-CTS” i „CAMELLIA-256-CBC-CTS”.
- Dodano obsługę podpisów cyfrowych CADES-BES (RFC 5126).
- AES_GCM implementuje parametr AuthEnvelopedData (RFC 5083), aby umożliwić szyfrowanie i deszyfrowanie wiadomości uwierzytelnianych i szyfrowanych przy użyciu trybu AES GCM.
- Do publicznego API dodano funkcje PKCS7_get_octet_string i PKCS7_type_is_other.
- API PKCS#12 zastępuje domyślne algorytmy używane w funkcji PKCS12_create() algorytmami PBKDF2 i AES oraz wykorzystuje algorytm SHA-256 do obliczenia MAC. Aby przywrócić wcześniejsze zachowanie, dostępna jest opcja „-legacy”. Dodano dużą liczbę nowych rozszerzonych wywołań do PKCS12_*_ex, PKCS5_*_ex i PKCS8_*_ex, takich jak PKCS12_add_key_ex().PKCS12_create_ex() i PKCS12_decrypt_skey_ex().
- Dla platformy Windows dodana została obsługa synchronizacji wątków z wykorzystaniem mechanizmu SRWLock.
- Dodano nowy interfejs API śledzenia, włączany za pomocą parametru Enable-Trace.
- Rozszerzono zakres kluczy obsługiwanych w funkcjach EVP_PKEY_public_check() i EVP_PKEY_param_check(): RSA, DSA, ED25519, X25519, ED448 i X448.
- Podsystem RAND_DRBG został usunięty i zastąpiony API EVP_RAND. Funkcje FIPS_mode() i FIPS_mode_set() zostały usunięte.
- Znaczna część interfejsu API stała się przestarzała - użycie przestarzałych wywołań w kodzie projektu spowoduje wyświetlenie ostrzeżeń podczas kompilacji. W tym interfejsy API niskiego poziomu powiązane z niektórymi implementacjami algorytmów (na przykład AES_set_encrypt_key i AES_encrypt) zostały oficjalnie uznane za przestarzałe. Oficjalna obsługa w OpenSSL 3.0.0 jest teraz dostępna tylko dla interfejsów API EVP wysokiego poziomu, które są wyodrębnione z poszczególnych typów algorytmów (ten interfejs API obejmuje na przykład funkcje EVP_EncryptInit_ex, EVP_EncryptUpdate i EVP_EncryptFinal). Przestarzałe interfejsy API zostaną usunięte w jednej z kolejnych głównych wersji. Implementacje starszych algorytmów, takich jak MD2 i DES, dostępnych poprzez EVP API, zostały przeniesione do osobnego modułu „starszego”, który jest domyślnie wyłączony.
- Dokumentacja i zestaw testów zostały znacznie rozszerzone. W porównaniu z wersją 1.1.1 objętość dokumentacji wzrosła o 94%, a rozmiar kodu zestawu testów o 54%.
Źródło: opennet.ru