TLS المقاوم للكم على Ubuntu 22.04 و24.04 مع OpenSSL 3.0
آخر تحديث:
يأتي Ubuntu 22.04 و24.04 مع OpenSSL 3.0. دعم ML-KEM وصل في OpenSSL 3.5، لذلك لا يستطيع nginx أو Apache المبنيّ على مكتبة النظام التفاوض على X25519MLKEM768 مهما كتبت في الإعدادات. هذا سبب ظهور خوادم كثيرة «تقليدية» في الفحص رغم أن Chrome وFirefox يعرضان التبادل الهجين في كل اتصال. أمامك ثلاثة طرق؛ اختر أول طريق يناسبك.
openssl version # OpenSSL 3.0.x on Ubuntu 22.04 / 24.04 nginx -V 2>&1 | grep -o 'OpenSSL [0-9.]*' # the library nginx was built with
الطريق 1 (الأسهل): Caddy أو CDN أمام الخادم
Caddy مكتوب بلغة Go، ومكتبة TLS فيها تدعم X25519MLKEM768 افتراضياً بمعزل عن OpenSSL النظام. اجعل Caddy يستقبل TLS على المنفذ 443 ويمرّر الطلبات إلى خادمك الحالي على العنوان المحلي. هذا الموقع نفسه يعمل بهذه الطريقة ودرجته A.
# /etc/caddy/Caddyfile
example.com {
reverse_proxy 127.0.0.1:8080 # nginx/Apache now listen on 8080 without TLS
}
يحصل Caddy على الشهادة ويجددها بنفسه. غيّر في nginx السطر listen 443 ssl إلى listen 127.0.0.1:8080، وأعد تحميل الاثنين، ثم افحص من جديد. شبكة CDN تدعم الهجين (مثل وكيل Cloudflare) تعطي الأثر نفسه للزوار؛ أما الاتصال من CDN إلى خادمك الأصلي فمرحلة منفصلة.
الطريق 2 (nginx للإنتاج): OpenSSL 3.5
إما أن تنتقل إلى إصدار يأتي مع OpenSSL 3.5 (مثل Debian 13 «trixie»؛ وتحقق بـ openssl version في إصدارات Ubuntu الأحدث)، أو تبني nginx على شجرة مصدر OpenSSL 3.5. يربطها nginx ربطاً ثابتاً فتبقى مكتبة النظام كما هي:
sudo apt install -y build-essential libpcre2-dev zlib1g-dev # download and verify the nginx and OpenSSL 3.5.x source tarballs from nginx.org and openssl-library.org cd nginx-1.x.y ./configure --with-openssl=../openssl-3.5.x --with-http_ssl_module --with-http_v2_module --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx # match your current nginx -V flags make -j"$(nproc)" && sudo make install
انسخ بقية خيارات configure من ناتج nginx -V الحالي حتى تبقى الوحدات والمسارات كما هي. ثم اتبع دليل nginx لسطر ssl_ecdh_curve. انتبه: nginx المبني يدوياً لا يصله تحديث Ubuntu الأمني، فعليك إعادة بنائه مع كل إصلاح لـ nginx أو OpenSSL.
الطريق 3 (للتجربة فقط): oqs-provider على OpenSSL 3.0
مشروع Open Quantum Safe يقدّم oqs-provider الذي يضيف ML-KEM إلى OpenSSL 3.0 كمزوّد قابل للتحميل، مبنياً على liboqs. المشروع نفسه يقول إنه للنماذج الأولية والتقييم، لا للإنتاج. استخدمه على خادم تجربة لتختبر التبادل الهجين قبل الترقية.
sudo apt install -y build-essential cmake ninja-build libssl-dev git git clone https://github.com/open-quantum-safe/liboqs.git cmake -S liboqs -B liboqs/build -GNinja -DBUILD_SHARED_LIBS=ON sudo cmake --build liboqs/build --target install && sudo ldconfig git clone https://github.com/open-quantum-safe/oqs-provider.git cmake -S oqs-provider -B oqs-provider/build -GNinja sudo cmake --build oqs-provider/build --target install openssl version -m # MODULESDIR: where oqsprovider.so was installed
لا تعدّل الملف العام /etc/ssl/openssl.cnf: يقرؤه apt وcurl وPython وكل برنامج آخر. أعطِ nginx ملفاً خاصاً به:
# /etc/nginx/openssl-oqs.cnf openssl_conf = openssl_init [openssl_init] providers = provider_sect [provider_sect] default = default_sect oqsprovider = oqs_sect [default_sect] activate = 1 [oqs_sect] activate = 1
sudo systemctl edit nginx # add: [Service] Environment=OPENSSL_CONF=/etc/nginx/openssl-oqs.cnf
تحقق من الاسم الدقيق للمجموعة في نسختك بالأمر OPENSSL_CONF=/etc/nginx/openssl-oqs.cnf openssl list -kem-algorithms، وضعه أولاً في ssl_ecdh_curve (مثلاً X25519MLKEM768:X25519:prime256v1)، ثم nginx -t && systemctl restart nginx. هذه الخطوات تتبع توثيق OQS، ولم نشغّلها على خوادمنا، فراجع ملف README للمشروع لمتطلبات النسخة التي تبنيها.
التحقق
شغّل الفحص المجاني: الدرجة A تعني TLS 1.3 مع تبادل مفاتيح هجين مقاوم للكم. الفحص يجيب أيضاً على طلب HelloRetryRequest كما تفعل المتصفحات، فتُقاس الخوادم التي تطلب مجموعة أخرى كذلك. وللفحص المستمر، GitHub Action يُفشل البناء إذا اختفى التبادل الهجين.
المصادر: ملاحظات إصدار OpenSSL 3.5 (ML-KEM)، وخيار البناء --with-openssl في nginx، وملفات README لمشروعي liboqs وoqs-provider من Open Quantum Safe، والمجموعات الافتراضية في crypto/tls بلغة Go.