Proxychains sa pamamagitan ng Squid: mga paghihigpit sa CONNECT sa port 80

Naglo-load ang browser ng HTTP page sa pamamagitan ng Squid. Nabibigo ang parehong destinasyon sa ilalim ng proxychains. Hindi ito laging nangangahulugang pinili ng isa sa dalawang programa ang maling proxy IP.

Ang ordinaryong kliyenteng nakakaunawa ng HTTP ay maaaring magpadala ng web request sa forward proxy sa anyong HTTP proxy. Ang isang pangkalahatang socket wrapper ay nangangailangan ng byte tunnel para sa koneksyong gustong buksan ng aplikasyon. Para sa HTTP proxy sa kadena nito, gumagamit ang proxychains ng CONNECT.

Nangangahulugan ito na ang isang plaintext na website sa port 80 ay makakagawa ng CONNECT request para sa port 80. Ang patakaran ng Squid na nagpapahintulot ng CONNECT lamang patungo sa aprubadong listahan ng TLS port nito ay maaaring tanggihan ang tunnel na iyon kahit na pinapayagan ang ordinaryong HTTP request sa port 80.

Ihambing ang mga request, hindi lamang ang mga hostname

Inilalarawan ng dokumentasyon ng proxychains-ng ang suporta nito sa HTTP CONNECT. Ang mga tuntunin sa pag-access ng Squid ay nakakikilala ng method at destinasyong port. Iba't ibang landas ng request ang mga ito patungo sa parehong website.

Basahin ang pagtanggi at ang inaasahang patakaran bago ito baguhin. Ang pagpapalawak ng CONNECT access sa bawat port ay malaking pagbabago; hindi ito dapat maging default na tugon sa hindi pagkakatugma ng wrapper.

Kung may native na suporta ang aplikasyon sa HTTP proxy, makakaiwas ang paggamit nito sa hindi kailangang pangkalahatang tunnel para sa plaintext na HTTP. Kung talagang kailangan nito ng hilaw na TCP tunnel, pumili ng aprubadong proxy protocol at patakaran sa port na nagbibigay nito.

Ang matagumpay na request ng browser ay kapaki-pakinabang na ebidensya tungkol sa maabot ng proxy at sa isang sinusuportahang mode ng request. Ngunit hindi nito pinapatunayan na ang bawat paraan ng pag-tunnel, destinasyong port o protocol ng aplikasyon ay pinapayagan sa proxy na iyon.