Ipinapakita ng bukas na TCP port na tumanggap ng koneksyon ang listener. Maaaring proxy, karaniwang web server o ibang serbisyo iyon; hindi tinutukoy ng port 8080 ang protocol.

Para sa endpoint na dokumentadong HTTP proxy, gamitin ang tunay nitong address sa HTTPS request na may takdang oras:

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/

Palitan ang address para sa dokumentasyon ng iyong HTTP endpoint o kandidato mula sa HTTP proxy list. Para sa SOCKS, gamitin ang katumbas na SOCKS client mode at kumpletuhin ang negosasyon. Maaaring pumalya ang maling handshake kaagad matapos tanggapin ang TCP.

Naobserbahang yugtoAno ang pinatutunayan
Tinanggap ang TCPMaaabot ang listener.
Tinanggap ang proxy handshakeTinanggap ng listener ang proxy operation na ito.
Naberipika ang TLS ng destinationNakumpleto ng client ang nilalayong ligtas na koneksyon ayon sa trust settings nito.
Natanggap ang inaasahang status at contentNagbigay ng inaasahang resulta ang request ng application.

Para sa HTTPS sa pamamagitan ng HTTP proxy, kailangang payagan ang CONNECT sa destination port. Kahit CONNECT 200 ay gitnang yugto lang: maaaring magsara ang tunnel bago magtagumpay ang TLS o huling request. Hindi patunay ng tunnel capability na iyon ang tagumpay sa hindi naka-encrypt na HTTP.

Gumamit ng destination na mahuhulaan ang content, mas mainam kung kontrolado mo, at tingnan ang request record kung mayroon. Kayang magbalik ng hindi naka-encrypt na HTTP listener ng nakapirming pahina na may status 200 nang hindi kinokontak ang target. Mas mahinang ebidensiya ang anumang success status kaysa tugmang inaasahang sagot; dagdag na proteksyon ang HTTPS identity verification.

Itala ang huling matagumpay na yugto. Ang ‘bukas ang port, tinanggihan ang SOCKS negotiation’ ay kapaki-pakinabang na simula para sa susunod na pagsisiyasat.

Kaugnay na mga artikulo