على مدار أكثر من ثلاثة عقود، قامت بروتوكولات SSL و TLS بحماية مليارات المعاملات عبر الإنترنت. ما بدأ كمشروع أمان طموح ل Netscape في عام 1994 تطور إلى معايير التشفير المتطورة اليوم. يمتد تاريخ بروتوكول SSL هذا إلى ستة إصدارات رئيسية من البروتوكول، وتحسينات أمنية لا حصر لها، وتحول أساسي في طريقة تفكيرنا في أمن الويب.
إن فهم إصدارات SSL/TLS لا يتعلق فقط بمعرفة البروتوكولات التي تم إهمالها. بل يتعلق بالتعرف على كيفية تشكيل كل ثغرة وهجوم واختراق للمشهد الحالي حيث يؤمن TLS 1.3 95% من حركة مرور الويب المشفرة.
جدول المحتويات
- مولد بروتوكول SSL في نتسكيب
- SSL 3.0 – إعادة تصميم البروتوكول بالكامل
- TLS 1.0 – عصر التوحيد القياسي لمنتدى معايير IETF
- TLS 1.1 و TLS 1.2 – التحسينات الأمنية الإضافية
- TLS 1.3 – معيار الأمان الحديث TLS 1.3
- المفاهيم الخاطئة الشائعة حول إصدار SSL/TLS
- دور المراجع المصدقة في تطور SSL/TLS
- معالم الصناعة التي شكّلت اعتماد HTTPS
- الثغرات الأمنية الرئيسية التي أدت إلى تطور البروتوكول
- مستقبل بروتوكولات SSL/TLS
وفر 10% على شهادات SSL عند الطلب من SSL Dragon اليوم!
إصدار سريع، وتشفير قوي، وثقة في المتصفح بنسبة 99.99%، ودعم مخصص، وضمان استرداد المال خلال 25 يومًا. رمز القسيمة: SAVE10
مولد بروتوكول SSL في نتسكيب
SSL 1.0 – المحاولة الأولى التي لم يتم إصدارها (1994)
قام طاهر الجمل، كبير علماء نتسكيب، بتصميم طبقة مآخذ التوصيل الآمنة الأصلية في عام 1994. لكن SSL 1.0 لم ير النور أبدًا. اكتشف الباحثون الأمنيون في نتسكيب ثغرات خطيرة قبل الإصدار العام، وهي ثغرات خطيرة بما يكفي لإلغاء الإصدار بأكمله.
كان الدرس واضحًا: تحتاج بروتوكولات التشفير إلى مراجعة شاملة قبل نشرها. وعلى الرغم من أن هذه الانتكاسة كانت محبطة، إلا أنها أسست لنمط من الاختبارات الصارمة التي ستحدد تطوير SSL و TLS في المستقبل.
SSL 2.0 – الإصدار العام الأول (1995)
متى ظهر SSL؟ الجواب هو فبراير 1995، عندما قامت نتسكيب بتجميع SSL 2.0 مع نافيجيتور 1.1. قدم هذا الإصدار من SSL مفاهيم أساسية لا تزال مستخدمة حتى اليوم: مصافحة مصافحة SSLوشهاداتX.509 الرقمية ومصادقة الخادم.
لكن SSL 2.0 كان لديه مشاكل. فقد اعتمدت على MD5 لمصادقة الرسائل، واستخدمت نفس المفتاح للتشفير والمصادقة، وافتقرت إلى حماية المصافحة نفسها. يمكن للمهاجمين خفض مستوى الاتصالات إلى تشفير أضعف من 40 بت دون أن يلاحظ أي من الطرفين.
قام IETF بإلغاء SSL 2.0 رسميًا في مارس 2011 من خلال RFC 6176. بحلول ذلك الوقت، كانت معظم الخوادم قد انتقلت بالفعل.
SSL 3.0 – إعادة تصميم البروتوكول بالكامل
التحسينات الرئيسية على SSL 2.0 (1996)
أعاد كل من بول كوشر وفيل كارلتون وآلان فراير كتابة بروتوكول SSL بالكامل للإصدار 3.0، الذي صدر في نوفمبر 1996. وفصلوا طبقة نقل البيانات عن طبقة الرسائل، وأضافوا دعمًا لتبادل مفاتيح Diffie-Hellman ومجموعات شفرات Fortezza، وطبقوا مفتاح 128 بت المناسب.
كما قدم SSL 3.0 أيضًا ضغط السجلات وتفاوضًا أكثر مرونة بشأن مجموعة الشفرات. قام IETF لاحقًا بتوثيقها في RFC 6101 إدراكًا لأهميتها التاريخية. على مدى عقدين تقريبًا، كان SSL 3.0 بمثابة خيار احتياطي للأنظمة القديمة.
ثغرة POODLE وإهمال SSL 3.0 SSL 3.0
في أكتوبر 2014، اكتشف فريق الأمن في جوجل بودل (حشوة أوراكل على التشفير القديم المتدرج). استغل الهجوم كيفية تعامل SSL 3.0 مع حشوة وضع تسلسل كتلة التشفير (CBC). يمكن للمهاجمين فك تشفير ملفات تعريف ارتباط HTTP الآمنة عن طريق إجبار المتصفحات على خفض مستوى التشفير من TLS إلى SSL 3.0.
استجابت IETF بسرعة، حيث استبعدت SSL 3.0 في يونيو 2015 عبر RFC 7568. كان هذا بمثابة نهاية عصر SSL. عندما يسأل الناس عن“أحدث إصدار من SSL،” فإن الإجابة هي SSL 3.0، لأن SSL نفسه لم يتم تحديثه مرة أخرى. انتقلت الشعلة إلى أمن طبقة النقل.
TLS 1.0 – عصر التوحيد القياسي لمنتدى معايير IETF
الانتقال من SSL إلى TLS (1999)
بحلول أواخر التسعينيات، أراد المنتدى الدولي للاتصالات السلكية واللاسلكية IETF توحيد بروتوكولات أمن الإنترنت. قاد تيم ديركس وكريستوفر ألين الجهود لتحويل SSL إلى معيار مفتوح. تفاوضت مايكروسوفت ونيتسكيب على التسمية – وكان الحل الوسط الذي تم التوصل إليه هوأمن طبقة النقل.
كان TLS 1.0، الذي نُشر على أنه RFC 2246 في يناير 1999، في الأساس SSL 3.1 باسم جديد. كانت الاختلافات طفيفة لكنها كانت ذات مغزى بما يكفي لكسر التوافق. لم يكن بإمكانك مزج عملاء SSL 3.0 مع خوادم TLS 1.0 دون تنفيذ دقيق.
الاختلافات الرئيسية عن SSL 3.0
قام TLS 1.0 بترقية التشفير الأساسي. فقد استبدل رمز مصادقة الرسائل المخصص (MAC) الخاص ب SSL برمز مصادقة الرسائل ( HMAC)، وهو رمز موحد من قبل خبراء التشفير. تغيرت وظيفة اشتقاق المفتاح لمنع بعض الهجمات النظرية. تم توسيع نظام التنبيه برموز أخطاء أكثر تحديدًا.
كما تطلب TLS 1.0 أيضًا دعم مجموعات شفرات DSS/DH، مما يمنح التطبيقات مزيدًا من المرونة. بدت هذه التغييرات صغيرة، لكنها عكست تحولاً من التطوير الاحتكاري إلى التوحيد القياسي الذي يحركه المجتمع. يتحكم منتدى IETF الآن في تطور البروتوكول.
TLS 1.1 و TLS 1.2 – التحسينات الأمنية الإضافية
حماية TLS 1.1 من هجمات CBC (2006)
تم إصدار TLS 1.1.1 في أبريل 2006 من خلال RFC 4346، وقد عالجت TLS 1.1 ثغرات CBC محددة. التغيير الأكبر؟ استبدال نواقل التهيئة الصريحة (IVs) بنواقل التهيئة الضمنية. وقد منع ذلك المهاجمين من التنبؤ بـ IV واستغلال تسلسل كتلة التشفير.
حسّن TLS 1.1 أيضًا معالجة الأخطاء في السجلات المبطنة. فبدلًا من الكشف عن أخطاء الحشو المحددة، أرجع تنبيهًا عامًّا لـ bad_record_mac. أدت هذه التغييرات إلى الحماية من BEAST (استغلال المتصفح ضد SSL/TLS)، الذي تم اكتشافه بعد سنوات في عام 2011.
تم إنشاء سجلات معلمات IANA، مما جعل إدارة مجموعة الشفرات أكثر تنظيماً. لكن الاعتماد كان بطيئًا. فقد تخطت العديد من المؤسسات TLS 1.1 بالكامل، في انتظار التحسينات الجوهرية التي أدخلت على TLS 1.2.
TLS 1.2 المرونة المعززة (2008)
متى تم إصدار TLS 1.2؟ أغسطس 2008، عبر RFC 5246. جلب هذا التحديث أهم التغييرات منذ إصدار SSL 3.0. تحول البروتوكول من مجموعات MD5/HA-1 المشفرة إلى الدوال العشوائية الكاذبة (PRFs) المحددة من قبل الشفرات. SHA-256 أصبحت المعيار الجديد.
قدّمت TLS 1.2 أنماط تشفير مصادق عليها مع بيانات إضافية (AEAD)، بما في ذلك AES-GCM و ChaCha20-Poly1305. أعطى مرونة في اختيار خوارزميات التجزئة والتوقيع. أثبتت هذه المرونة أهميتها البالغة مع تطور معايير التشفير.
لا يزال البروتوكول منتشرًا على نطاق واسع اليوم. لا تزال حوالي 95.8% من المواقع الإلكترونية تدعم بروتوكول TLS 1.2، وغالبًا ما تعمل جنبًا إلى جنب مع TLS 1.3. في مارس 2021، قام منتدى IETF بإهمال بروتوكولي TLS 1.0 و1.1 من خلال RFC 8996، مما يجعل TLS 1.2 هو الحد الأدنى المقبول من المعايير.
وفر 10% على شهادات SSL عند الطلب من SSL Dragon اليوم!
إصدار سريع، وتشفير قوي، وثقة في المتصفح بنسبة 99.99%، ودعم مخصص، وضمان استرداد المال خلال 25 يومًا. رمز القسيمة: SAVE10
TLS 1.3 – معيار الأمان الحديث TLS 1.3
خمس سنوات من التطوير (2018)
استغرق الوصول إلى TLS 1.3 عقدًا من الزمن. نشر منتدى IETF RFC 8446 في أغسطس 2018 بعد 28 مسودة وتعاون مكثف. كان الدافع وراء إعادة التصميم هو البساطة والأداء. قامت مجموعة العمل بإزالة الميزات القديمة وتبسيط المصافحة وإزالة فئات كاملة من الثغرات الأمنية.
وسرعان ما أضافت جوجل وموزيلا ومايكروسوفت وأبل الدعم بسرعة. بحلول عام 2019، أصبح بإمكان جميع المتصفحات الرئيسية التفاوض على اتصالات TLS 1.3. قام Cloudflare ومزودو شبكات CDN الآخرون بتمكينه افتراضيًا. لم يعمل أحدث إصدار من TLS على تحسين الأمان فحسب، بل جعل الاتصالات المشفرة أسرع.
التحسينات الأمنية الثورية
أزال TLS 1.3 كل ما تم كسره أو إضعافه. مجموعات تشفير SHA-1 و MD5 و RC4 و DES و 3DES؟ اختفت. تبادل مفاتيح RSA وDiffie-Hellman الثابتة؟ تم التخلص منها. يتطلب البروتوكول الآن السرية التامة للأمام باستخدام مفتاح D iffie-Hellman سريع الزوال لجميع الاتصالات.
تغيرت المصافحة بشكل أساسي. يتم تشفير كل رسالة بعد ServerHello، مما يخفي التفاوض عن أعين المتطفلين. تحولت وظيفة اشتقاق المفتاح إلى الاستخراج والتوسيع المستند إلى HMAC (HKDF)، مما يوفر ضمانات تشفير أفضل.
كما قدم TLS 1.3 أيضًا وضع 0-RTT (زمن انتقال صفر). يمكن للعملاء إرسال البيانات المشفرة في الرسالة الأولى إلى الخوادم التي تم الاتصال بها مسبقًا، مما يلغي زمن انتقال المصافحة. جعلت آلة الحالة المبسطة عمليات التنفيذ أقل عرضة للأخطاء. انتقلت ECC إلى المواصفات الأساسية مع خوارزميات توقيع جديدة مثل RSA-PSS.
التبني الحالي والتعايش
ما هو أحدث إصدار من TLS؟ يحمل TLS 1.3 هذا اللقب. لكن TLS 1.2 لن يذهب إلى أي مكان قريبًا. تحتاج المؤسسات إلى وقت لترقية الخوادم واختبار التوافق وتحديث برامج العميل. تدعم معظم المواقع المهتمة بالأمان الآن كلا الإصدارين، مما يتيح للعملاء اختيار أفضل خيار متاح.
يعمل التعايش بشكل جيد. تتفاوض الخوادم على أعلى إصدار مدعوم بشكل متبادل. يعود العملاء الذين لا يستطيعون التعامل مع TLS 1.3 إلى TLS 1.2. يمنع نهج الترحيل التدريجي هذا كوارث التوافق التي ابتليت بها عمليات الانتقال السابقة.
المفاهيم الخاطئة الشائعة حول إصدار SSL/TLS
سبب عدم وجود TLS 2.0
ما هو تاريخ إصدار TLS 2.0؟ لا توجد واحدة. TLS 2.0 غير موجود ولن يكون موجودًا أبدًا. يستخدم IETF الإصدار التدريجي: TLS 1.0، 1.1، 1.1، 1.2، 1.3. سيكون الإصدار التالي، إذا جاء، هو TLS 1.4 أو ربما TLS 2.0، ولكن التخطي مباشرةً إلى “TLS 2.0” بعد SSL 3.0 كان سيتسبب في ارتباك كبير.
غالباً ما يتوقع الناس أن تستخدم البروتوكولات أرقام إصدارات رئيسية (مثل البرمجيات التي تقفز من الإصدار 1 إلى الإصدار 2). لكن بروتوكولات التشفير تتطور بشكل أكثر تحفظًا، حيث يعتمد كل إصدار على الإصدار السابق.
مصطلحات SSL مقابل TLS
اطلب “شهادة SSL” وستحصل على شهادة تعمل مع TLS 1.2 وTLS 1.3. لا تزال الصناعة تستخدم “SSL” في التسويق لأنها مألوفة. على الرغم من أن الإصدار الحالي من SSL غير موجود من الناحية الفنية (انتهت SSL في الإصدار 3.0)، إلا أن المصطلح عالق.
تبيع المراجع المصدقة مثل DigiCert وSectigo “شهادات SSL” التي تستخدم بروتوكولات TLS حصرياً. إنه أمر مربك ولكنه غير ضار. فقط تذكر: عندما يذكر شخص ما SSL في عام 2026، فمن شبه المؤكد أنه يعني TLS.
دور المراجع المصدقة في تطور SSL/TLS
تطوير أنواع التحقق من الصحة
كانت شهادات SSL المبكرة باهظة الثمن وبطيئة. التحقق من صحة الأعمال تتطلب أيامًا أو أسابيع من التحقق اليدوي. في عام 2002، قدمت GeoTrust التحقق من صحة النطاقأتمتة العملية عن طريق التحقق من ملكية النطاق من خلال البريد الإلكتروني أو سجلات DNS.
ظهرت شهاداتالمصادقة الموسّعة في عام 2007، واعدةً بأعلى درجات الضمان من خلال أشرطة العناوين الخضراء في المتصفحات. تم إطلاق Let’s Encrypt في عام 2015، حيث قدمت شهادات مجانية للتحقق من صحة النطاق من خلال الإصدار التلقائي. تبعتها Cloudflare ببرنامج الشهادات المجاني الخاص بها. أدت هذه التغييرات إلى إضفاء الطابع الديمقراطي على HTTPSمما جعل التشفير متاحًا للمواقع الإلكترونية الصغيرة.
تخفيض فترة صلاحية الشهادة
استمرت فترات صلاحية الشهادات في التقلص. خفضت المتطلبات الأساسية الحد الأقصى للصلاحية من خمس سنوات إلى ثلاث سنوات في عام 2015. وأصبحت سنتان هي الحد الأقصى في عام 2018. فرض متصفح Safari من Apple عام واحد كحد أقصى في عام 2020، مما أجبر المتصفحات الأخرى على اتباعه.
والآن، تدفع الصناعة نحو دورات حياة أقصر للشهادات. وقد حدد منتدى المرجع المصدق/المتصفح CA/المتصفح تخفيضًا واضحًا في فترات صلاحية الشهادات: 200 يوم ابتداءً من 15 مارس 2026،و100 يوم ابتداءً من 15 مارس 2027، و47 يومًا فقط بحلول 15 مارس 2029.
هذا التحول يجعل الإدارة اليدوية للشهادات غير عملية، مما يدفع المؤسسات نحو الحلول الآلية مثل الشهادة كخدمة (CaaS) القائمة على ACME، حيث يتم التعامل مع عمليات التحقق من الصحة والإصدار والتجديد تلقائيًا.
معالم الصناعة التي شكّلت اعتماد HTTPS
دفع HTTPS من جوجل
في أغسطس 2014، أعلنت Google عن HTTPS كإشارة تصنيف. غيّر هذا القرار الوحيد تاريخ SSL. أصبح لدى مشرفي المواقع الإلكترونية الذين تجاهلوا التشفير فجأة أسباب تجارية للاهتمام. بحلول عام 2016، كانت نصف حركة مرور الإنترنت مشفرة.
اتخذ كروم 68 الخطوة التالية في يوليو 2018، حيث وضع علامة على جميع مواقع HTTP على أنها “غير آمنة.” ظهر التحذير في شريط العناوين لكل صفحة غير مشفرة. اليوم، أكثر من 95% من حركة مرور الويب تستخدم HTTPS. حوَّلت Google التشفير من أفضل الممارسات الأمنية إلى مطلب تجاري.
تطور مؤشرات أمان المتصفح
هل تتذكر شريط العنوان الأخضر الخاص بالتحقق الموسع؟ لقد اختفى. أزاله كروم في 2020 بعد أن أظهرت الأبحاث أن المستخدمين لم يلاحظوه أو يفهموه. اختفت أيقونة القفل نفسها، واستُبدلت بمؤشرات محايدة تعمل على تطبيع HTTPS بدلاً من مكافأتها.
أزال Chrome 69 نص “آمن” تاركًا القفل فقط. تركز المتصفحات الحالية على التحذير من الاتصالات غير الآمنة بدلاً من الإشادة بالاتصالات الآمنة. الرسالة: HTTPS هو التوقع الافتراضي، وليس شيئًا خاصًا.
الثغرات الأمنية الرئيسية التي أدت إلى تطور البروتوكول
الهجمات البارزة على SSL/TLS
ضرب POODLE نظام SSL 3.0 في عام 2014، مستغلًا ثغرات في حشوة أوراكل في وضع CBC. تمكن المهاجمون من فك تشفير ملفات تعريف الارتباط الآمنة عن طريق خفض مستوى الاتصالات وتعديل النص المشفر بشكل متكرر. قضى الهجوم على SSL 3.0 في غضون أشهر.
استهدف BEAST TLS 1.0 في عام 2011، باستخدام نقطة ضعف CBC مماثلة. يمكن للمهاجمين فك تشفير ملفات تعريف الارتباط HTTPS عن طريق حقن تعليمات برمجية من جانب العميل ومراقبة الاستجابات المشفرة. تطلّب الإصلاح تطبيق رموز IV صريحة في TLS 1.1.
أساءت BREACH استخدام ضغط HTTP في عام 2013. لم يستهدف الهجوم بروتوكول TLS نفسه ولكنه أظهر كيف تؤثر قرارات طبقة التطبيقات على الأمان. كشفت Heartbleed، التي اكتُشفت في عام 2014، عن ثغرة خطيرة في بروتوكول OpenSSL الذي سرّب المفاتيح الخاصة وبيانات المستخدم.
الدروس المستفادة
أثبتت كل ثغرة النقطة نفسها: التوافق مع الإصدارات السابقة أمر خطير. فالإبقاء على البروتوكولات القديمة للأنظمة القديمة يخلق نواقل للهجوم. لقد تعلمت الصناعة إبطال الإهمال بقوة وفرض التحديثات.
يستحق الباحثون في مجال الأمن التقدير أيضاً. أدى الكشف العلني عن الثغرات الأمنية إلى تسريع التحسينات. فبدون POODLE، ربما كان من الممكن أن تظل SSL 3.0 كامنة في تكوينات الخوادم اليوم.
مستقبل بروتوكولات SSL/TLS
تشفير ما بعد الكم
تهدد الحواسيب الكمية خوارزميات التشفير الحالية. يمكن أن يصبح تشفير RSA وتشفير المنحنى الإهليلجي عتيقًا بمجرد أن تحقق الآلات الكمية نطاقًا كافيًا. يقوم المعهد الوطني للمعايير والتكنولوجيا بتوحيد خوارزميات ما بعد الكم المصممة لمقاومة الهجمات الكمية.
ستحتاج TLS إلى تحديثات لدعم هذه الخوارزميات المقاومة للكم. لن يكون الانتقال سهلاً، فتشفير ما بعد الكم يستخدم مفاتيح أكبر وأساليب رياضية مختلفة. لكن تطور البروتوكول الذي أوصلنا من SSL 2.0 إلى TLS 1.3 أثبت أن المجتمع قادر على التعامل مع التحولات الكبرى.
التقنيات الناشئة
يوسع DTLS (أمن طبقة نقل مخطط البيانات) نطاق TLS ليشمل اتصالات UDP. كويكالذي طورته Google وتم توحيده من قبل IETF، يدمج التشفير مباشرةً في طبقة النقل. تعتمد هذه البروتوكولات على أسس تشفير TLS مع التكيف مع حالات الاستخدام المختلفة.
البدائل القائمة على البلوك تشين مثل تجربة Remme مع مرفق المفاتيح العمومية الموزعة. تستمر سلطات الشهادات في التطور، وأتمتة المزيد من العمليات ودعم فترات صلاحية أقصر. ماذا سيحدث بعد TLS 1.3؟ ربما تحسينات تدريجية بدلاً من إعادة تصميم كاملة. لقد حقق TLS 1.3 معظم الأمور بشكل صحيح.
ابقَ على اطلاع دائم بشهادات TLS 1.3 الجاهزة من SSL Dragon
فهم تطور البروتوكول شيء. أما تطبيق معايير التشفير الحديثة فهو شيء آخر. توفر SSL Dragon شهادات رقمية متوافقة تمامًا مع TLS 1.3 وTLS 1.2، وتدعم أحدث بروتوكولات التشفير ومجموعات التشفير.
نحن نقدم إصدارًا سريعًا وتشفيرًا قويًا وثقة في المتصفح بنسبة 99.99% من خلال شراكات مع جهات إصدار الشهادات الرائدة بما في ذلك DigiCert وSectigo وGeoTrust. تساعدك حلول إدارة الشهادات الآلية التي نقدمها على التعامل مع دورات حياة الشهادات القادمة التي تستغرق 47 يوماً دون متاعب التجديد اليدوي.
الانتقال من البروتوكولات المهملة؟ يرشدك فريق الدعم المتخصص لدينا خلال عملية الانتقال. تتضمن كل عملية شراء ضمان استرداد الأموال خلال 25 يوماً. استكشف مجموعة شهاداتنا اليوم وقم بتأمين بنيتك الأساسية باستخدام أحدث إصدار من TLS.
وفِّر 10% على شهادات SSL عند الطلب اليوم!
إصدار سريع، وتشفير قوي، وثقة في المتصفح بنسبة 99.99%، ودعم مخصص، وضمان استرداد المال خلال 25 يومًا. رمز القسيمة: SAVE10
