Proksi ilə WRONG_VERSION_NUMBER: HTTP və HTTPS-i yoxlayın

Xəta “yanlış versiya” deyir, ona görə TLS versiyalarını dəyişməyə başlamaq cəlbedicidir. Proksi ilə isə daha erkən bir ehtimalı yoxlayın: müştəri TLS əl sıxmasını adi HTTP gözləyən porta göndərdimi?

https://example.com/ kimi bir təyinat və http://proxy.example:8080 kimi bir proksi adi cütdür. İkinci URL-i HTTPS-ə çevirmək müştəriyə öz söhbətini elə proksinin özü ilə şifrələməsini deyir. Bu, HTTPS saytlarına icazə vermək barədə göstəriş deyil.

İlk TLS söhbətini tapın

HTTP proksi üçün müştəri əvvəlcə CONNECT göndərib HTTP cavabı ala bilər. Yalnız bundan sonra tunelin içində təyinatın TLS-ni başladır. HTTPS proksi üçün isə əvvəlcə proksiyə ayrıca TLS bağlantısı gəlir.

HTTP xəta səhifəsi və ya digər sadə mətn alan TLS analizatoru protokol xətası bildirə bilər. Bu ifadə saytın hansı TLS versiyalarını dəstəklədiyini, hətta saytla əlaqə saxlanıldığını belə sübut etmir.

1. Proksinin URL-ini sxemi daxil olmaqla və son nöqtənin sənədləşdirilmiş protokolunu qeyd edin.
2. Uğursuzluğun CONNECT cavabından əvvəl, təyinat TLS-i zamanı, yoxsa proksinin öz sertifikatı yoxlanılarkən baş verdiyini müəyyən edin.
3. Köhnə müvəqqəti həlli müqayisə edərkən faktiki müştəri və asılılıq versiyalarını yoxlayın. Əvvəlki proksi tətbiqləri bəzən sxemi başqa cür rəftar edirdi.

Bir neçə düzəliş müxtəlif səbəblərdən yanlış ola bilər. HTTP proksi siyahısı bu cür marşrutla icazə verilən ictimai sorğular üçün adi HTTP son nöqtə namizədləri təqdim edir. Adi HTTP son nöqtəsi HTTP proksi sxeminə ehtiyac duyur; həqiqətən TLS aktiv olan son nöqtə HTTPS-i və sertifikat yoxlamasını saxlamalıdır. CONNECT-i rədd edən proksi dəstəklənən xidmət və ya siyasət tələb edir, kitabxananın özbaşına aşağı salınmasını deyil.

İlk müşahidə edilə bilən uğursuzluğu saxlayın. Sertifikat yoxlamasını söndürmək yalnız HTTP ilə danışan dinləyicini TLS danışan etmir və köhnə şifr siyasətinin seçilməsi saytın əl sıxmasından əvvəl göndərilən HTTP rəddini izah edə bilməz.