SSL/TLS: كيف يُشفّر الويب ويُثبت هوية المواقع

في المقال السابق عن «HTTP وHTTPS» قلتُ إن الحرف «S» في HTTPS هو طبقة تشفير اسمها TLS، تُعمّي المحادثة وتثبت هوية الخادم. هنا أفتح هذه الطبقة: كيف تتحوّل محادثة مكشوفة على شبكة عامّة إلى اتصال لا يقرؤه أحد سواك والخادم، وكيف تتأكّد أن من تكلّمه هو الموقع الحقيقيّ لا منتحِل يشبهه.

القفل في شريط العنوان يلخّص هذا كلّه في أيقونة، لكنّ خلفه نظاما أنيقا من التشفير والشهادات وهيئات الثقة. سأفكّكه قطعة قطعة: ما يحقّقه TLS، وما الشهادة وكيف تُبنى الثقة بها، وكيف تجري المصافحة فعلًا، ثمّ ماذا تعني رسائل الخطأ التي تراها حين يختلّ شيء.

ما SSL/TLS؟ ولماذا الاسمان؟

تخيّل الإنترنت سوقا مكتظّا، كل ما ترسله يمرّ في فضائه المفتوح. TLS هو ما يتيح لك أن تبني وسط هذا السوق «غرفة عازلة للصوت» تجري فيها محادثاتك الحسّاسة بسرّية. لكنّ للاسم قصّة تشرح الالتباس الشائع.

الاسم الأصليّ كان SSL (طبقة المقابس الآمنة)، طُوّر في التسعينيات، وصدر منه إصداران (2.0 و3.0) صارا اليوم مهجورَين لثغرات أمنية فيهما. ثمّ خلَفه TLS (أمان طبقة النقل): صدر TLS 1.0 سنة 1999 ترقية لـSSL 3.0، وما يُستعمَل اليوم هو TLS 1.2 وTLS 1.3.^[1] فالتقنية الحيّة كلّها TLS، لكنّ كلمة «SSL» القديمة بقيت عالقة في الأذهان؛ فحين تسمع «شهادة SSL»، المقصود تقنيًا «شهادة TLS».

ويحقّق هذا البروتوكول ثلاثة أركان للثقة معا:

• التشفير (السرّية): يحوّل بياناتك إلى صيغة غير مفهومة لا تُقرأ إلا بمفتاح سرّي، فلو تنصّت أحد على الطريق لم يسمع إلا ضجيجا.
• المصادقة (الهوية): يثبت أن الخادم الذي تكلّمه هو فعلًا من يدّعي، لا موقعا مزيّفا نصبه مهاجم.
• السلامة (عدم العبث): يكشف أيّ تعديل يطرأ على البيانات في الطريق، فلا يستطيع وسيط أن يحقن أو يبدّل دون أن يُفتضح.

التشفير وحده لا يكفي: لو شفّرتَ محادثتك مع منتحِل، فأنت تسلّمه أسرارك في غلاف مقفل. هنا يكمن خطر «الرجل في المنتصف» (Man-in-the-Middle): مهاجم يعترض اتصالك ويتظاهر بأنه موقع بنكك، فتشفّر معه بياناتك وأنت مطمئنّ، وهو يقرؤها كاملة. التشفير يحميك من المتنصّت الصامت، لكنه لا يحميك من المنتحِل النشِط. لهذا تأتي المصادقة قبل التشفير، وحجر زاويتها «الشهادة».

الشهادة: جواز سفر الموقع الرقميّ

كيف يتأكّد متصفّحك أن الخادم حقيقيّ؟ عبر ملفّ صغير حاسم اسمه الشهادة (Certificate)، أشبه بجواز سفر رقميّ للموقع.^[2] أهمّ ما فيها:

• اسم النطاق الذي صدرت له (مثل www.google.com).
• المفتاح العامّ (Public Key): مفتاح يشاركه الخادم علنا، يُستعمل في بداية المصافحة لتأمين الاتفاق على مفتاح الجلسة.
• هيئة الإصدار (CA) التي أصدرت الشهادة، ومدّة الصلاحية (تاريخا الإصدار والانتهاء).
• التوقيع الرقميّ: ختم مانع للتزوير وضعته هيئة الإصدار بمفتاحها الخاصّ، يتيح للمتصفّح أن يتحقّق أن الشهادة أصلية لم تُبدَّل.

من أين تأتي الثقة؟ هيئات الإصدار وسلسلة الثقة

لماذا يثق متصفّحك بهذه الشهادة؟ الثقة لا تأتي من الشهادة نفسها، بل من الجهة التي وقّعتها. فهيئة إصدار الشهادات (Certificate Authority) أشبه بمكتب إصدار الجوازات المعترف به: لا تُصدِر جواز سفرك بنفسك، بل تأخذه من جهة موثوقة، وكذلك لا يصدر صاحب الموقع شهادة موثوقة لنفسه.

تأتي المتصفّحات وأنظمة التشغيل محمّلة مسبقا بقائمة «هيئات جذرية» (Root CAs) تثق بها ثقة مطلقة (مثل DigiCert وISRG التي تشغّل Let’s Encrypt). حين يقدّم الخادم شهادته، يتتبّع المتصفّح توقيعها: شهادة الموقع موقّعة من هيئة وسيطة، والوسيطة موقّعة من جذر موثوق، كما في الشكل 1. فإن وصلت السلسلة إلى جذر في قائمته، وثِق وعرض القفل؛ وإن انكسرت حلقة، أو انتهت صلاحية الشهادة، أو كانت لنطاق مختلف، أطلق تحذيرا يمنعك من المتابعة.^[2]

شكل 1

وماذا لو تسرّب مفتاح موقع خاصّ قبل انتهاء شهادته؟ لذلك آليّات لـ«إبطال» الشهادة قبل أجلها: قوائم الإبطال (CRL) وبروتوكول الاستعلام الفوري (OCSP) اللذان يتحقّق بهما المتصفّح أن الشهادة لم تُلغَ. وهذه إحدى حُجج تفضيل الشهادات القصيرة الأجل: كلّما قصُر العمر، قلّ الزمن الذي تبقى فيه شهادة مسروقة صالحة.

وهذه المنظومة كلّها (مفاتيح عامّة وخاصّة، وشهادات، وهيئات إصدار، وقوائم ثقة في المتصفّحات) تُسمّى «البنية التحتية للمفتاح العامّ» (PKI). وهي ما يحوّل الثقة بين غريبين لم يلتقيا قطّ، أنت وخادم في طرف آخر من العالم، من أمر مستحيل إلى أمر يوميّ لا تكاد تنتبه إليه.

ويبقى في هذه المنظومة سؤال يستحقّ أن يُطرح: إن كانت الهيئات هي التي توقّع، فمن يراقب الهيئات؟ فهيئة واحدة مخترَقة أو مخطئة قد تُصدر شهادة باسم نطاقك لمن ليس أنت، ولا يفرّق متصفّحك بينها وبين شهادتك ما دام الجذر موثوقا. الجواب المُعتمد اليوم هو «شفافية الشهادات» (Certificate Transparency): سجلّات عامّة لا يُحذَف منها شيء، تُدرَج فيها كلّ شهادة تُصدرها الهيئات، فيطلب المتصفّح إثبات الإدراج قبل أن يقبل الشهادة.^[7]

وفائدة هذا العلن مزدوجة. فمن جهة لا تستطيع هيئة أن تُصدر شهادة في الظلّ ثمّ تنكر، لأنّ الإصدار مسجّل للعامّة. وصار بوسع صاحب النطاق أن يراقب أيضًا: تُنبّهك خدمات مجانيّة كلّما ظهرت في السجلّات شهادة باسم نطاقك، فتعرف بالإصدار المشبوه في ساعته لا بعد أن يُستعمل. وهذا انتقال من الثقة إلى التحقّق.

ويكمّل شفافيةَ الشهادات إجراء سابق لها في الزمن: سجلّ CAA في نطاقك. فبه تُعلن أيّ الهيئات يحقّ لها أن تُصدر شهادة لاسمك، والهيئة ملزمة بقراءة هذا السجلّ قبل الإصدار والامتناع إن لم تكن مذكورة فيه.^[8] فسطر واحد في إعدادات DNS، من جنس السجلّات التي فكّكتُ أنواعها في مقال نظام أسماء النطاقات، يضيّق دائرة من يستطيع إصدار شهادة باسمك من مئات الهيئات إلى واحدة تختارها. فالشفافية تكشف الخطأ بعد وقوعه، وسجلّ CAA يمنع وقوعه أصلًا.

مستويات التحقّق، وثورة الشهادات المجانية

تتحقّق الهيئات من طالب الشهادة بدرجات مختلفة. أبسطها التحقّق من النطاق (DV): تتأكّد الهيئة أن الطالب يسيطر على النطاق فحسب. وفوقه التحقّق من المؤسّسة (OV) الذي يثبت وجود الشركة قانونيا، ثمّ التحقّق الممتدّ (EV) بتدقيق أوسع. وكان EV يعرض اسم الشركة في شريط أخضر بالمتصفّحات القديمة، لكنّ المتصفّحات الكبرى أزالت هذا العرض سنة 2019 بعد أن تبيّن أنه لا يغيّر سلوك المستخدمين فعليا؛ فالنوع ما زال موجودا لكن بلا تمييز بصريّ خاصّ.^[5]

والأثر الأكبر في انتشار HTTPS لم يأتِ من هذه المستويات، بل من مبادرة Let’s Encrypt: هيئة غير ربحية تصدر شهادات DV مجّانًا، وبشكل آليّ بالكامل عبر بروتوكول ACME، فيجدّد الخادم شهادته من نفسه كل 90 يوما دون تدخّل.^[4] قبلها كانت الشهادة تُشترى وتُركَّب يدويا، فبقي نصف الويب على HTTP. بعدها صار التشفير مجّانيا وتلقائيا، فقفزت نسبة المواقع المشفّرة حتى صارت القاعدة لا الاستثناء. هذا مثال آخر على أن قرار «المجّانيّ والمفتوح» غيّر الويب أكثر من أيّ تحسين تقنيّ.

وعمليا، تركيب الشهادة اليوم أيسر من أيّ وقت: أكثر لوحات الاستضافة تركّبها بنقرة، وعلى خادم خاصّ تتكفّل أداة مثل certbot بطلبها وتجديدها آليا من Let’s Encrypt. أما قلق الأداء القديم (أن التشفير يبطئ الموقع) فقد زال: كلفة TLS الحسابية صارت ضئيلة، بل إنّ HTTP/2 وHTTP/3 الأسرع لا يعملان أصلًا إلا فوق اتصال آمن، فصار الأمان والسرعة في صفّ واحد لا صفّين متقابلين.

كيف تجري المصافحة؟

قبل تبادل أيّ بيانات، يجري المتصفّح والخادم «مصافحة TLS»: تفاوض سريع يثبتان فيه الهوية ويتّفقان على مفتاح سرّيّ، كلّه دون أن يفهم المتنصّت شيئا. تجري في أجزاء من الثانية على هذا النحو:

• يبدأ المتصفّح بتحيّة يعرض فيها إصدارات TLS و«مجموعات التشفير» التي يتقنها.
• يردّ الخادم باختيار أقوى ما يتّفقان عليه، ويرسل شهادته (وفيها مفتاحه العامّ).
• يتحقّق المتصفّح من الشهادة: صلاحيتها، ومطابقتها للنطاق، وسلسلة توقيعها حتى جذر موثوق. هذه خطوة المصادقة الحاسمة.
• يتّفق الطرفان على «مفتاح جلسة» سرّيّ مشترك دون أن يرسلاه في العلن.
• من تلك اللحظة، يشفّران كل رسائل HTTP بهذا المفتاح بتشفير «متماثل» سريع، ويظهر القفل.

والخطوة الرابعة هي ألطف ما في الأمر، وفيها تطوّر مهمّ يُغفله كثير من الشروح. الفكرة الأساس هي الجمع بين نوعَي تشفير: «غير متماثل» (مفتاح عامّ يشفّر، وخاصّ يفكّ) لتأمين الاتفاق على المفتاح، ثمّ «متماثل» (مفتاح واحد مشترك) لسرعة تشفير المحادثة الفعلية. ولماذا لا يُكتفى بالنوع غير المتماثل لكل شيء؟ لأنه بطيء ومكلِّف حسابيا، يصلح لتبادل سرّ صغير لا لتشفير ميغابايتات من البيانات في كل ثانية. أما المتماثل فسريع جدا لكنه يشترط مفتاحا يعرفه الطرفان سلفا. فالحلّ أن يُستعمَل البطيء الآمن مرّة واحدة للاتفاق على مفتاح السريع، ثمّ يتولّى السريع بقية الجلسة.

أما كيف يُتّفق على المفتاح المشترك، فهنا الفرق بين الأمس واليوم. في الطريقة القديمة، كان المتصفّح يولّد سرّا ويشفّره بالمفتاح العامّ للخادم، فلا يفتحه إلا الخادم بمفتاحه الخاص. لكنّ هذا له عيب: لو سُرِق مفتاح الخادم الخاصّ لاحقًا، أمكن فكّ كل المحادثات القديمة المسجّلة. لذا اعتمد TLS 1.3 طريقة تُسمّى «التبادل العابر» (Ephemeral)، يشتقّ فيها الطرفان سرّا جديدا لكل جلسة لا يُرسَل أبدًا ويُمحى بعدها. النتيجة خاصّية اسمها «السرّية التامّة إلى الأمام» (Forward Secrecy): تسريب مفتاح الخادم اليوم لا يكشف محادثات الأمس.^[3]

وقد جعل TLS 1.3 (الصادر سنة 2018) هذه السرّية إلزامية، واختصر المصافحة إلى جولة ذهاب وإياب واحدة بدل اثنتين، وأسقط الخوارزميات الضعيفة التي كان يسمح بها 1.2.^[3] فالنتيجة اتصال أسرع وأأمن في آن.

و«مجموعة التشفير» (Cipher Suite) التي يتّفقان عليها ليست خوارزمية واحدة، بل حزمة: طريقة للاتفاق على المفتاح، وأخرى لتشفير البيانات، وثالثة للتحقّق من سلامتها. ومن إنجازات TLS 1.3 أنه قلّص هذه الحزم إلى قائمة قصيرة من الخيارات القوية فقط، فأزال حيرة الاختيار وثغرات الإعدادات الضعيفة التي طالما أوقعت أصحاب المواقع.

فحين تفتح موقع بنكك، يجري هذا كلّه في أجزاء من الثانية قبل أن تظهر صفحة الدخول: يتأكّد متصفّحك أن الشهادة صادرة فعلًا لبنكك وموقّعة من هيئة موثوقة، ثمّ يتّفقان على مفتاح سرّيّ، فلا يصل ما تكتبه من اسم وكلمة مرور إلا إلى البنك وحده. ولو حاول منتحِل اعتراض الاتصال، لسقط عند خطوة التحقّق من الشهادة، إذ لا يملك شهادة صحيحة باسم البنك موقّعة من جذر موثوق.

وفي هذه الخطوة بالتحديد يجري اليوم أكبر تغيير في TLS منذ الإصدار 1.3. وأنت لا تشعر به. فتبادل المفاتيح الذي مرّ بك قائم على مسائل رياضية يعجز الحاسوب التقليديّ عن حلّها، ولا يعجز عنها حاسوب كموميّ كبير إن وُجد. والخطر ليس مستقبليّا بحتا: من يسجّل مرورك المشفّر اليوم يستطيع فكّه بعد سنوات حين تتوفّر الآلة.

ولهذا انتقلت المتصفّحات إلى تبادل مفاتيح «هجين» يجمع الطريقة التقليدية وطريقة مقاومة للكمّ في عملية واحدة، فلا يفكّ المهاجم الاتصال إلّا إن كسر الاثنتين معا. مكّنت Chrome ذلك افتراضيّا في أبريل 2024، وتبعتها Firefox في نوفمبر من العام نفسه. وصار الخيار المعروف بـX25519MLKEM768 هو الافتراضيّ في TLS 1.3. وبحسب قياسات Cloudflare في أبريل 2026، صار أكثر من ثلثي مرور المستخدمين المشفّر يستعمله فعلًا.^[9] أي أنّ متصفّحك يحمي محادثاتك اليوم من آلة لم تُبنَ بعد.

ماذا يُخفي TLS؟ وماذا يبقى مكشوفا

يشفّر TLS محتوى طلباتك وردودك: الصفحات التي تطلبها، وما تكتبه في النماذج، وكلمات مرورك. لكنّه لا يخفي كل شيء. يبقى مكشوفا لمن يراقب الطريق: عنوان IP للخادم الذي تتّصل به، وغالبًا اسم النطاق نفسه (يُرسَل في مطلع المصافحة باسم SNI ليعرف الخادم أيّ موقع تريد من بين مواقع كثيرة يستضيفها على العنوان نفسه)، وحجم البيانات وتوقيتها. بعبارة أخرى: قد لا يرى مزوّد خدمتك ماذا قرأتَ على موقع ما، لكنّه يرى أنك زرته. وثمّة امتداد حديث (ECH) يسعى لإخفاء اسم النطاق أيضًا، لكنّ انتشاره ما زال في بدايته. معرفة حدّ ما يخفيه التشفير بقدر معرفة ما يخفيه: فهي تجنّبك ثقة زائدة في غير محلّها.

شكل 2

ونقطة تكمّلها: أين يجري فكّ التشفير؟ ليس دائمًا على خادمك مباشرةً. كثير من المواقع تضع أمامها شبكة توصيل محتوى (CDN) أو موازن حِمل يتولّى مصافحة TLS نيابة عنها (ويُسمّى ذلك «إنهاء TLS»)، ثمّ يمرّر الطلب إلى الخادم الخلفيّ. هذا يخفّف الحِمل ويقرّب المصافحة من المستخدم، لكنّه يعني أن الجهة التي تُنهي TLS ترى بياناتك مكشوفة عندها، فاختَرها بثقة.

ماذا تعني رسائل خطأ الشهادات؟

متى فهمتَ آلية الثقة، صارت أعطالها مقروءة. هذه أشيعها:

المحتوى المختلط (Mixed Content)

يحدث حين تكون الصفحة على HTTPS لكنها تحمّل بعض مواردها (صورة أو نصّا برمجيا) عبر HTTP غير آمن، كشاحنة مصفّحة تُرِك أحد أبوابها مفتوحا. فلا يعرض المتصفّح قفلا كاملا، وغالبًا يحجب المورد غير الآمن لحمايتك، فقد ينكسر تصميم الصفحة. علاجه أن تكون كل الموارد على HTTPS.

شهادة منتهية الصلاحية

الشهادات لها أجل (شهادات Let’s Encrypt مثلًا 90 يوما)، وإن نسي صاحب الموقع تجديدها عرض المتصفّح تحذيرا بملء الصفحة («اتصالك ليس خاصّا») يمنع المرور بسهولة، لأنه لم يعد قادرا على التحقّق من الهوية. وهذا بالذات ما يجعل التجديد الآليّ (عبر ACME) مهمّا.

شهادة غير موثوقة أو موقّعة ذاتيا

يظهر حين لا تنتمي الشهادة إلى سلسلة تنتهي بهيئة موثوقة، غالبًا لأنها «موقّعة ذاتيا» (أنشأها صاحب الخادم بنفسه) أو صادرة عن هيئة مجهولة. يقول المتصفّح عمليا: «عُرض عليّ جواز سفر، لكنّي لا أعرف الجهة التي أصدرته، فلا أثق به». والشهادات الموقّعة ذاتيا مقبولة في بيئة التطوير المحلية، لا على موقع عامّ.

عدم تطابق الاسم

يحدث حين لا يطابق اسم النطاق في الشهادة العنوان في شريط المتصفّح، كأن تكون الشهادة لـwww.example.com وتزور example.com دون أن يكون الخادم مهيّأ لكليهما. فلا يستطيع المتصفّح أن يجزم أن الخادم يملك العنوان الذي قصدتَه، فيحذّر. ولتفادي ذلك تدعم الشهادات أسماء متعدّدة: شهادة «SAN» تغطّي عدّة نطاقات مختلفة في وثيقة واحدة، وشهادة «البدل» (Wildcard) مثل *.example.com تغطّي كل النطاقات الفرعية دفعة واحدة، فيجمع الموقع نطاقه الرئيس وفروعه تحت شهادة واحدة بلا أخطاء تطابق.

القفل ليس ضمانة صدق

يبقى تنبيه مهمّ: القفل يعني أن الاتصال مشفّر وأن هوية النطاق موثّقة، لا أن الموقع «صادق» أو «حسن النيّة». فموقع احتياليّ يستطيع أن يحصل على شهادة DV مجّانية ويعرض قفلا، لأن DV لا تتطلّب إلا إثبات السيطرة على النطاق، لا فحص النشاط ولا النيّة؛ ولهذا تحمل كثير من مواقع التصيّد قفلا سليما. التشفير يحمي الطريق بينك وبين الخادم، لكنه لا يحكم على نوايا صاحبه. القفل يقول: «الطريق إلى هذا الخادم آمن وهويته موثّقة»، لا «صاحب الخادم أمين». فلا تقرأ القفل أكثر مما يقول.

على أن HTTPS اليوم لم يعد ميزة إضافية بل شرطا أساسيا: المتصفّحات تعلّم ما سواه «غير آمن»، وكثير من مزايا الويب الحديثة لا تعمل إلا عليه. وقد رأيتَ في مقال HTTP ترويسة HSTS التي تفرض على المتصفّح ألّا يتّصل بالموقع إلا مشفّرا أبدًا، فتحمي كلّ زيارة بعد الأولى. أمّا الزيارة الأولى نفسها فلا تحميها ترويسة لم تصل بعد، وتلك ثغرة تسدّها قائمة مُدمَجة في المتصفّح اسمها قائمة HSTS المُحمَّلة مسبقا.^[6] وTLS ليس للويب وحده: البريد الآمن، وشبكات VPN، وواجهات البرمجة، ومعظم ما يتّصل اليوم، يستعمل الطبقة نفسها لحماية اتصاله.

افحص شهادة بنفسك

لست مضطرّا إلى تصديق هذا الشرح؛ افحص شهادة أيّ موقع الآن. انقر القفل الصغير في شريط العنوان، ثمّ اختر «الاتّصال آمن» أو «تفاصيل الشهادة» (تختلف التسمية قليلا بين المتصفّحات). فترى من أصدر الشهادة (هيئة الإصدار)، ولمن صدرت (اسم النطاق)، ومتى تبدأ صلاحيتها ومتى تنتهي، وسلسلة الثقة كاملة من الموقع صعودا إلى الجذر. جرّبه على موقع بنكيّ ثمّ على مدوّنة عاديّة، ولاحظ الفرق في معلومات المالك بين مستويات التحقّق التي شرحتُها لك. دقيقة واحدة تجعل كلّ ما سبق ملموسا أمام عينيك.

من الأمان إلى السرعة

TLS هو ما يحوّل الويب من ساحة مكشوفة إلى مكان تُجرى فيه المعاملات الحسّاسة بثقة: يثبت الهوية بالشهادة وسلسلة الثقة، ويعمّي المحادثة بمفتاح يُشتقّ لكل جلسة على حدة بحيث لا يكشفه تسريب لاحق، ويكشف أيّ عبث يطرأ على البيانات في الطريق. ومتى عرفتَ المصافحة وقرأت رسائل الخطأ، لم يعد القفل أيقونة غامضة، بل آلية تفهمها. وحين يعترضك تحذير في موقع، صرتَ تعرف أين الخلل: أشهادة منتهية، أم موقّعة ذاتيا، أم اسم لا يطابق النطاق، لا مجرّد «خطأ غامض» تتجاوزه بنقرة متسرّعة.

وقد رأيتَ أن TLS يثبت هويةَ الخادم لك، لكن يبقى الوجه الآخر: كيف يتعرّف الموقع عليك أنت، ويبقى دخولك قائما، رغم أن HTTP لا يتذكّر شيئا؟ هذا موضوع المقال التالي: «الكوكيز والجلسات»، حيث ترى كيف يمنح الويب نفسه ذاكرة للتعرّف عليك.

المصادر

1. MDN Web Docs: Transport Layer Security. تعريف TLS وعلاقته بـSSL، والإصدارات، والأركان.
2. AWS: What is an SSL certificate? محتوى الشهادة، وهيئات الإصدار، وسلسلة الثقة، والتحقّق.
3. IETF: RFC 8446: TLS 1.3. المصافحة بجولة واحدة، والسرّية التامّة إلى الأمام، وإسقاط الخوارزميات الضعيفة.
4. Let’s Encrypt: How It Works. الشهادات المجّانية المؤتمتة عبر بروتوكول ACME.
5. Wikipedia: Extended Validation Certificate. إزالة المتصفّحات لعرض شهادات EV سنة 2019.
6. IETF: RFC 6797: الإلزام الصارم بالنقل الآمن (HSTS)، القسمان 12.3 و14.6. ثغرة الاتصال الأوّل، والقائمة المُحمَّلة مسبقا التي وُضعت لسدّها.
7. IETF: RFC 9162: شفافية الشهادات (الإصدار 2.0). السجلّات العامّة غير القابلة للحذف، وإثبات الإدراج الذي يطلبه المتصفّح.
8. IETF: RFC 8659: تخويل هيئات الإصدار عبر DNS (CAA). كيف يحدّد صاحب النطاق الهيئات المسموح لها بالإصدار، وإلزام الهيئة بقراءته.
9. Cloudflare Radar: اعتماد التشفير المقاوم للكمّ، بقياس أبريل 2026. نسبة المرور المشفّر الذي يستعمل تبادل مفاتيح هجين.