WRONG_VERSION_NUMBER kun prokurilo: kontrolu HTTP kontraŭ HTTPS

La eraro diras “malĝusta versio”, do estas tentante komenci ŝanĝi TLS-versiojn. Kun prokurilo, kontrolu pli fruan eblecon: ĉu la kliento sendis TLS-manpremon al pordo, kiu atendis ordinaran HTTP?

Celvojo kiel https://example.com/ kaj prokurilo kiel http://proxy.example:8080 estas ordinara paro. Ŝanĝi la duan URL-on al HTTPS diras al la kliento ĉifri sian konversacion kun la prokurilo mem. Ĝi ne estas instrukcio permesi HTTPS-retejojn.

Trovu la unuan TLS-konversacion

Ĉe HTTP-prokurilo, la kliento povas unue sendi CONNECT kaj ricevi HTTP-respondon. Nur poste ĝi komencas la TLS de la celvojo ene de la tunelo. Ĉe HTTPS-prokurilo unue venas aparta TLS-konekto al la prokurilo.

TLS-analizilo ricevanta HTTP-eraran paĝon aŭ alian ordinaran tekston povas raporti protokoleraron. La vortigo ne pruvas, kiujn TLS-versiojn la retejo subtenas, nek eĉ ke la retejo estis kontaktita.

1. Notu la URL-on de la prokurilo, inkluzive de sia skemo, kaj la dokumentitan protokolon de la finpunkto.
2. Eltondu, ĉu la malsukceso okazis antaŭ CONNECT-respondo, dum la TLS de la celvojo, aŭ dum kontrolo de la propra atestilo de la prokurilo.
3. Kontrolu la realajn versiojn de kliento kaj dependaĵoj kiam vi komparas malnovan provizoran solvon. Pli fruaj prokurilaj efektivigoj foje traktis skemon alimaniere.

Pluraj riparoj povas esti malĝustaj pro diversaj kaŭzoj. La listo de HTTP-prokuriloj proponas ordinarajn HTTP-finpunktajn kandidatojn por publikaj petoj permesitaj tra tia vojo. Ordinara HTTP-finpunkto bezonas la HTTP-prokurilan skemon; vere TLS-ebligita finpunkto devus konservi HTTPS kaj sian atestilan kontrolon. Prokurilo rifuzanta CONNECT bezonas subtenatan servon aŭ regularon, ne arbitran malaltigon de la biblioteko.

Konservu la unuan observeblan malsukceson. Malŝalti atestilan kontrolon ne povas igi nur-HTTPaŭskultanton paroli TLS, kaj elekto de malnova ĉifra regulo ne povas klarigi HTTP-rifuzon senditan antaŭ la manpremo de la retejo.