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 ارسال‌شده پیش از دست‌دهی وب‌سایت را توضیح دهد.