WRONG_VERSION_NUMBER ve bir proxy: HTTP ile HTTPS'i karşılaştırın

Hata “yanlış sürüm” diyor, bu yüzden TLS sürümlerini değiştirmeye başlamak cazip geliyor. Bir proxy ile daha önceki bir olasılığı kontrol edin: istemci, düz HTTP bekleyen bir bağlantı noktasına TLS el sıkışması gönderdi mi?

https://example.com/ gibi bir hedef ile http://proxy.example:8080 gibi bir proxy olağan bir çifttir. İkinci URL'yi HTTPS yapmak, istemciye konuşmasını proxy'nin kendisiyle şifrelemesini söyler. Bu, HTTPS sitelerine izin verme talimatı değildir.

İlk TLS konuşmasını bulun

HTTP proxy'sinde istemci önce CONNECT gönderip bir HTTP yanıtı alabilir. Ancak ondan sonra tünelin içinde hedefin TLS'ini başlatır. HTTPS proxy'sinde önce proxy'ye ayrı bir TLS bağlantısı gelir.

HTTP hata sayfası veya başka bir düz metin alan TLS ayrıştırıcısı bir protokol hatası bildirebilir. Bu ifade, sitenin hangi TLS sürümlerini desteklediğini, hatta siteyle bağlantı kurulup kurulmadığını bile ortaya koymaz.

1. Proxy URL'sini şemasıyla birlikte ve uç noktanın belgelenmiş protokolünü kaydedin.
2. Hatayı bir CONNECT yanıtından önce mi, hedefin TLS'i sırasında mı, yoksa proxy'nin kendi sertifikası doğrulanırken mi oluştuğunu bulun.
3. Eski bir geçici çözümü karşılaştırırken gerçek istemci ve bağımlılık sürümlerini kontrol edin. Önceki proxy uygulamaları bazen bir şemayı farklı ele alıyordu.

Birkaç düzeltme farklı nedenlerle yanlış olabilir. HTTP proxy listesi, böyle bir yoldan izin verilen genel istekler için olağan HTTP uç nokta adayları sunar. Düz HTTP uç noktası HTTP proxy şemasını gerektirir; gerçekten TLS etkin bir uç nokta HTTPS'i ve sertifika doğrulamasını korumalıdır. CONNECT'i reddeden proxy desteklenen bir hizmet veya ilke gerektirir, kitaplığı keyfî biçimde düşürmek değil.

İlk gözlenebilir hatayı koruyun. Sertifika doğrulamasını kapatmak yalnızca HTTP konuşan bir dinleyiciye TLS konuşturmaz ve eski bir şifreleme ilkesi seçmek, sitenin el sıkışmasından önce gönderilen bir HTTP reddini açıklayamaz.