الخلاصة

  • اقترح RFC 2817 نقل اتصال HTTP/1.1 القائم إلى TLS بواسطة Upgrade، بحيث تتشارك الحركة المكشوفة والمحمية المنفذ 80، ويصل حقل Host قبل اختيار شهادة الخادم.
  • أبقى المعيار https فضاء عناوين مستقلاً، وسجل ضعف الاهتمام باستبدال المنفذ 443 في تصفح الويب المعتاد. ووثق RFC 2818 المسار الذي يبدأ فيه TLS على ذلك المنفذ قبل HTTP.

كان للويب بابان واضحان. عند المنفذ 80 تصل طلبات HTTP العادية. أما عنوان https فيقود، افتراضياً، إلى المنفذ 443؛ تبدأ مصافحة TLS ثم يأتي طلب HTTP داخل القناة المحمية. في ديسمبر 1997، جدد قادة مجال التطبيقات في IETF رغبتهم في إنهاء عادة منح كل بروتوكول جديد منفذاً عادياً وآخر آمناً. بدا اقتراح مايو 2000 جواباً هندسياً لطيفاً: ضع القفل على الباب الموجود.

شرح RFC 2817 كيف ينتقل اتصال TCP واحد من HTTP/1.1 إلى TLS/1.0 عبر Upgrade. كان أمامه سبب آخر غير الاقتصاد في أرقام المنافذ. فالاستضافة الافتراضية القائمة على الاسم سمحت لعناوين ويب عدة بمشاركة عنوان IP واحد؛ يحدد الخادم الموقع المطلوب عندما يقرأ حقل Host في طلب HTTP. وفي المسار الذي يبدأ فيه TLS أولاً، يأتي وقت اختيار الشهادة قبل قراءة ذلك الحقل. بداية HTTP المكشوفة تمنح الخادم الاسم، ثم تبدأ الحماية. يسأل موظف الاستقبال عن صاحب الموعد قبل أن يغلق المدخل.

وضع RFC 2616 Upgrade في علاقة الطرفين المتجاورين على الاتصال. يستطيع العميل إرسال Upgrade: TLS/1.0 مع Connection: Upgrade في طلب عادي إذا كان يقبل جواباً غير محمي. وإذا كان الجواب المكشوف غير مقبول، وجهه RFC 2817 إلى البدء بطلب OPTIONS *. هذه مقدمة تفاوضية تخلو من العملية الحساسة؛ يتأكد العميل بها من استعداد الخادم قبل إرسال ما يحتاج إلى الحماية.

عندما يوافق الخادم، يرد بـ101 Switching Protocols، ويعلن ترتيب TLS/1.0, HTTP/1.1، ثم تبدأ مصافحة TLS فور انتهاء رؤوس الرد. وبعد المصافحة تستمر محادثة HTTP داخل TLS. ويمكن للخادم أن يرسل 426 Upgrade Required لإبلاغ العميل بأن المورد يتطلب انتقالاً محدداً. الرقم 426 طلب للانتقال؛ تنفيذ الانتقال يتطلب تبادل Upgrade نفسه. اللافتة المعلقة على الباب لا تدير المفتاح.

وتتعدد الأبواب عندما يدخل الوكيل الوسيط في الطريق. يعمل Upgrade قفزة واحدة في كل مرة؛ انتقال اتصال العميل بالوكيل لا ينقل اتصال الوكيل بخادم المنشأ تلقائياً. للوصول المحمي إلى الخادم، وصف RFC 2817 إنشاء نفق CONNECT أولاً، حتى إن كان المقصد المنفذ 80. بعد جواب نجاح من فئة 2xx، يستطيع العميل إجراء تفاوض Upgrade مع خادم المنشأ عبر النفق. توحيد المنفذ لا يختصر خريطة الوسطاء.

كانت في شريط العنوان عقدة إضافية. حافظ RFC 2817 على فضاءين منفصلين للعنوانين http:// وhttps://. وفي الشهر نفسه، وصف RFC 2818 مسار https المعتاد: المنفذ 443 افتراضياً، ورسالة TLS ClientHello أولاً، ثم HTTP داخل الاتصال المحمي. يستطيع المهندسون تغيير ترتيب الخطوات عند المدخل؛ أما اسم الوجهة العامة فيظل جزءاً من الاتفاق بين الرابط والمتصفح والقارئ.

لم يخف مؤلفو RFC 2817 استقبال فكرتهم. فقد سجلوا قبولاً واسعاً للمبدأ، واهتماماً ضئيلاً ببديل عن 443 لتصفح الويب العام. ورأوا منفعة محتملة في بروتوكولات جديدة مبنية على HTTP، منها الطباعة عبر الإنترنت. هكذا دخلت عادة الاستخدام اليومية إلى مقدمة وثيقة هندسية. عالج الباب الواحد مشكلة المنافذ المزدوجة، ووقت اختيار شهادة المضيف، وإعلان الحاجة إلى التشفير. لكنه مر أيضاً عبر طلب تمهيدي ووسطاء وعناوين https المنتشرة. طرق TLS الباب 80؛ وكانت الدعوة تحمل الرقم 443.