Pikem SOCKS-ahel ei peida järgmist hüpet automaatselt

Ahel muudab, kes iga ühenduse avab. See ei lisa krüpteerimist üksnes sellega, et nimekirja pannakse veel üks SOCKS-aadress.

Mõelge kliendile, kes ehitab selle ahela ise:

application → SOCKS A → SOCKS B → website

Kõigepealt palub ta A-l ühenduda B-ga. Selle voo kaudu saab ta seejärel B-ga läbi rääkida ühenduse veebisaidiga. Kui transport kliendilt A-le kannab mõlemad läbirääkimised ilma krüpteerimiseta, suudab sellel lingil piisavalt võimekas vaatleja lugeda seadistusbaite, mille klient saatis. Väline TCP-sihtkoht ei ole vaatleja ainus võimalik tõend.

Eraldage ahel kaitstud rakendusvahetusest

HTTPS suudab veebisaidi rakendussisu kaitsta pärast TLS-seansi algust. See ei krüpteeri tagasiulatuvalt varasemaid SOCKS-i seadistussõnumeid. Ka SOCKS5 kasutajanime/parooli autentimine ei ole krüpteeritud transport.

Krüpteeritud lahendus kliendi ja esimese hüppe vahel muudab sellel lingil nähtavust. Sellel on endiselt operaator ja teine lõpp-punkt, mis hoiab dekrüpteeritud voogu. Kirjeldage seda usalduspiiri, selle asemel et väita, et ahelat ei saa jälitada.

Serveris seadistatud ülemvee tee on teine topoloogia. Kui A valib B sisemiselt, ei pruugi klient oma esimese ühendusega saata täielikku vahendajate nimekirja. Ärge väitke, et iga ahel paljastab iga hüppe ühtemoodi.

Kasuliku privaatsushinnangu jaoks nimetage vaatleja, link, puhverserveri läbirääkimine ja TLS-i piirid. Veebisait, mis jälgib B väljumist, ja juurdepääsuvõrgu vaatleja, kes jälgib kliendi esimest ühendust, vastavad erinevatele küsimustele. Ainult hüpete loendamine ei vasta kummagile.