ما هو TLS وما أهمية هذا البروتوكول لحماية الموقع، وكيف يعمل؟ وما هي أهم الخدمات التي تجعله مميزًا عن ناظريه؟ جميع ذلك ستجده من خلال ما هو موضح أدناه، بالإضافة إلى المقارنة بين TLS وSSL - وما علاقته بـ UDP؟
ما هو بروتوكول TLS وكيف يعمل بشكل مفصل؟
TLS أو Transport Layer Security هو بروتوكول تشفير يوفر أمانًا شاملاً للبيانات المرسلة بين التطبيقات عبر الإنترنت. إنَّه مألوف للمستخدمين أكثر من خلال استخدامه في تصفح الويب الآمن، وخاصة رمز القفل الذي يظهر في متصفحات الويب عند إنشاء جلسة آمنة. ومع ذلك يمكن، بل يجب استخدامه أيضًا لتطبيقات أخرى مثل: البريد الإلكتروني، ونقل الملفات، وملتقيات الفيديو/الصوت، والمراسلة الفورية والصوت عبر بروتوكول الإنترنت، بالإضافة إلى خدمات الإنترنت مثل DNS وNTP.
تطور TLS من Secure Socket Layers (SSL) الذي طورته Netscape Communications Corporation في عام 1994 لتأمين جلسات الويب. لم يتم إطلاق SSL 1.0 علنًا، بينما تم استبدال SSL 2.0 بسرعة بـ SSL 3.0 الذي يعتمد TLS عليه.
يستخدم TLS مزيجًا من التشفير المتماثل وغير المتماثل، حيث يوفر ذلك حلًا وسطيًا جيدًا، بين الأداء والأمان، من أجل نقل البيانات بشكل آمن.
باستخدام التشفير المتماثل، يتم تشفير البيانات وفك تشفيرها باستخدام مفتاح سري معروف لكل من المرسل والمستقبل؛ عادةً يكون: 128، ولكن يفضل أن يكون: 256 بايت (أي أقل من 80 بايت يعتبر الآن غير آمن).
يعد التشفير المتماثل فعالاً من حيث الحساب، لكن وجود مفتاح سري مشترك يعني أنَّه يجب مشاركته بطريقة آمنة.
يستخدم التشفير غير المتماثل أزواج المفاتيح - مفتاح عام ومفتاح خاص. يرتبط المفتاح العام رياضيًا بالمفتاح الخاص، ولكن نظرًا لطول المفتاح الكافي؛ فمن غير العملي من الناحية الحسابية اشتقاق المفتاح الخاص من المفتاح العام.
يسمح ذلك للمرسل باستخدام المفتاح العام للمستلم، من أجل تشفير البيانات التي يرغب في إرسالها إليهم، لكن لا يمكن فك تشفير هذه البيانات إلا باستخدام المفتاح الخاص للمستلم.
ميزة التشفير غير المتماثل هي أن عملية مشاركة مفاتيح التشفير لا يجب أن تكون آمنة، لكن العلاقة الرياضية بين المفاتيح العامة والخاصة تعني أن هناك حاجة إلى أحجام مفاتيح أكبر بكثير.
إنَّ الحد الأدنى الموصى به لطول المفتاح هو 1024 بايت، مع 2048 بايت المفضل، لكن هذا يصل إلى ألف مرة أكثر كثافة من الناحية الحسابية من المفاتيح المتماثلة ذات القوة المتكافئة (على سبيل المثال، المفتاح غير المتماثل 2048 بايت يكافئ تقريبًا مفتاح متماثل 112 بايت)، وهذا ما يجعل التشفير غير المتماثل بطيئًا جدًا للعديد من الأغراض.
نتيجة لذلك، يَستخدم TLS تشفيرًا غير متماثل، لإنشاء مفتاح جلسة وتبادله بشكل آمن. ثم يتم استخدام مفتاح الجلسة لتشفير البيانات المرسلة من قبل طرف واحد، وفك تشفير البيانات المستلمة من الطرف الآخر. بمجرد انتهاء الجلسة، يتم تجاهل مفتاح الجلسة.
يمكن استخدام مجموعة متنوعة من طرق إنشاء وتبادل المفاتيح المختلفة، بما في ذلك RSA وDiffie-Hellman (DH) وEphemeral Diffie-Hellman (DHE) وElliptic Curve Diffie-Hellman (ECDH) ومنحنى إهليلجي سريع الزوال Diffie-Hellman (ECDHE).
يوفر كل من DHE وECDHE أيضًا السرية إلى الأمام، حيث أنَّه لن يتم اختراق مفتاح الجلسة، في حال تمَّ الحصول على أحد المفاتيح الخاصة في المستقبل، على الرغم من أن إنشاء رقم عشوائي ضعيف أو استخدام نطاق محدود من الأرقام الأولية قد تم افتراضه للسماح بتكسير حتى مفاتيح DH ذات 1024 بايت مع توفير موارد الحوسبة على مستوى الدولة. ومع ذلك، يمكن اعتبار هذه المشكلات تنفيذًا بدلاً من مشكلات البروتوكول، وهناك أدوات متاحة لاختبار مجموعات التشفير الأضعف.
باستخدام TLS، من المستحسن أيضًا أن يكون العميل المتصل بالخادم قادرًا على التحقق من ملكية المفتاح العام للخادم. يتم ذلك عادةً باستخدام شهادة رقمية X.509 صادرة عن جهة خارجية موثوقة تُعرف باسم شهادة القوة (CA) والتي تؤكد صحة المفتاح العام.
في بعض الحالات، قد يستخدم الخادم شهادة موقعة ذاتيًا والتي يجب أن يثق بها العميل بشكل صريح (يجب أن تعرض المتصفحات تحذيرًا عند مصادفة شهادة غير موثوق بها)، لكن قد يكون هذا مقبولاً في الشبكات الخاصة أو من حيث الشهادة الآمنة للتوزيع الممكن. يوصى بشدة باستخدام الشهادات الصادرة عن المراجع المصدقة بشكل عام.
ما هو سر أهمية بروتوكول TLS؟
تاريخياً، تم إرسال البيانات بدون تشفير عبر الإنترنت، وعندما تم البدء في استخدام التشفير، كان يُستخدم عادةً بطريقة مجزأة للمعلومات الحساسة، مثل: كلمات المرور أو تفاصيل الدفع.
في حين تم الاعتراف في عام 1996 (بواسطة RFC 1984) أنَّ نمو الإنترنت يتطلب حماية البيانات الخاصة؛ فقد أصبح من الواضح بشكل متزايد خلال الفترة الفاصلة أنَّ قدرات التنصت والمهاجمين أكبر وأكثر انتشارًا مما كان يُعتقد سابقًا.
نتيجةً لما سبق، أصدر IAB بيانًا في نوفمبر عام 2014 يدعو مصممي البروتوكول والمطورين والمشغلين إلى جعل التشفير هو المعيار لحركة مرور الإنترنت، ممَّا يعني أن يتم جعله سريًا بشكل افتراضي من الأساس.
بدون TLS، يمكن بسهولة الحصول على معلومات حساسة مثل: تسجيلات الدخول وتفاصيل بطاقة الائتمان والتفاصيل الشخصية من قبل الآخرين، لكن يمكن أيضًا مراقبة عادات التصفح ومراسلات البريد الإلكتروني والمحادثات عبر الإنترنت ومكالمات الاجتماعات.، وذلك من خلال تمكين تطبيقات العميل والخادم لدعم TLS؛ فإنه يضمن أن البيانات المنقولة بينهما مشفرة بخوارزميات آمنة وغير قابلة للعرض من قبل أطراف أخرى.
تدعم الإصدارات الحديثة من جميع متصفحات الويب الرئيسية حاليًا بروتوكول TLS، ومن الشائع بشكل متزايد أن تدعم خوادم الويب بروتوكول TLS افتراضيًا. ومع ذلك، لا يزال استخدام TLS للبريد الإلكتروني وبعض التطبيقات الأخرى غير إلزامي في كثير من الأحيان، وعلى عكس متصفحات الويب التي توفر أدلة مرئية، حيث لا يتضح دائمًا للمستخدمين ما إذا كانت اتصالاتهم مشفرة أم لا.
لذلك يوصى بأن يصر جميع العملاء والخوادم على الاستخدام الإلزامي لـ TLS في اتصالاتهم، ويفضل أن يكون أحدث إصدار TLS 1.2. للحصول على أمان كامل، ومن الضروري استخدامه جنبًا إلى جنب مع البنية التحتية للمفتاح العام (PKI) X.509 الموثوق به بشكل عام ويفضل DNSSEC أيضًا من أجل المصادقة على أن النظام الذي يتم الاتصال به هو بالفعل ما تدعي أنه يكون.
ما هي الخدمات التي يقدمها TLS للمواقع؟
تم تصميم بروتوكول TLS لتوفير ثلاث خدمات أساسية لجميع التطبيقات التي تعمل فوقها، مثال: التشفير والمصادقة وتكامل البيانات. من الناحية الفنية، لا يلزمك استخدام الثلاثة في كل موقف.
قد تقرر قبول شهادة دون التحقق من صحتها، ولكن يجب أن تكون على دراية جيدة بمخاطر الأمان والآثار المترتبة على القيام بذلك. من الناحية العملية، سيعمل تطبيق الويب الآمن على الاستفادة من جميع الخدمات الثلاث، والتي تشمل، ما يلي:
- التشفير: آلية للتعتيم على ما يتم إرساله من مضيف إلى آخر.
- المصادقة: آلية للتحقق من صحة مواد التعريف المقدمة.
- النزاهة: آلية لكشف التلاعب والتزوير في الرسائل.
من أجل إنشاء قناة بيانات آمنة مشفرة، يجب أن يتفق أقران الاتصال على مجموعات التشفير التي سيتم استخدامها والمفاتيح المستخدمة لتشفير البيانات.
يحدد بروتوكول TLS تسلسل مصافحة محدد جيدًا لإجراء هذا التبادل، والذي سنقوم بفحصه بالتفصيل في TLS Handshake. يرجع الجزء المبتكر من هذه المصافحة، وسبب عمل TLS عمليًا، إلى استخدامه لتشفير المفتاح العام (المعروف أيضًا باسم تشفير المفتاح غير المتماثل)، والذي يسمح للأقران بالتفاوض على مفتاح سري مشترك دون الحاجة إلى إنشاء أي معرفة مسبقة لبعضهم البعض، والقيام بذلك عبر قناة غير مشفرة.
كجزء من TLS، يسمح البروتوكول أيضًا لكل الزملاء بمصادقة هويتهم. عند استخدامها في المتصفح، تتيح آلية المصادقة هذه للعميل، التحقق من أنَّ الخادم هو الشخص الذي يدعي أنه صاحب العلاقة (على سبيل المثال، البنك الذي تتعامل معه) وليس شخصًا يتظاهر ببساطة بأنه الوجهة عن طريق انتحال اسمه أو عنوان IP الخاص به.
يعتمد هذا التحقق على سلسلة الثقة المعمول بها - راجع سلسلة الثقة والمراجع المصدقة. بالإضافة إلى ذلك، يمكن للخادم أيضًا التحقق اختياريًا من هوية العميل - على سبيل المثال، يمكن لخادم وكيل الشركة المصادقة على جميع الموظفين، ويمكن أن يكون لكل منهم شهادة فريدة موقعة من الشركة.
أخيرًا، مع التشفير والمصادقة في مكانهما الصحيح، يوفر بروتوكول TLS أيضًا آلية تأطير الرسائل الخاصة به ويوقع كل رسالة برمز مصادقة الرسالة (MAC). خوارزمية MAC هي وظيفة تجزئة تشفير أحادية الاتجاه (بشكل فعال مجموع اختباري)، حيث يتم التفاوض على المفاتيح من قبل جميع نظراء الاتصال.
عندما يتم إرسال سجل TLS، يتم إنشاء قيمة MAC وإلحاقها بهذه الرسالة، ويمكن للمستقبل بعد ذلك حساب قيمة MAC المرسلة والتحقق منها لضمان سلامة الرسالة ومصداقيتها.
تعمل الآليات الثلاث مجتمعة كأساس للاتصال الآمن على الويب. توفر جميع متصفحات الويب الحديثة دعمًا لمجموعة متنوعة من مجموعات التشفير، وهي قادرة على مصادقة كل من العميل والخادم، وإجراء فحوصات سلامة الرسائل بشفافية لكل سجل.
ما هي شهادة القوة (CA) وكيف يتم التحقق من صحة الشهادات؟
شهادة القوة (Certificate Authority) هو كيان يُصدر الشهادات الرقمية المطابقة لمعيار ITU-T X.509 للبنى التحتية للمفاتيح العمومية (PKI). تصدق الشهادات الرقمية على المفتاح العام لمالك الشهادة (المعروف باسم الموضوع)، وأن المالك يتحكم في المجال الذي يتم تأمينه بواسطة الشهادة. لذلك، تعمل شهادة القوة (CA) كطرف ثالث موثوق به يمنح العملاء (المعروفين باسم الأطراف المعتمدة) ضمانًا بأنهم متصلون بخادم يتم تشغيله بواسطة كيان معتمد.
يتم التحقق من صحة شهادات الكيان النهائي من خلال سلسلة ثقة تنشأ من شهادة جذر، تُعرف أيضًا باسم مرساة الثقة. باستخدام التشفير غير المتماثل، من الممكن استخدام المفتاح الخاص للشهادة الجذر لتوقيع الشهادات الأخرى، والتي يمكن التحقق من صحتها باستخدام المفتاح العام لشهادة الجذر وبالتالي ترث ثقة شهادة القوة المُصدر.
من الناحية العملية، عادةً ما يتم توقيع شهادات الكيان النهائي بواسطة واحدة أو أكثر من الشهادات الوسيطة (تُعرف أحيانًا باسم الشهادات الثانوية أو المراجع المصدقة الفرعية)، لأنَّ هذا يحمي شهادة الجذر في حالة إصدار شهادة الكيان النهائي بشكل غير صحيح أو اختراقها.
في معظم الأحيان يتم إنشاء الثقة في الشهادة الأساسية من خلال التوزيع المادي لشهادات الجذر في أنظمة التشغيل أو المتصفحات.
يتم تشغيل برامج الشهادات الرئيسية بواسطة Microsoft (Windows وWindows Phone) وApple (OSX وiOS) وMozilla (Firefox وLinux)، وتتطلب CAs للتوافق مع المتطلبات الفنية الصارمة وإكمال WebTrust، ETSI EN 319411-3 (سابقًا) TS 102 042 أو تدقيق ISO 21188: 2006 لإدراجها في توزيعاتها.
WebTrust هو برنامج تم تطويره بواسطة المعهد الأمريكي للمحاسبين القانونيين المعتمدين والمعهد الكندي للمحاسبين القانونيين، ETSI هو المعهد الأوروبي لمعايير الاتصالات، بينما ISO هي منظمة المعايير الدولية.
يُقال إنَّ الشهادات الأساسية الموزعة مع أنظمة التشغيل والمتصفحات الرئيسية موثوقة بشكل عام أو عالمي، وتعني المتطلبات الفنية والتدقيق أساسًا أنَّ CA المُصدِرة هي شركات أو حكومات متعددة الجنسيات.
يوجد حاليًا حوالي خمسين مرجعًا مصدقًا موثوقًا به بشكل عام، على الرغم من أن معظم/جميعهم لديهم أكثر من شهادة جذر واحدة، ومعظمهم أيضًا أعضاء في منتدى CA/Browser الذي يطور إرشادات الصناعة لإصدار الشهادات وإدارتها. مع ذلك، من الممكن أيضًا إنشاء مراجع مصدقة خاصة وإنشاء الثقة من خلال التوزيع الآمن للشهادات الجذرية وتثبيتها على أنظمة العميل.
تتضمن الأمثلة RPKI CAs التي تديرها سجلات الإنترنت الإقليمية (AfriNIC وAPNIC وARIN وLACNIC وRIPE NCC) التي تصدر شهادات لسجلات الإنترنت المحلية، وتشهد على عناوين IP وأرقام AS التي يمتلكونها؛ بالإضافة إلى الاتحاد الدولي لصناديق الشبكة (IGTF) الذي يوفر مرساة ثقة لإصدار شهادات الخادم والعميل التي تستخدمها الأجهزة في الحوسبة العلمية الموزعة. في هذه الحالات، يمكن تحميل الشهادات الجذرية وتثبيتها بأمان من المواقع، باستخدام شهادة صادرة عن مرجع مصدق موثوق به بشكل عام.
تتمثل إحدى نقاط الضعف في نظام X.509 PKI في أن الأطراف الثالثة (CAs) قادرة على إصدار شهادات لأي مجال، سواء كان الكيان الطالب يمتلكه بالفعل أو يتحكم به.
يتم إجراء التحقق عادةً من خلال التحقق من صحة المجال - أي إرسال بريد إلكتروني مع رابط المصادقة إلى عنوان معروف بأنه مسؤول إداريًا عن المجال.
من المحتمل أنْ هذا أحد عناوين الاتصال القياسية مثل "hostmaster @ domain" أو جهة الاتصال الفنية المدرجة في قاعدة بيانات WHOIS، ولكن هذا يترك المجال مفتوحًا لهجمات man-in-the-middle على DNS أو بروتوكولات BGP، أو ببساطة أكثر، المستخدمون يسجلون عناوين إدارية على المجالات التي لم يتم حجزها. ربما الأهم من ذلك، أنَّ شهادات التحقق من صحة المجال (DV) لا تؤكد أن المجال له أي علاقة بكيان قانوني، على الرغم من أنَّه قد يبدو أن المجال له علاقة.
نتيجةً لذلك، تشجع المراجع المصدقة بشكل متزايد على استخدام شهادات التحقق من صحة المنظمة (OV) والمصادقة الموسعة (EV). مع شهادات OV، يخضع الكيان الطالب لفحوصات إضافية مثل تأكيد اسم المنظمة والعنوان ورقم الهاتف باستخدام قواعد البيانات العامة.
أمَّا مع شهادات EV، هناك فحوصات إضافية على المنشأة القانونية، والموقع المادي، وهوية الأفراد الذين يزعمون أنَّهم يعملون نيابة عن الكيان الطالب. تَعرض المستعرضات عادةً اسم المؤسسة المصادق عليه باللون الأخضر عند مصادفة شهادة EV صالحة، على الرغم من عدم وجود طريقة سهلة لتمييز OV عن شهادة DV.
بالطبع، لا يزال هذا لا يمنع المراجع المصدقة من إصدار شهادات غير صحيحة عن طريق الخطأ أو عن طريق الاحتيال، كما كانت هناك حوادث خرق أمني، حيث تم خداع المراجع المصدقة لإصدار شهادات مزيفة.
على الرغم من التشديد الكبير للإجراءات الأمنية في أعقاب العديد من الحوادث البارزة، لا يزال النظام يعتمد على ثقة الطرف الثالث، ممَّا أدى إلى تطوير بروتوكول مصادقة الكيانات المسماة (DANE) المستند إلى DNS كما هو محدد في RFCs 6698، 7671 و7672 و7673.
باستخدام DANE، يمكن لمسؤول المجال المصادقة على مفاتيحه العامة عن طريق تخزينها في DNS، أو بدلاً من ذلك تحديد الشهادات التي يجب أن يقبلها العميل. يتطلب ذلك استخدام DNSSEC الذي يؤكد بشكل مشفر صحة سجلات DNS، على الرغم من أن DNSSEC ليس له نشر واسع النطاق حتى الآن وتتطلب المتصفحات الرئيسية حاليًا تثبيت وظيفة إضافية لدعم DANE.
علاوة على ذلك، سيبقى DNSSEC وDANE في حاجة إلى التحقق من صحة أصحاب المجال الذي من المحتمل أن يتم إجراؤه بواسطة سجلات المجال أو المسجلين بدلاً من CAs.
مقارنة سريعة - TLS مقابل SSL
يعد TLS أكثر كفاءة وأمانًا من SSL، لأَنَّه يحتوي على مصادقة أقوى للرسائل وتوليد المواد الأساسية وخوارزميات التشفير الأخرى. على سبيل المثال، يدعم TLS المفاتيح المشتركة مسبقًا وكلمات المرور الآمنة عن بُعد ومفاتيح المنحنيات البيضاوية وKerberos، بينما لا يدعم SSL.
TLS وSSL غير قابلين للتشغيل البيني، لكن TLS يوفر توافقًا مع الإصدارات السابقة للأجهزة القديمة التي لا تزال تستخدم SSL.
تحدد مواصفات بروتوكول TLS طبقتين. يوفر بروتوكول سجل TLS أمان الاتصال، ويمكّن بروتوكول مصافحة TLS العميل والخادم من مصادقة بعضهما البعض والتفاوض على مفاتيح الأمان قبل إرسال أي بيانات.
مصافحة TLS هي عملية متعددة الخطوات. تتضمن مصافحة TLS الأساسية أن يرسل العميل والخادم رسائل "مرحبًا" ، وتبادل المفاتيح ورسالة التشفير ورسالة النهاية. العملية متعددة الخطوات هذا ما يجعل TLS مرنًا بدرجة كافية لاستخدامه في تطبيقات مختلفة لأنه يمكن تعديل تنسيق وترتيب التبادل.
العلاقة بين - TLS وUDP
يتطلب TLS وسيلة نقل موثوقة. على الإنترنت، يترك هذا TCP فقط، حيث لا يوفر UDP الموثوقية. لا يتطلب TLS نقلًا موثوقًا لأنَّه (وفقًا لمعمارية الطبقات للنموذج المرجعي ISO/OSI) لا يعالج أخطاء النقل أو الحزم المفقودة أو الاضطرابات الأخرى التي قد تحدث مع IP.
تم تصميم TLS لتقديم قناة آمنة فوق وسيلة نقل موثوقة، وهي تقوم بذلك بشكل جيد. يقوم DTLS بمعالجة الأخطاء الضرورية داخل البروتوكول. وإذا كان من المقرر تنفيذ TLS عبر UDP، فقد تفشل الاتصالات والمصافحة لمجرد فقدان حزمة أثناء النقل ولم يلاحظها أحد.
إن التخفيف من مثل هذه المشكلات (وفقًا للنموذج المرجعي ISO/OSI) هو المهمة المحددة للنقل الموثوق. يعمل أي نقل موثوق به نظريًا، ولكن بالنسبة لجميع الأغراض العملية لشبكات IP، فهذا يعني عادةً TCP.
وهكذا نكون قد تحدثنا عن بروتوكول TLS وأهم مميزاته وعلاقاته مع باقي البروتوكولات والتي تحقق تناغمًا قياسيًا يجعل تحقيق أمن الموقع أمرًا لا مفر منه.