SSL وTLS

SSL وTLS

الوصف

وSSL، اختصارًا لـ Secure Socket Layer، هو بروتوكول تشفير أدخلته أوّلًا شركة Netscape Communications ^[1] لتأمين حركة البيانات على الويب. وقد حلّ محلّه الآن TLS (Transport Layer Security)، وهو معيار أهلَته IETF في سلسلة RFCs. ولا يزال مصطلح SSL مستعملًا على نطاق واسع، حتى حين يقصد المتحدث في الحقيقة اتصال TLS. ومن الآن فصاعدًا، لن يستعمل هذا الكتاب إلّا مصطلح TLS، ما لم نكن نعني حقًا معيار SSL القديم.

وهدفه الأول والأوّل هو نقل البايتات بأمان، عبر الإنترنت أو عبر أيّ وسطٍ آخر غير آمن. tls12 وهو نظام تشفير هجين: فهو يستعمل خوارزميات متماثلة وغير متماثلة في آنٍ واحد. فمثلًا، يمكن استعمال خوارزميات غير متماثلة مثل خوارزميات التوقيع لتوثيق هوية الأطراف، بينما يمكن استعمال خوارزميات التشفير بالمفتاح العامّ أو تبادلات Diffie-Hellman للتفاوض على أسرار مشتركة وتوثيق الشهادات. أمّا في الجانب المتماثل، فتُستعمل شيفرات التيار\s (سواء الأصلية منها أو شيفرات الكتل في وضع تشغيل) لتشفير البيانات الفعلية التي تُرسَل، وتُستعمل خوارزميات MAC لتوثيق تلك البيانات.

وTLS هو أكثر أنظمة التشفير شيوعًا في العالم، ومن ثمّ هو على الأرجح أكثرها دراسةً. وعلى مدى السنين، اكتُشف في SSL وTLS كثيرٌ من العيوب، رغم مساهمة كثيرٍ من أشهر مشفّري العالم في المعيار وفي فحصه ^[2]. وإلى حدٍّ ما نعلم، فإنّ الإصدارات الحالية من TLS آمنة، أو يمكن ضبطها لتكون آمنة على الأقلّ.

المصافحات

TODO: اشرح مصافحة TLS حديثة

هجمات تخفيض المستوى

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

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

وهذا أحد الأسباب العديدة التي أدّت إلى وجود RFC صريح turner:prohibitssl20 يحظر على تنفيذات TLS الجديدة أن تدعم SSL v2.0.

جهات إصدار الشهادات

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

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

ومقابل رسمٍ ما، سيستعمل هؤلاء المالكون جهةَ إصدار شهاداتهم لتوقيع شهادات أخرى. والفكرة أنّ جهة إصدار الشهادات لن توقّع شهادة لـ Facebook أو لمصرف أو لأيّ شخص آخر، ما لم تستطع إثبات أنّك أنت بالتّحديد.

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

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

TODO: اشرح لماذا هذا احتكارٌ فاسد تمامًا

الشهادات الموقّعة ذاتيًا

شهادات العملاء

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

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

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

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

السرّية الأماميّة التامّة

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

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

وهناك بدائل واضحة لهذا المخطّط. فقد رأينا بالفعل تبادل المفاتيح Diffie-Hellman، الذي يتيح لطرفين الاتفاق على مفاتيح سرّية عبر وسطٍ غير آمن. ويتيح TLS للأطراف الاتفاق على السرّ الأوّلي باستعمال تبادل Diffie-Hellman، سواءً استنادًا إلى السجلّات أو إلى المنحنيات الإهليلجيّة.

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

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

الهجمات

كما في معظم الهجمات، يمكن عادةً تصنيف هجمات TLS في فئتين متمايزتين:

#. هجمات على البروتوكول نفسه، مثل تقويض آلية جهات إصدار الشهادات #. هجمات على تنفيذٍ معيّن أو شيفرة معيّنة، مثل هجمات التحليل الشفويّ التي تستغلّ نقاط ضعف في RC4، أو هجمات التوقيت في تنفيذ معيّن لـ AES.

ولأسف، تعرّض SSL/TLS لهجمات ناجحة في الفئتين معًا. ويتناول هذا القسم بصفة خاصة الفئة الثانية.

CRIME وBREACH

وCRIME هجوم من صنع مؤلّفي BEAST. وهو هجوم قناة جانبيّة مبتكر يعتمد على تسرّب معلومات عن الأسرار في النصّ الصريح عبر ضغط TLS. وفي هجومٍ مرتبط يُدعى BREACH، يحقّق المهاجمون الأثر نفسه باستعمال ضغط HTTP. وقد توقّع ذلك مؤلّفو البحث الأصلي، لكنّ مؤلّفي BREACH هم أوّل من أوضّحه بوصفه هجومًا عمليًّا. وكان هجوم BREACH أكثر قابلية للتطبيق عمليًّا: فضغط HTTP أوسع انتشارًا بكثير من ضغط TLS.

تسريب معلومات نسبة الضغط بسهولة (Compression Ratio Info-leak Made Easy)

الاستطلاع واستخراج البيانات عبر الضغط التكيّفيّ للنصّ الفائق في المتصفّحات (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) ويعتمد كلاهما على تشفير نصّ صريح مضغوط، وآليّتيهما متطابقتان إلى حدٍّ بعيد: فالتفاصيل الخاصّة المتعلّقة لضغط HTTP أو لضغط TLS وحدها هي ذات الأهمية. وأكبر فرق هو أنّه مع ضغط TLS يمكن مهاجمة السلسلة بأكملها، أمّا مع ضغط HTTP فلا يُضغط إلّا متن الطلب، فتبقى ترويسات HTTP آمنة. ولأنّ الهجمات متشابهة إلى حدٍّ كبير فيما عدا ذلك، فسنكتفي بالحديث عن كيفية عمل الهجوم على نحو مجرّد، ببيان كيف يمكن للمهاجمين تعلّم معلومات عن النصّ الصريح إذا كان مضغوطًا قبل التشفير.

وأكثر خوارزمية شيوعًا في ضغط HTTP وTLS معًا rfc3749:tlscompression هي DEFLATE. ولا تهمّ التفاصيل الدقيقة لـ DEFLATE كثيرًا، لكنّ المهمّ فيها أنّ متتاليات البايتات المتكرّرة يمكن تخزينها بكفاءة. فwhen متتالية بايتات تتكرّر ^[3]، لا تُسجَّل المتتالية نفسها، بل يُقدَّم مرجعٌ إلى المتتالية السابقة: فبدلًا من تكرار المتتالية، تقول «ارجع وانظر إلى الشيء الذي كتبته قبل N بايت».

ولنفترض أنّ المهاجم يستطيع التحكّم في النصّ الصريح. فمثلًا، يحقن المهاجم إطار iframe غير مرئي ^[4] أو بعض شيفرة JavaScript التي تُطلق طلبات كثيرة. ويحتاج المهاجم إلى وسيلة ما ليحقن تخمينه للسرّ بحيث يقع تخمينه في النصّ الصريح، مثل معاملات الاستعلام ^[5]. وعادةً ما يستطيع أن يسبق تخمينه بشيء معروف. فلنفترض أنّه يحاول اعتراض رمز مصادقة يُرسَل في متن صفحة الويب:

<input type="hidden"
       name="csrf-token"
       value="TOKEN_VALUE_HERE">

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

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

---

1. لمن هو أصغر سنًّا من أن يتذكّر، فإنّ Netscape شركة كانت تصنع المتصفّحات. ↩︎

2. إن لم أكن قد أصرّحت بذلك بما يكفي: فإنّ هذا لا يثبت إلّا أنّ تصميم أنظمة التشفير صعب، ومن المرجّح ألّا تصمّمه بنفسك. ↩︎

3. ضمن حدود؛ وتحديدًا ضمن نافذة منزلقة، بحجم 32 كيلوبايت عادةً. ولولا ذلك لكبرت المؤشّرات أكثر من المتتاليات التي يقصدها ضغطها. ↩︎

4. الـ iframe صفحة ويب مضمّنة داخل صفحة أخرى. ↩︎

5. أزواج المفتاح والقيمة في URL بعد علامة الاستفهام، مثل x=1&y=2 في http://example.test/path?x=1&y=2. ↩︎