WRONG_VERSION_NUMBER مع وسيط: تحقّق من HTTP مقابل HTTPS

يقول الخطأ “إصدار خاطئ”، لذا يغري الأمر ببدء تبديل إصدارات TLS. مع وسيط، تحقّق من احتمال أسبق: هل أرسل العميل مصافحة TLS إلى منفذ كان ينتظر HTTP عاديًا؟

وجهة مثل https://example.com/ ووسيط مثل http://proxy.example:8080 زوج عادي. تغيير عنوان URL الثاني إلى HTTPS يخبر العميل بتشفير محادثته مع الوسيط نفسه. وهو ليس تعليمًا بالسماح بمواقع HTTPS.

حدّد أول محادثة TLS

مع وسيط HTTP، يمكن للعميل أن يرسل أولًا CONNECT ويتلقى ردًا بـ HTTP. وبعد ذلك فقط يبدأ TLS الوجهة داخل النفق. ومع وسيط HTTPS، تأتي اتصال TLS منفصل بالوسيط أولًا.

محلل TLS يتلقى صفحة خطأ HTTP أو نصًا عاديًا آخر قد يبلّغ عن خطأ بروتوكول. لا تحدد الصياغة إصدارات TLS التي يدعمها الموقع، ولا حتى أن الموقع جرى الاتصال به.

1. سجّل عنوان URL للوسيط، بما في ذلك مخطّطه، والبروتوكول الموثّق لنقطة النهاية.
2. ابحث عمّا إذا وقع الفشل قبل رد CONNECT، أو أثناء TLS الوجهة، أو أثناء التحقق من شهادة الوسيط نفسه.
3. تحقّق من إصدارات العميل والاعتماديات الفعلية عند مقارنة حل قديم. فقد تعاملت تطبيقات وسيط سابقة مع المخطط بشكل مختلف.

عدة إصلاحات يمكن أن تكون خاطئة لأسباب مختلفة. قائمة وسطاء HTTP تقدّم مرشحات نقاط نهاية HTTP عادية للطلبات العامة المسموح بها عبر هذا المسار. نقطة نهاية HTTP عادية تحتاج مخطط وسيط HTTP؛ ونقطة نهاية ممكّنة فعليًا بـ TLS ينبغي أن تحتفظ بـ HTTPS والتحقق من شهادتها. الوسيط الذي يرفض CONNECT يحتاج خدمة أو سياسة مدعومة، لا خفضًا عشوائيًا للمكتبة.

احتفظ بأول فشل قابل للملاحظة. تعطيل التحقق من الشهادة لا يمكن أن يجعل مستمعًا يعمل بـ HTTP فقط يتحدث TLS، واختيار سياسة تشفير قديمة لا يمكن أن يفسّر رفضًا بـ HTTP أُرسل قبل مصافحة الموقع.