Un lanț SOCKS mai lung nu ascunde automat următorul salt
Identificați mesajele de configurare necriptate dintr-un lanț SOCKS construit de client înainte de a presupune că un alt salt ascunde metadatele destinației.
Un lanț schimbă cine deschide fiecare conexiune. Nu adaugă criptare doar pentru că o altă adresă SOCKS este adăugată pe o listă.
Luați în considerare un client care construiește singur acest lanț:
application → SOCKS A → SOCKS B → website
Mai întâi cere lui A să se conecteze la B. Prin acel flux poate negocia apoi cu B o conexiune la site. Dacă transportul de la client la A duce ambele negocieri fără criptare, un observator suficient de capabil pe acea legătură poate citi octeții de configurare trimiși de client. Destinația TCP exterioară nu este singura dovadă posibilă a observatorului.
Separați lanțul de schimbul de aplicație protejat
HTTPS poate proteja conținutul de aplicație al site-ului după ce sesiunea TLS începe. Nu criptează retroactiv mesajele de configurare SOCKS anterioare. Nici autentificarea SOCKS5 cu nume de utilizator și parolă nu este un transport criptat.
O aranjare criptată între client și primul salt schimbă vizibilitatea pe acea legătură. Are în continuare un operator și un alt capăt care ține fluxul decriptat. Descrieți această graniță de încredere în loc să afirmați că lanțul nu poate fi urmărit.
O rută părinte configurată pe server este altă topologie. Dacă A îl alege pe B intern, clientul nu a trimis neapărat o listă completă de intermediari pe prima sa conexiune. Nu afirmați că fiecare lanț expune fiecare salt în același fel.
Pentru o evaluare utilă a confidențialității, numiți observatorul, legătura, negocierea cu proxy-ul și granițele TLS. Site-ul care observă ieșirea lui B și observatorul rețelei de acces care urmărește prima conexiune a clientului răspund la întrebări diferite. Numărarea doar a salturilor nu răspunde la niciuna.