أمن طبقة النقل (TLS)

لفهم أهداف التصميم ومتطلبات معيار أمن طبقة النقل (Transport Layer Security، TLS) وطبقة المقابس الآمنة (Secure Socket Layer، SSL) التي يقوم عليها TLS، من المفيد أن نأخذ في الحسبان المشكلات الرئيسية التي اخترُع من أجل حلّها. فمع انتشار الشبكة العنكبوتية العالمية (World Wide Web) وبدء المؤسسات التجارية في إبداء اهتمام بها، اتضح أنه يلزم قدرٌ ما من الأمن للمعاملات التي تجري عبر الشبكة. والمثال النموذجي على ذلك هو الشراء بواسطة بطاقات الائتمان. وهناك عدة قضايا مقلقة عند إرسال معلومات بطاقتك الائتمانية إلى حاسوب على الشبكة. أولًا، قد تساورك مخاوف من أن تُعترَض تلك المعلومات أثناء نقلها ثم تُستخدَم لإجراء مشتريات غير مصرّح بها. وقد تساورك أيضًا مخاوف من تعديل تفاصيل معاملة ما، مثل تغيير مبلغ الشراء. وبطبيعة الحال، تودّ أن تتأكد من أن الحاسوب الذي ترسل إليه معلومات بطاقتك الائتمانية يعود بالفعل إلى البائع المعنيّ وليس إلى طرف آخر. وعليه، نرى على الفور حاجةً إلى السرّية (confidentiality) والسلامة (integrity) والمصادقة (authentication) في معاملات الشبكة. وكان أول حلّ منتشر على نطاق واسع لهذه المشكلة هو SSL، الذي طُوِّر في الأصل بواسطة نتسكيب (Netscape) ثم صار أساسًا لمعيار TLS الخاص بـ IETF.

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

الشكل 12. إدخال طبقة نقل آمنة بين طبقة التطبيق وطبقة TCP.↗

وعند استخدام HTTP بهذه الطريقة يشار إليه بـHTTPS (‏HTTP الآمن). وفي الواقع لم يتغيّر HTTP نفسه؛ فهو ببساطة يسلّم البيانات إلى طبقة SSL/TLS ويستقبل منها بدلًا من TCP. ولتيسير الأمور، خُصّص لمنفذ TCP افتراضي خاص بـHTTPS وهو المنفذ 443. أي أنه إذا حاولت الاتصال بخادم على منفذ TCP رقم 443، فغالبًا ما ستجد نفسك تتحدث عبر بروتوكول SSL/TLS، الذي يمرّر بياناتك إلى HTTP شريطة أن يسير كل شيء على ما يرام مع المصادقة وفكّ التعمية. وبرغم توفّر تنفيذات مستقلة لـSSL/TLS، فإن الأمر أشيعَ أن تكون مرفقة بالتطبيقات التي تحتاج إليها، ولا سيما متصفحات الويب والخوادم.

ولا يخلو النهج الطبقي، الذي يُدرِج TLS بين بروتوكول التطبيق وبروتوكول النقل، من عيوب، ولا سيما عند النظر في الأداء. وقد أدّى هذا في النهاية إلى إعادة التفكير في هذا الترتيب الطبقي، فتم تطوير بروتوكول نقل جديد هو QUIC مستفيدًا من عقود الخبرة مع TLS وHTTP. وسنعود إلى هذا التطور لاحقًا.

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

ومثل TCP، يملك TLS مرحلة تهيئة تنطوي على عمليّات مصافحة (handshake)، تليها مرحلة يتّصل فيها الطرفان وتتبادل البيانات. وسنناقش كلًّا منهما على حدة، بدءًا من بروتوكول المصافحة (handshake protocol) الذي يدعم التهيئة الأولية. وبعد أن ترسّم المصافحة خصائص الاتصال، يُستخدَم بروتوكول السجلات (record protocol) لحماية البيانات المرسلة بين الطرفين.

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

6.1 بروتوكول المصافحة

المهمة الأساسية لبروتوكول المصافحة هي السماح لزوج من المشاركين في TLS بتأسيس سرّ مشترك، والتفاوض أثناء التشغيل على مجموعة الخوارزميات التشفيرية التي ستُستخدَم. كما يتيح التفاوض على الإصدار، بحيث يمكن مثلًا لعميل يعمل بالإصدار 1.2 من TLS أن يتحدث إلى خادم يدعم الإصدارين 1.2 و1.3. كما يتيح للعميل مصادقة الخادم، ويمكن بشكل اختياري أن تُصادَق هويّة العميل أيضًا.

ولا بدّ أن يكون بروتوكول المصافحة مقاومًا لهجمات الوسيط (man-in-the-middle، MITM) التي ناقشناها في الفصل 4. ففي مرحلة ما من تاريخه، كان بإمكان مهاجم من هذا النوع أن يُفسد التفاوض على الإصدار بحيث يتفق العميل والخادم على إصدار أدنى مما يلزم. ويفتح هذا «هجوم التخفيض» (downgrade) الباب أمام خطر استغلال ثغرات قديمة في الإصدار الأدنى، مثل بروتوكولات التشفير الضعيفة.

يتخذ TLS احتياطات متعددة لزيادة مقاومته لهجمات الوسيط. فـTLS 1.3 يعمّي معظم بروتوكول المصافحة، في أبكر مرحلة ممكنة من العملية. ولتسهيل ذلك، تنطوي الخطوة الأولى من المصافحة على تأسيس سرّ مشترك بين العميل والخادم. ويُحقق ذلك في الغالب باستخدام تبادل مفاتيح ديفي-هيلمان (Diffie-Hellman) عابر (ephemeral)، كما هو موضّح في الفصل 4. كما أن المفاتيح المُسبقة التشارُك مدعومة أيضًا، ولها دور في إعادة تشغيل جلسة بسرعة، كما سنناقش في القسم 6.3.

وحين وصفنا ديفي-هيلمان في الفصل 4، شرحنا الخوارزمية الأصلية التي تعمل على مجموعات من الأعداد الصحيحة باستخدام الحساب النمطي. وهذه تُعرف الآن باسم ديفي-هيلمان في الحقول المنتهية (Finite Field Diffie-Hellman). ومن الممكن أيضًا استعمال المنحنيات الإهليلجية (elliptic curves) بدلًا من الحساب النمطي، والخياران كلاهما متاح في TLS الحديثة.

هناك عدد من الطرق التي يمكن أن تسير بها بروتوكول المصافحة، لكن مجموعةً نموذجية من العمليات هي كما يلي:

1. يرسل العميل رسالة «مرحبًا من العميل» (client hello) تحدّد مجموعات ديفي-هيلمان أو المنحنيات الإهليلجية التي يدعمها، إلى جانب مفتاح ديفي-هيلمان عابر لكل مجموعة أو منحنى. وتتضمّن رسالة الترحيب أيضًا قيمةً غيرية (nonce)، ومجموعة الشيفرات (cipher suite) التي يستطيع العميل استخدامها في التعمية والمصادقة اللاحقتين، وإصدار TLS الذي يدعمه العميل.
2. يردّ الخادم برسالة «مرحبًا من الخادم» (server hello) تبيّن أيّ مجموعة أو أيّ منحنى من ديفي-هيلمان قد اختاره، إلى جانب مفتاح ديفي-هيلمان عام عابر مقابل. وتذكر رسالة الترحيب أيضًا إصدار TLS الذي يدعمه الخادم، ومجموعة الشيفرات التي اختارها من بين ما عرضه العميل، وقيمةً غيرية (nonce).

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

1. يرسل الخادم الآن شهادة واحدة أو أكثر. وفي أبسط الحالات، تكون هناك شهادة واحدة موقّعة من سلطة شهادات (certificate authority، CA) موثوق بها لدى العميل.
2. يرسل الخادم رسالة «التحقّق من الشهادة» (certificate verify)، التي تثبت أن الخادم يملك المفتاح الخاص المقابل للمفتاح العام الوارد في الشهادة التي قُدّمت قبل قليل. ويغطي التوقيع كل ما أُرسل في المصافحة حتى هذه اللحظة، بما في ذلك قيمتين غيريتين، مما يوفّر حماية ضد هجمات الإعادة (replay attacks). والتوقيع مع الشهادة كافٍ لإثبات للعميل أنه يتحدث إلى الخادم المقصود، لا إلى مهاجم في الوسط لن يستطيع تقديم هذا التوقيع.
3. يرسل الخادم رسالة «انتهت المصافحة» (handshake finished) التي تحتوي تجزئة (hash) لكل ما أُرسل حتى الآن، بما يضمن ألّا يكون شيء في المصافحة قد اعتُدِّل. وتوفّر هذه حماية إضافية ضد هجمات الوسيط.
4. يرسل العميل رسالة مماثلة بعنوان «انتهت المصافحة».

عند هذه النقطة يعرف العميل أنه يتحدث إلى الخادم المقصود، ويعرف الطرفان أنهما أكملا المصافحة بنجاح دون أي عبث بالرسائل. وفي هذه الحالة لا يعرف الخادم هوية العميل، لأن مصادقة العميل لم تتم. ويدعم TLS بالفعل مصادقة العميل باستخدام شهادات العميل (client certificates)، لكنه ليس القاعدة في إنترنت اليوم أن يصادق العملاء بهذه الطريقة.

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

يعرض الشكل 13 بروتوكول المصافحة على مستوى عالٍ. وحين يستقبل كلٌّ من العميل والخادم رسالة «انتهت المصافحة» من نظيره، تكتمل المصافحة ويصبح بإمكان بيانات التطبيق أن تبدأ بالتدفّق.

الشكل 13. بروتوكول المصافحة لإقامة جلسة TLS.↗

ويتم تنفيذ تعمية البيانات بين العميل والخادم بواسطة بروتوكول السجلات الخاص بـTLS. ولأن بروتوكول المصافحة في TLS 1.3 يتطلب التعمية بعد الرسالتين الأولى والثانية، فإن بروتوكول السجلات يدخل فعليًا في المشهد عند الخطوة 3 أعلاه، حتى قبل أن نصل إلى إرسال أي بيانات تطبيق. وسنناقش تفاصيل بروتوكول السجلات أدناه.

6.2 بروتوكول السجلات

مهمة بروتوكول السجلات هي حماية البيانات المرسلة عبر اتصال TLS بالتعمية والمصادقة معًا. وبرغم أن TLS يدعم مجموعة واسعة من طرائق التعمية والمصادقة، فإن مجموع الخيارات قد ضاق فعلًا في الإصدار 1.3 مع وضوح نقاط ضعف الطرق الأقدم وظهور خوارزميات تشفير جديدة. وتوفّر جميع خوارزميات TLS 1.3 التعمية والمصادقة معًا في مجموعة شيفرات واحدة، باستعمال التقنية المعروفة بالتعمية المصادَق عليها مع بيانات إضافية (authenticated encryption with additional data، AEAD) التي ناقشناها في الفصل 3.

في TLS، تستخدم الشيفرة التي توفّر المصادقة والتعمية مفتاحين، واحدًا لكل اتجاه. وعلى نحو مماثل، يلزم متجهّا تهيئة (initialization vectors). وعليه، أيًّا كانت مجموعة الشيفرات المختارة، تتطلّب جلسة TLS بفعالية أربعة مفاتيح يتفق عليها الطرفان. ويشتق TLS جميعها من سرّ مشترك واحد نُيل خلال مرحلة المصافحة.

وتسمى الخطوة التي تشتق المفاتيح ومتجهات التهيئة من السرّ المشترك «دالة اشتقاق المفاتيح المستندة إلى HMAC مع الاستخلاص والتوسيع» (HMAC-based extract-and-expand key derivation function، HKDF). والهدف هو إنتاج قدرٍ كافٍ من مادة اشتقاق المفاتيح لطبقة السجلات — متجهَي تهيئة ومفتاحين متماثلين بالطول المناسب — وأن يُنجَز ذلك بحيث لا يملك المهاجم طريقة أفضل لتخمينها من البحث الشامل (brute force). وبعبارة أخرى، نريد أن تكون المفاتيح ومتجهات التهيئة أقرب ما يمكن إلى العشوائية. وهذا أصعب قليلًا مما قد يبدو للوهلة الأولى، لأن السرّ المشترك الذي يُنال عبر ديفي-هيلمان، وهو نقطة انطلاقنا، ليس عشوائيًا تمامًا. وقد لا يكون السبب في ذلك واضحًا، لكن هدف خوارزميات ديفي-هيلمان المختلفة هو توليد سرّ مشترك، لا أن تكون هذه الأسرار موزّعة توزيعًا عشوائيًا.

وراء HKDF بعض الرياضيات الجادّة إلى حدٍّ ما، لكن الفكرة الأساسية تُسمى «الاستخلاص والتوسيع» (extract and expand). وتتمثّل الخطوة الأولى في «استخلاص» العشوائية من السرّ المشترك. ويجري ذلك بحساب رمز مصادقة رسالة مبنيّ على التجزئة (hash-based message authentication code، HMAC) — كما هو موضّح في الفصل 3 — فوق السرّ المشترك. ويصبح المفتاح شبه العشوائي الناتج مدخلًا للمرحلة التالية، إلى جانب مصدر إضافي للعشوائية: تجزئة كل ما ورد في المصافحة الأولية. ولاحظ أن رسائل المصافحة تتضمّن قيمتين غيريتين عشوائيتين. ثم تطبّق خطوة «التوسيع» دالة HMAC باستخدام هذه المدخلات، وتُعاد إضافة HMAC بقدر ما يلزم من المرات لإنتاج المقدار المطلوب من مادة المفاتيح ومتجهات التهيئة.

وحين تصبح جميع المفاتيح ومتجهات التهيئة متاحةً للعميل والخادم، تستطيع طبقة السجلات عندئذٍ حماية البيانات الأصلية بالتعمية والمصادقة. كما تتولى طبقة السجلات تجزئة البيانات وإعادة تجميعها — بتقسيم تدفّق النص الصريح الوارد إلى قطع يصل حجم كل منها إلى 2^14 بايت.

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

وعلى جانب الاستلام، تجري العملية في الاتجاه المعاكس، إذ تُمرَّر المفتاح المناسب والقيمة غيرية والنص المشفّر والبيانات الإضافية (الترويسات) إلى دالة فكّ التعمية في AEAD. وإذا نجحت المصادقة، يُستعاد النص الصريح ويمكن تمريره صعودًا إلى التطبيق. وإذا لم تنجح المصادقة، يُنهى الاتصال ويصدر تنبيه (alert).

6.3 استئناف الجلسة والعمل ببيانات 0-RTT

في وصفنا الأوّلي لمصافحة TLS، وصفنا كيف يُستخدم ديفي-هيلمان لتأسيس سرّ مشترك، لكننا أشرنا أيضًا إلى وجود خيار استعمال مفتاح مُسبق التشارُك (pre-shared key، PSK). وبرغم أنه ممكن تجهيز مفتاح مُسبق التشارُك خارج النطاق، فإن استعماله الأشيع هو السماح باستئناف الجلسة (session resumption)، مما يُغني عن الحاجة إلى إجراء عملية تبادل ديفي-هيلمان أخرى.

ومن الآثار الجانبية المهمة لاستعمال مفتاح مُسبق التشارُك إمكانية بدء إرسال البيانات في مرحلة أبكر من العملية. ويُشار إلى هذه العملية بـ«بيانات 0-RTT»، لأنه من الممكن بدء إرسال بيانات التطبيق مع مادة المصافحة دون انتظار انقضاء زمن رحلة الذهاب والإياب للمصافحة. وهذه خطوة مهمة في تحسين زمن استجابة إنشاء اتصال HTTPS، وبالتالي تحسين تجربة المستخدم عند تصفّح الشبكة.

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

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

وحين يرى الخادم أن العميل قد أرسل تذكرة، يتحقق من صحة الربط، فإن نجح حساب HMAC، اتّفق الخادم والعميل الآن على أنهما يستطيعان استعمال سرّ مشترك أُسّس في الجلسة السابقة. ويستخدمان «سرّ استئناف عتيمي» (resumption master secret) حُسب وخُزّن في الجلسة السابقة ليشتقا مجموعة مفاتيح جديدة لهذه الجلسة. وتختلف مفاتيح الجلسة الجديدة عن مفاتيح الجلسة السابقة لدعم السرّية الأمامية (forward secrecy) — أي أنه حتى لو تمكّن المهاجم من اختراق مفتاح جلسة ما، فلن يكتسب القدرة على فكّ تشفير بيانات جلسات أخرى.

وحين يرسل الخادم رسالة Finished الخاصة به، فإنه يحسب HMAC على رسائل المصافحة باستخدام المفتاح الجديد المتّفق عليه، وبذلك يصادق نفسه أمام العميل.

ولو نظرنا إلى استئناف الجلسة بمفرده كما وُصف للتو، فقد لا يبدو ذا أهمية كبيرة. فهو يتجنّب الحاجة إلى عملية تبادل ديفي-هيلمان أخرى، لكنه يظل يتطلّب رحلة ذهاب وإياب واحدة لإنشاء الجلسة. غير أن مفاتيح الجلسة الجديدة معروفة للطرفين قبل إرسال أول رسالة مصافحة، مما يتيح لاستئناف الجلسة فتح إمكان إرسال «بيانات 0-RTT» مع المصافحة. إذ يمكن تضمين بيانات 0-RTT مع رسائل المصافحة دون انتظار رحلة ذهاب وإياب واحدة حتى تُرسَم المفاتيح. وهذا مفيد من ناحية الأداء، ولا سيما للاتصالات قصيرة العمر، لكنه يأتي مع بعض العيوب من ناحية الأمان.

هناك عيبان رئيسيان لبيانات 0-RTT. الأول أنها عرضة لهجمات الإعادة بطريقة ليست كذلك نقل البيانات الآخر. فإذا استطاع المهاجم أن يجلس بين عميل وخادم، فلديه فرصة لإعادة إرسال بيانات 0-RTT. أما مقدار الضرر الذي يلحقه ذلك فمرهوب جدًا منه للتطبيق، لذلك تشترط مواصفات TLS أن (أ) لا تُرسَل بيانات 0-RTT إلا عندما تطلب طبقة التطبيق ذلك صراحةً، أي أنها لا يمكن أن تكون مجرد تحسين توفّره طبقة المقابس، و(ب) أن يعرف التطبيق كيفية التعامل مع إعادة إرسال البيانات المُرسلة كبيانات 0-RTT، مثلًا بإرسال بيانات 0-RTT فقط للعمليات التي لا يتأثر نتيجتها بإعادتها (idempotent).

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

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

6.4 QUIC وHTTP/3 وTLS

منذ اختراع الشبكة العنكبوتية العالمية في تسعينيات القرن الماضي، كان HTTP يعمل فوق TCP. وكان للإصدار الأصلي HTTP/1.0 عدد كبير من مشكلات الأداء بسبب الطريقة التي كان يستعمل بها TCP، مثل أن كل طلب لعنصر كان يتطلّب إنشاء اتصال TCP جديد ثم إغلاقه بعد إعادة الرد. وقد اقتُرح HTTP/1.1 في مرحلة مبكرة للاستفادة الأفضل من TCP. وظل TCP هو البروتوكول الذي يستخدمه HTTP لأكثر من عشرين عامًا أخرى.

وقد أدّى إضافة الأمان إلى HTTP فوق TCP على هيئة SSL وTLS إلى تفاقم مشكلات الأداء أكثر، حتى مع تحسينات HTTP التي خفّفت بعض المشكلات الأصلية. وكما ذُكر في القسم السابق، فإن إنشاء جلسة TLS آمنة يتطلّب رحلة ذهاب وإياب واحدة على الأقل. أما إضافة بيانات 0-RTT التي ظهرت حديثًا نسبيًا فيخفض زمن الاستجابة قبل أن يمكن إرسال البيانات الأولى؛ وهو أيضًا يأتي مع بعض عيوب الأمان كما لاحظنا أعلاه.

وبطبيعة الحال، فإن الوقت اللازم لإنشاء جلسة آمنة مع TLS يكون إضافةً إلى الوقت اللازم لإنشاء اتصال TCP. ويحتاج TCP إلى إتمام مصافحته الثلاثية (three-way handshake) قبل أن يُرسَل أول رسالة مصافحة لـTLS — وهي مجرد بيانات بالنسبة إلى TCP —. وكان تسلسل الأحداث إذن كما يلي:

• يبدأ العميل المصافح الثلاثية لـTCP لإنشاء جلسة TCP.
• تُنشئ مصافحة TLS معاملات الأمان الخاصة بالاتصال بين العميل والخادم.
• تُرسَل أول رسالة HTTP من العميل إلى الخادم.

وبعبارة أخرى، في نموذج TLS فوق TCP الأصلي كانت ستستغرق ثلاث رحلات ذهاب وإياب على الأقل للحصول على رد على طلب HTTPS واحد. بل كانت المدة قبل ظهور TLS 1.3 أربع رحلات ذهاب وإياب على الأقل بسبب استعمال رحلتين لإكمال مصافحة TLS.

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

وتضافرت عوامل أخرى، مثل ظهور شبكات لاسلكية ذات زمن استجابة مرتفع وتوفّر شبكات متعددة لجهاز واحد (مثل Wi-Fi والخلوي)، لتوصلنا إلى أن طبقة النقل الخاصة بـHTTP ستحتاج مقاربة جديدة. وكان البروتوكول الذي ظهر لسد هذه الحاجة هو QUIC.

وفي هذا القسم سنركّز على كيف يحسّن QUIC خصوصًا أداء TLS مقارنةً بالتشغيل فوق TCP. فـQUIC هو إعادة عمل شاملة إلى حدٍّ كبير لطبقة النقل، ويمكن أن يشغل كتابًا خاصًا به — فضمجموعة RFCs التي تعرّفه تمتد إلى مئات الصفحات.

انطلق QUIC من Google عام 2012، ثم طُوِّر لاحقًا بوصفه معيارًا مقترحًا في IETF. وقد شهد بالفعل قدرًا كبيرًا من النشر — فهو موجود في معظم متصفحات الويب وفي كثير من المواقع الرائجة، بل بدأ استعماله حتى في تطبيقات غير HTTP. وقابلية النشر كانت اعتبارًا رئيسيًا في تصميم البروتوكول. فهناك أجزاء كثيرة متحركة في QUIC — إذ تمتد مواصفته عبر ثلاثة RFCs — لكننا نركّز هنا على كيفية تغييره للعلاقة بين TLS والناقل الأساسي.

إن التغيير الأهم على الإطلاق في QUIC من منظور أداء TLS هو أنه لا يعامل مصافحتي النقل والأمان طبقيتين منفصلتين. وبدلًا من ذلك، بُنيت في QUIC مصافحة تشفيرية قائمة على TLS داخل طبقة النقل. ويوضّح ذلك الشكل 14. وكما تقول RFC 9001:

بدلًا من التقسيم الطبقي الصارم، يتعاون البروتوكولان معًا: يستخدم QUIC مصافحة TLS؛ ويستخدم TLS الموثوقية والتسليم المرتّب وطبقة السجلات التي يوفّرها QUIC.

الشكل 14. مقارنة بين حزم البروتوكولات. (أ) HTTP فوق TLS فوق TCP. (ب) مصافحة HTTP وTLS فوق QUIC.↗

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

وأوضح أثر عملي واضح لهذا هو أن إنشاء اتصال QUIC يحدث في الوقت نفسه الذي تُرسَل فيه رسائل مصافحة TLS، بدلًا من أن يحدث قبل مصافحة TLS كما هو الحال مع TCP. وبحلول الوقت الذي تكتمل فيه مصافحة TLS، يكون طرفا اتصال QUIC قد توفّر لديهما كامل الحالة اللازمة لنقل بيانات مثل رسائل HTTP. وإضافةً إلى ذلك، في الحالات التي يمكن فيها إرسال بيانات 0-RTT (لوجود أسرار مشتركة مخزّنة من اتصال سابق)، يمكن إرسال أول طلب HTTP في الوقت نفسه الذي تُرسَل فيه رسالة ترحيب العميل.

وتفصيل أخير جدير بالذكر هو أن QUIC يعمل فوق UDP بدلًا من أن يعمل مباشرة فوق IP. والسبب في ذلك أن الإنترنت يحتوي على وسطاءات (middleboxes) كثيرة تفترض أن البروتوكولات الوحيدة المقبولة للنقل هي TCP وUDP فتحجب ما عدا ذلك. وعليه، وبرغم أن UDP لا يضيف الكثير من الوظائف المفيدة إلى QUIC، إلا أنه كان خطوة عملية موفّرة لتشغيل QUIC فوق UDP بغية تيسير نشره في الإنترنت.

ويُعد QUIC تطورًا مثيرًا للاهتمام في عالم بروتوكولات النقل، وليس فقط لأثره في الأمان. فقد كانت حدود TCP العديدة معروفة منذ عقود، لكن QUIC يمثّل واحدة من أنجح المحاولات حتى الآن لترسيخ موضع مختلف في فضاء التصميم. ولأن QUIC استُلهم من الخبرة مع HTTP وTLS والشبكة — التي ظهرت بعد أن رسخ TCP في الإنترنت بزمن طويل —، فإنه يقدّم حالة دراسية لافتة في النتائج غير المتوقعة للتصاميم الطبقية وفي تطوّر الإنترنت. وهناك الكثير مما لم نتمكّن من تغطيته هنا. والمرجع القاطع لـQUIC هو RFC 9000، بينما تتناول RFC 9001 العلاقة بين TLS وQUIC. ويظهر في الورقة التالية من SIGCOMM 2017 عرضٌ أكثر قابلية للقراءة لتصميم البروتوكول ونشره.

قراءات إضافية

A. Langley et al. The QUIC Transport Protocol: Design and Internet-Scale Deployment. Proc. ACM SIGCOMM، أغسطس 2017.

L. Peterson، L. Brakmo، وB. Davie، TCP Congestion Control: A Systems Approach.

6.5 منظور الأنظمة إلى TLS

حين نتحدث عن «مقاربة الأنظمة» (The Systems Approach)، فإننا نعود دائمًا إلى ضرورة النظر في كيفية تفاعل أجزاء النظام بعضها مع بعض لتشكيل كلٍّ متماسك، بدلًا من مجرد النظر في المكوّنات المنفردة بمعزل عن غيرها. فمثلًا، TLS نظام يضم التشفير بالمفتاح العام والتشفير بالمفتاح المتماثل، وآليات المصادقة والخصوصية، وسلطات الشهادات، وطبقات فرعية مثل بروتوكول السجلات وبروتوكول المصافحة. لكن مقاربة الأنظمة تنطبق على نحو متكرر أيضًا. فكما رأينا، من المهم النظر في موقع TLS داخل حزمة البروتوكولات إجمالًا، مع HTTP وتطبيقات أخرى فوقه، واختيار من بروتوكولات طبقة النقل (TCP وQUIC) تحته. وقد أثبتت التفاعلات بين هذه الطبقات حاسمتها في أداء الشبكة العنكبوتية العالمية والتطبيقات الأخرى التي تعمل فوق HTTPS.

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

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

ومن التطورات المهمة في نشر TLS إنشاء «Let's Encrypt»، وهي سلطة شهادات تديرها مؤسسة غير ربحية وتقدّم شهادات TLS دون أي مقابل. وبجعل الشهادات مجانية لمواقع الويب، ساعد «Let's Encrypt» في تقدّم causas جعل الاتصال المشفّر على الشبكة هو الخيار الافتراضي. وقبل إنشاء «Let's Encrypt»، كان من المعتاد أن تدفع المواقع مقابل شهادة من سلطة شهادات، وكان هذا الثمن غير هزيل للمواقع الصغيرة. ويصدر «Let's Encrypt» شهادات موثّقة بنطاق (domain-validated certificates). ويمكن أن يكون إصدار هذه الشهادات آليًا بالكامل ويعتمد على النطاق في تطبيق بروتوكول تحدٍّ واستجابة يُعرف بـACME (بيئة إدارة الشهادات الآلية). ولن نتوقف هنا عند التفاصيل، لكن توفّر شهادات مجانية آليًا الإصدار والتجديد قد أدّى إلى زيادة هائلة في انتشار HTTPS. وهذا بدوره يساعد على ترسيخ توقعات المستخدمين بوجود قفل في شريط عنوان المتصفح، حتى لو لم يكونوا يفهمون ما يجري تحت الغطاء.

ويمكن العثور على مزيد من التفاصيل عن «Let's Encrypt» في الورقة التالية.

قراءات إضافية

J. Aas et al. Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web. SIGSAC 2019.

ويظل أحد ميادين التحدي أمام المستخدمين النهائيين هو قدرة الجهات الخبيثة على إنشاء مواقع تبدو شرعية وتستعمل عناوين URL مشابهة للأصل بما يكفي لخداع المستخدمين. ويمكن أن يتم ذلك عبر أخطاء إملائية يسهل تفويتها (فـaccoounts-google.com مثال شهيرة على ذلك). ولا قيمة للاتصال المشفّر بالنسبة إلى المستخدم النهائي إذا كان يُوصله إلى موقع خبيث. وفي الفصل 9 ننظر إلى مفاتيح المرور (passkeys) كجزء من الحل لمش هجمات التصيّد التي تقود المستخدمين إلى مثل هذه المواقع. وهنا أيضًا، النظام الذي نحاول حمايته أكبر من مجرد اتصال من متصفح إلى موقع ويب.

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