Ralat berkata “versi salah”, jadi menggoda untuk mula menukar versi TLS. Dengan proksi, semak kemungkinan yang lebih awal: adakah klien menghantar jabat tangan TLS ke port yang menunggu HTTP biasa?

Destinasi seperti https://example.com/ dan proksi seperti http://proxy.example:8080 ialah pasangan biasa. Menukar URL kedua kepada HTTPS memberitahu klien untuk menyulitkan perbualannya dengan proksi itu sendiri. Ia bukan arahan untuk membenarkan laman HTTPS.

Cari perbualan TLS pertama

Dengan proksi HTTP, klien boleh menghantar CONNECT dahulu dan menerima balasan HTTP. Selepas itu barulah ia memulakan TLS destinasi di dalam terowong. Dengan proksi HTTPS, sambungan TLS berasingan ke proksi datang dahulu.

Penghurai TLS yang menerima halaman ralat HTTP atau teks biasa lain boleh melaporkan ralat protokol. Perkataan itu tidak menetapkan versi TLS yang disokong laman, malah sama ada laman itu dihubungi.

  1. Catat URL proksi, termasuk skemanya, dan protokol titik hujung yang didokumenkan.
  2. Cari sama ada kegagalan berlaku sebelum balasan CONNECT, semasa TLS destinasi, atau semasa mengesahkan sijil proksi itu sendiri.
  3. Semak versi klien dan kebergantungan sebenar apabila membandingkan penyelesaian lama. Pelaksanaan proksi terdahulu kadangkala mengendalikan skema secara berbeza.

Beberapa pembetulan boleh tersilap atas sebab berbeza. Senarai proksi HTTP menawarkan calon titik hujung HTTP biasa untuk permintaan awam yang dibenarkan melalui laluan sedemikian. Titik hujung HTTP biasa memerlukan skema proksi HTTP; titik hujung yang benar-benar didayakan TLS harus mengekalkan HTTPS dan pengesahan sijilnya. Proksi yang menolak CONNECT memerlukan perkhidmatan atau dasar yang disokong, bukan penurunan pustaka secara sewenang-wenangnya.

Kekalkan kegagalan pertama yang boleh diperhatikan. Melumpuhkan pengesahan sijil tidak boleh membuat pendengar HTTP sahaja bertutur TLS, dan memilih dasar sifer lama tidak boleh menjelaskan penolakan HTTP yang dihantar sebelum jabat tangan laman.

Artikel berkaitan