Pidempi SOCKS-ketju ei piilota seuraavaa hyppyä automaattisesti

Ketju muuttaa sitä, kuka avaa minkäkin yhteyden. Se ei lisää salausta vain siksi, että listaan lisätään vielä yksi SOCKS-osoite.

Tarkastellaan asiakasta, joka rakentaa tämän ketjun itse:

application → SOCKS A → SOCKS B → website

Se pyytää ensin A:ta yhdistämään B:hen. Tuon virran kautta se voi sitten neuvotella B:n kanssa yhteydestä verkkosivustoon. Jos asiakkaan ja A:n välinen siirto kuljettaa molemmat neuvottelut salaamatta, riittävän kyvykäs tarkkailija tuolla linkillä voi lukea asiakkaan lähettämät asetusbitit. Ulkoinen TCP-kohde ei ole tarkkailijan ainoa mahdollinen todiste.

Erota ketju suojatusta sovellusvaihdosta

HTTPS voi suojata verkkosivuston sovellussisällön, kun sen TLS-istunto alkaa. Se ei salaa takautuvasti aiempia SOCKS-asetusviestejä. Myöskään SOCKS5:n käyttäjänimi/salasana-todennus ei ole salattu siirto.

Salattu järjestely asiakkaan ja ensimmäisen hypyn välillä muuttaa näkyvyyttä tuolla linkillä. Sillä on yhä operaattori ja toinen päätepiste, joka pitää salauksen purkamansa virran. Kuvaile tuo luottamusraja sen sijaan, että väittäisit ketjua jäljittämättömäksi.

Palvelimelle määritetty ylätason reitti on toinen topologia. Jos A valitsee B:n sisäisesti, asiakas ei välttämättä lähettänyt täydellistä välikäsittelijöiden luetteloa ensimmäisellä yhteydellä. Älä väitä, että jokainen ketju paljastaa jokaisen hypyn samalla tavalla.

Hyödyllistä yksityisyysarviointia varten nimeä tarkkailija, linkki, välityspalvelinneuvottelu ja TLS-rajat. Verkkosivusto, joka tarkkailee B:n ulostuloa, ja käyttöverkon tarkkailija, joka seuraa asiakkaan ensimmäistä yhteyttä, vastaavat eri kysymyksiin. Pelkkä hyppyjen laskeminen ei vastaa kumpaankaan.