Jinsi bandari moja ya proksi inaweza kupokea HTTP na SOCKS
Inaeleza jinsi msikilizaji aliyehifadhiwa kwa makusudi anaweza kutofautisha HTTP na SOCKS, wakati msikilizaji wa kawaida wa itifaki moja hawezi.
Msikilizaji wa proksi mchanganyiko anaweza kupokea HTTP na SOCKS kwenye bandari moja ya TCP kwa sababu seva huchunguza baiti za kwanza za itifaki. Nambari ya bandari haifanyi utambuzi huo.
Ombi la proksi la HTTP huanza na mbinu ya HTTP, kama GET au CONNECT. Salamu ya SOCKS huanza na sehemu za itifaki za jozi. Programu iliyoundwa kwa ajili ya maingizo haya inaweza kupeleka muunganisho kwa mshughulikiaji anayefaa.
Hii ni sifa bayana ya utekelezaji. Msikilizaji wa kawaida wa HTTP wa Squid hawi mchanganyiko kwa sababu bandari yake inabadilishwa kuwa 1080, na msikilizaji wa SOCKS pekee hajifunzi HTTP kutoka mipangilio ya kivinjari.
TLS inaongeza mpaka mwingine: muunganisho wa proksi uliosimbwa huanza na TLS, si kwa mbinu ya HTTP inayoonekana. Kuunga mkono hilo kwenye nukta moja ya mwisho kunahitaji ushughulikiaji wa makusudi wa ziada; kutambua HTTP ya maandishi wazi na SOCKS hakuthibitishi uwezo huo.
Tumia itifaki ya mteja iliyoandikwa kwa nukta ya mwisho. Ikiwa zote mbili zinafanya kazi, hiyo ni ushahidi kuhusu msikilizaji mchanganyiko wa seva hiyo, si sababu ya kuacha itifaki bila kubainishwa kwa kila mteja.
Msikilizaji mchanganyiko wa Glider unatoa mfano halisi: huchungulia baiti moja bila kuinywa, hutuma 0x05 kwa mshughulikiaji wake wa SOCKS5, na vinginevyo huita kichanganuzi chake cha HTTP. Kichanganuzi hicho bado huthibitisha ombi linaloingia; uchaguzi wa kutuma haufanyi maingizo holela kuwa HTTP halali.
Kushiriki msikilizaji wa TCP hakuleti kwa wenyewe uhusiano wa UDP wa SOCKS5. Glider huanzisha msikilizaji wake wa UDP kando. Uchaguzi wa itifaki ya TCP na upelekaji wa datagram baadaye ni uwezo tofauti.