A hosszabb SOCKS-lánc nem rejti el automatikusan a következő ugrást
Azonosítsa az ügyfél által épített SOCKS-lánc titkosítatlan beállítási üzeneteit, mielőtt feltételezné, hogy egy újabb ugrás elrejti a cél metaadatait.
A lánc megváltoztatja, ki nyitja meg az egyes kapcsolatokat. Nem tesz hozzá titkosítást pusztán azzal, hogy egy újabb SOCKS-cím kerül a listára.
Vegyünk egy ügyfelet, amely maga építi fel ezt a láncot:
application → SOCKS A → SOCKS B → websiteElőször megkéri A-t, hogy kapcsolódjon B-hez. Ezen a folyamon keresztül aztán tárgyalhat B-vel a webhelyhez való kapcsolódásról. Ha az ügyféltől A-ig tartó átvitel mindkét tárgyalást titkosítás nélkül szállítja, egy kellően rátermett megfigyelő ezen a kapcsolaton elolvashatja az ügyfél által küldött beállítási bájtokat. A külső TCP-cél nem az egyetlen lehetséges bizonyíték a megfigyelő számára.
Válassza szét a láncot a védett alkalmazásforgalomtól
A HTTPS megvédheti a webhely alkalmazástartalmát, miután elindult a TLS-munkamenet. Nem titkosítja visszamenőleg a korábbi SOCKS-beállítási üzeneteket. A SOCKS5 felhasználónév és jelszó alapú hitelesítése sem titkosított átvitel.
Az ügyfél és az első ugrás közötti titkosított elrendezés megváltoztatja a láthatóságot azon a kapcsolaton. Továbbra is van egy üzemeltetője és egy másik végpontja, amely a visszafejtett folyamot tartja. Írja le ezt a bizalmi határt ahelyett, hogy azt állítaná, a lánc nyomon követhetetlen.
A kiszolgálón beállított szülőútvonal más topológia. Ha A belsőleg választja B-t, az ügyfél nem feltétlenül küldte el a közvetítők teljes listáját az első kapcsolatán. Ne állítsa, hogy minden lánc minden ugrást ugyanúgy tár fel.
Egy hasznos adatvédelmi értékeléshez nevezze meg a megfigyelőt, a kapcsolatot, a proxy-tárgyalást és a TLS-határokat. A B kimenetét figyelő webhely és az ügyfél első kapcsolatát néző hálózati megfigyelő különböző kérdésekre válaszol. Az ugrások puszta számolása egyikre sem válaszol.