بروتوكول نقل النص التشعبي الآمن

بروتوكول نقل النص التشعبي الآمن ( S-HTTP ) هو بديل قديم لبروتوكول HTTPS لتشفير الاتصالات عبر الإنترنت. طُوِّر هذا البروتوكول بواسطة إريك ريسكورلا وآلان إم. شيفمان في شركة Enterprise Integration Technologies عام 1994 [ ^{1 ] ونُشر} عام 1999 تحت مسمى RFC 2660. وقد أدى هيمنة نتسكيب على سوق المتصفحات إلى جعل HTTPS الطريقة المُعتمدة لتأمين الاتصالات عبر الإنترنت. 

يقوم بروتوكول S-HTTP بتشفير بيانات الصفحة المُقدَّمة والبيانات المُرسَلة فقط، مثل حقول POST، دون تغيير في بدء البروتوكول. ولهذا السبب، يُمكن استخدام S-HTTP بالتزامن مع HTTP (غير المُشفَّر) على نفس المنفذ، حيث يُحدِّد رأس الطلب غير المُشفَّر ما إذا كانت بقية البيانات المُرسَلة مُشفَّرة أم لا.

في المقابل، يغلّف بروتوكول HTTP عبر TLS كامل عملية الاتصال ضمن بروتوكول أمان طبقة النقل (TLS؛ المعروف سابقًا باسم SSL)، لذا يبدأ التشفير قبل إرسال أي بيانات بروتوكول. وهذا يُنشئ معضلة "البيضة والدجاجة" في مجال الاستضافة الافتراضية القائمة على الأسماء، حيث يصعب تحديد اسم نظام أسماء النطاقات (DNS) المقصود للطلب.

وهذا يعني أن تطبيقات HTTPS بدون دعم Server Name Indication (SNI) تتطلب عنوان IP منفصل لكل اسم DNS، وجميع تطبيقات HTTPS تتطلب منفذًا منفصلاً (عادةً 443 مقابل 80 القياسي لـ HTTP) ^{[ 2 ]} للاستخدام الواضح للتشفير (يتم التعامل معه في معظم المتصفحات كمخطط URI منفصل ، https:// ).

كما هو موثق في RFC 2817 ، يمكن تأمين بروتوكول HTTP أيضًا بتطبيق رؤوس ترقية HTTP/1.1 والترقية إلى TLS. لا يترتب على تشغيل HTTP عبر TLS المُتفاوض عليه بهذه الطريقة أي آثار لبروتوكول HTTPS فيما يتعلق بالاستضافة الافتراضية القائمة على الأسماء (لا عناوين IP أو منافذ أو مساحة URI إضافية). مع ذلك، لا تدعم سوى تطبيقات قليلة هذه الطريقة. 

في بروتوكول S-HTTP، لا يُرسل عنوان URL المطلوب ضمن ترويسة النص الواضح، بل يُترك فارغًا؛ وتوجد مجموعة أخرى من الترويسات داخل الحمولة المشفرة. أما في بروتوكول HTTP عبر TLS، فتكون جميع الترويسات داخل الحمولة المشفرة، ولا تتاح لتطبيق الخادم عادةً فرصة التعافي بسلاسة من أخطاء TLS الفادحة (بما في ذلك "شهادة العميل غير موثوقة" و"شهادة العميل منتهية الصلاحية"). ^{[ 2 ]}

• RFC 2660 بروتوكول نقل النص التشعبي الآمن