عمل SSL قبل أن تتوافر له مرجعية مستقرة

الخلاصة

• أعلنت Netscape في ديسمبر 1994 أن SSL جزء من Commerce Server؛ ويذكر تاريخ هندسي لاحق أن Navigator 1.0 دعم SSL 2.0.
• ظل SSL 3.0 مسودة إنترنت منتهية الصلاحية في نوفمبر 1996، ولم تظهر له مرجعية تاريخية مستقرة من IETF إلا مع RFC 6101 في 2011.

أول دليل ليس وثيقة معيارية. ففي ديسمبر 1994 أعلنت Netscape عن Navigator 1.0 وخط خوادم Netsite. وقال بيان الإطلاق المعاصر إن Commerce Server يدمج تقنية Secure Sockets Layer المعتمدة على تقنية RSA Data Security، وقدّم مجموعة العميل والخادم بوصفها صالحة للتجارة عبر الإنترنت. هذا ادعاء تسويقي عند الإطلاق، وليس إحصاءً مستقلاً للتثبيتات. لكنه يضع SSL داخل منتج تجاري عُرض على الجمهور قبل أن يصبح سجل المواصفات مرجعاً ثابتاً.

يضيف تاريخ لاحق لشفرة الأمان في Netscape تفصيلاً لا يظهر في البيان: دعم Navigator 1.0 كان لـSSL 2.0، بينما أضاف Navigator 2.0 دعم SSL 3.0. ويقول المصدر نفسه إن شفرة الأمان نُقلت للاستخدام في خوادم Netscape 2.0. هذه شهادة هندسية من داخل المؤسسة، لا سجل كامل للشحنات؛ لذا تُقرأ إلى جانب إعلان المنتج المؤرخ لا بديلاً عنه.

تُظهر وثائق 1995 انتقال البروتوكول إلى وصف تقني متاح علناً. فـنسخة مؤرشفة تسجل «The SSL Protocol» لكِب هيكمان وطاهر الجمل بوصفها مسودة إنترنت من يونيو 1995. وتشرح نسخة من فبراير محفوظة في أرشيف Mozilla أن SSL طبقة مستقلة عن بروتوكول التطبيق: تفاوض المصافحة على المعلمات التشفيرية وتوثق الخادم قبل تدفق بيانات التطبيق. تصف هذه الوثائق سلوكاً قابلاً للتنفيذ. لكن صفة المسودة لا تجعلها معيار إنترنت معتمداً ولا تضمن توافق جميع التطبيقات.

يكشف SSL 3.0 الفرق بوضوح خاص. يسجل IETF Datatracker الوثيقة draft-ietf-tls-ssl-version3-00 كمسودة إنترنت منتهية الصلاحية، آخر تحديث لها في 21 نوفمبر 1996، ومن دون حالة RFC مقصودة. ويحمل النص تاريخ 18 نوفمبر. وفي 2011 نشر RFC 6101 ذلك الإصدار كسجل تاريخي. ويقول تمهيده إن SSL 3.0 كان واسع التطبيق وأساساً لـTLS، لكنه لم يُنشر رسمياً من IETF إلا عبر مسودات منتهية الصلاحية؛ ولذلك لم يكن له مرجع ثابت سهل الاستشهاد به. أنشأ RFC 6101 مرجعاً تاريخياً ولم يحوّل SSL 3.0 بأثر رجعي إلى مواصفة على مسار المعايير.

لا تعني هذه السلسلة أن SSL افتقر إلى المواصفات، أو أن هيئات المعايير لم تشارك. فكل سجل يجيب عن سؤال مختلف: إعلان المنتج يثبت ما عرضته الشركة؛ وتاريخ الشفرة يذكر ما دعمته عائلة من العملاء؛ والمسودة تتيح فحص البروتوكول وتعديله؛ أما RFC المنشور فيوفر نصاً دائماً للاستشهاد وحالة معلنة. لا يثبت أي مصدر بمفرده انتشاراً شاملاً أو سلوكاً موحداً.

لذلك لا ينبغي اختزال الاعتماد في لحظة واحدة. قد تجذب برمجية عاملة مستخدمين قبل صدور مواصفة مستقرة. وقد تحسن المسودة التوافق من دون أن تثبته. ويمكن لـRFC تاريخي لاحق أن يجعل بروتوكولاً قديماً قابلاً للرجوع إليه من دون أن يوصي بأمانه أو استخدامه الحالي. في حالة SSL، وصل المنتج ونص العمل والمرجع الدائم في أوقات مختلفة.