Sau ba năm phát triển và 19 bản phát hành thử nghiệm, thư viện OpenSSL 3.0.0 đã được phát hành cùng với việc triển khai các giao thức SSL/TLS và các thuật toán mã hóa khác nhau. Nhánh mới bao gồm các thay đổi phá vỡ khả năng tương thích ngược ở cấp độ API và ABI, nhưng những thay đổi này sẽ không ảnh hưởng đến hoạt động của hầu hết các ứng dụng yêu cầu xây dựng lại để di chuyển từ OpenSSL 1.1.1. Nhánh OpenSSL 1.1.1 trước đó sẽ được hỗ trợ cho đến tháng 2023 năm XNUMX.
Một sự thay đổi đáng kể về số phiên bản là do sự chuyển đổi sang cách đánh số “Major.Minor.Patch” truyền thống. Từ giờ trở đi, chữ số đầu tiên (Chính) trong số phiên bản sẽ chỉ thay đổi nếu khả năng tương thích bị phá vỡ ở cấp API/ABI và chữ số thứ hai (Nhỏ) sẽ thay đổi khi chức năng được tăng lên mà không thay đổi API/ABI. Các bản cập nhật khắc phục sẽ được gửi kèm theo thay đổi ở chữ số thứ ba (Bản vá). Số 3.0.0 ngay sau 1.1.1 đã được chọn để tránh trùng lặp với mô-đun FIPS hiện đang được phát triển cho OpenSSL, trong đó cách đánh số 2.x đã được sử dụng.
Thay đổi quan trọng thứ hai đối với dự án là việc chuyển đổi từ giấy phép kép (OpenSSL và SSLeay) sang giấy phép Apache 2.0. Giấy phép OpenSSL độc quyền trước đây dựa trên nội dung của giấy phép Apache 1.0 cũ và yêu cầu đề cập rõ ràng về OpenSSL trong các tài liệu tiếp thị khi sử dụng thư viện OpenSSL, cũng như thông báo đặc biệt nếu OpenSSL được cung cấp như một phần của sản phẩm. Những yêu cầu này khiến giấy phép cũ không tương thích với GPL, gây khó khăn cho việc sử dụng OpenSSL trong các dự án được cấp phép GPL. Để giải quyết vấn đề không tương thích này, các dự án GPL buộc phải sử dụng các thỏa thuận cấp phép cụ thể trong đó văn bản chính của GPL được bổ sung một điều khoản cho phép rõ ràng ứng dụng được liên kết với thư viện OpenSSL và đề cập rằng các yêu cầu của GPL không áp dụng để liên kết với OpenSSL.
So với nhánh OpenSSL 1.1.1, OpenSSL 3.0.0 đã bổ sung hơn 7500 thay đổi do 350 nhà phát triển đóng góp. Những cải tiến chính của OpenSSL 3.0.0:
- Một mô-đun FIPS mới đã được đề xuất, bao gồm việc triển khai các thuật toán mã hóa tuân thủ tiêu chuẩn bảo mật FIPS 140-2 (quy trình chứng nhận cho mô-đun này dự kiến sẽ bắt đầu trong tháng này và chứng nhận FIPS 140-2 dự kiến vào năm tới). Mô-đun mới dễ sử dụng hơn nhiều và việc kết nối nó với nhiều ứng dụng sẽ không khó hơn việc thay đổi tệp cấu hình. Theo mặc định, mô-đun FIPS bị tắt và yêu cầu bật tùy chọn Enable-fips.
- libcrypto triển khai khái niệm nhà cung cấp có thể cắm, thay thế khái niệm công cụ (API ĐỘNG CƠ đã không còn được dùng nữa). Với sự trợ giúp của các nhà cung cấp, bạn có thể thêm các triển khai thuật toán của riêng mình cho các hoạt động như mã hóa, giải mã, tạo khóa, tính toán MAC, tạo và xác minh chữ ký số. Có thể vừa kết nối các thuật toán mới vừa tạo các triển khai thay thế cho các thuật toán đã được hỗ trợ (theo mặc định, nhà cung cấp được tích hợp trong OpenSSL hiện được sử dụng cho mỗi thuật toán).
- Đã thêm hỗ trợ cho Giao thức quản lý chứng chỉ (RFC 4210), có thể được sử dụng để yêu cầu chứng chỉ từ máy chủ CA, cập nhật chứng chỉ và thu hồi chứng chỉ. Làm việc với CMP được thực hiện bằng tiện ích openssl-cmp mới, tiện ích này cũng hỗ trợ định dạng CRMF (RFC 4211) và gửi yêu cầu qua HTTP/HTTPS (RFC 6712).
- Một ứng dụng khách chính thức cho giao thức HTTP và HTTPS đã được triển khai, hỗ trợ các phương thức GET và POST, chuyển hướng yêu cầu, hoạt động thông qua proxy, mã hóa ASN.1 và xử lý thời gian chờ.
- Một EVP_MAC (API mã xác thực tin nhắn) mới đã được thêm vào để giúp việc thêm các triển khai mới của các phần chèn mô phỏng trở nên dễ dàng hơn.
- Một giao diện phần mềm mới để tạo khóa được đề xuất - EVP_KDF (API chức năng dẫn xuất khóa), giúp đơn giản hóa việc bổ sung các triển khai mới của KDF và PRF. API EVP_PKEY cũ, qua đó có sẵn thuật toán mã hóa, TLS1 PRF và HKDF, đã được thiết kế lại dưới dạng một lớp được triển khai trên API EVP_KDF và EVP_MAC.
- Việc triển khai giao thức TLS cung cấp khả năng sử dụng máy khách và máy chủ TLS được tích hợp trong nhân Linux để tăng tốc hoạt động. Để kích hoạt triển khai TLS do nhân Linux cung cấp, bạn phải bật tùy chọn "SSL_OP_ENABLE_KTLS" hoặc cài đặt "enable-ktls".
- Đã thêm hỗ trợ cho các thuật toán mới:
- Các thuật toán tạo khóa (KDF) là “SINGLE STEP” và “SSH”.
- Các thuật toán chèn mô phỏng (MAC) là “GMAC” và “KMAC”.
- Thuật toán đóng gói khóa RSA (KEM) "RSASVE".
- Thuật toán mã hóa "AES-SIV" (RFC-8452).
- Đã thêm lệnh gọi vào API EVP với sự hỗ trợ cho mật mã nghịch đảo bằng thuật toán AES để mã hóa khóa (Quấn khóa): “AES-128-WRAP-INV”, “AES-192-WRAP-INV”, “AES-256-WRAP- INV”, “AES-128-WRAP-PAD-INV”, “AES-192-WRAP-PAD-INV” và “AES-256-WRAP-PAD-INV”.
- Đã thêm hỗ trợ cho thuật toán mượn văn bản mã hóa (CTS) vào API EVP: “AES-128-CBC-CTS”, “AES-192-CBC-CTS”, “AES-256-CBC-CTS”, “CAMELLIA-128-CBC -CTS” ", "CAMELLIA-192-CBC-CTS" và "CAMELLIA-256-CBC-CTS".
- Đã thêm hỗ trợ cho chữ ký số CADES-BES (RFC 5126).
- AES_GCM triển khai tham số AuthEnvelopedData (RFC 5083) để cho phép mã hóa và giải mã các tin nhắn được xác thực và mã hóa bằng chế độ AES GCM.
- Các hàm PKCS7_get_octet_string và PKCS7_type_is_other đã được thêm vào API công khai.
- API PKCS#12 thay thế các thuật toán mặc định được sử dụng trong hàm PKCS12_create() bằng PBKDF2 và AES, đồng thời sử dụng thuật toán SHA-256 để tính toán MAC. Để khôi phục hành vi trong quá khứ, tùy chọn "-legacy" được cung cấp. Đã thêm một số lượng lớn cuộc gọi mở rộng mới vào PKCS12_*_ex, PKCS5_*_ex và PKCS8_*_ex, chẳng hạn như PKCS12_add_key_ex().PKCS12_create_ex() và PKCS12_decrypt_skey_ex().
- Đối với nền tảng Windows, hỗ trợ đồng bộ hóa luồng bằng cơ chế SRWLock đã được thêm vào.
- Đã thêm API theo dõi mới, được bật thông qua tham số bật-trace.
- Phạm vi khóa được hỗ trợ trong các hàm EVP_PKEY_public_check() và EVP_PKEY_param_check() đã được mở rộng: RSA, DSA, ED25519, X25519, ED448 và X448.
- Hệ thống con RAND_DRBG đã bị xóa và được thay thế bằng API EVP_RAND. Các hàm FIPS_mode() và FIPS_mode_set() đã bị xóa.
- Một phần quan trọng của API đã trở nên lỗi thời - việc sử dụng các lệnh gọi lỗi thời trong mã dự án sẽ dẫn đến cảnh báo trong quá trình biên dịch. Bao gồm các API cấp thấp gắn liền với việc triển khai một số thuật toán nhất định (ví dụ: AES_set_encrypt_key và AES_encrypt) đã chính thức bị tuyên bố lỗi thời. Hỗ trợ chính thức trong OpenSSL 3.0.0 hiện chỉ được cung cấp cho các API EVP cấp cao được trừu tượng hóa từ các loại thuật toán riêng lẻ (ví dụ: API này bao gồm các hàm EVP_EncryptInit_ex, EVP_EncryptUpdate và EVP_EncryptFinal). Các API không được dùng nữa sẽ bị xóa trong một trong các bản phát hành chính tiếp theo. Việc triển khai các thuật toán cũ như MD2 và DES, có sẵn thông qua API EVP, đã được chuyển sang một mô-đun "cũ" riêng biệt, mô-đun này bị tắt theo mặc định.
- Các tài liệu và bộ thử nghiệm đã được mở rộng đáng kể. So với nhánh 1.1.1, khối lượng tài liệu đã tăng 94% và kích thước của mã bộ thử nghiệm đã tăng 54%.
Nguồn: opennet.ru