더 긴 SOCKS 체인이 다음 홉을 자동으로 숨기지는 않는다

체인은 각 연결을 누가 여는지를 바꾼다. 목록에 SOCKS 주소를 하나 더 넣는다고 해서 암호화가 추가되지는 않는다.

이 체인을 스스로 구성하는 클라이언트를 생각해 보자:

application → SOCKS A → SOCKS B → website

먼저 A에게 B로의 연결을 요청한다. 그 스트림을 통해 이어서 B와 웹사이트로의 연결을 협상할 수 있다. 클라이언트에서 A로 가는 전송이 두 협상을 암호화 없이 실어 보낸다면, 그 링크에서 충분한 능력을 갖춘 관찰자는 클라이언트가 보낸 설정 바이트를 읽을 수 있다. 바깥쪽 TCP 목적지만이 관찰자의 유일한 증거는 아니다.

체인과 보호된 애플리케이션 교환을 분리하라

HTTPS는 TLS 세션이 시작된 뒤 웹사이트의 애플리케이션 콘텐츠를 보호할 수 있다. 그러나 앞서 오간 SOCKS 설정 메시지를 소급해 암호화하지는 않는다. SOCKS5의 사용자 이름/비밀번호 인증 역시 암호화된 전송이 아니다.

클라이언트와 첫 홉 사이를 암호화하면 그 링크에서의 가시성만 달라진다. 운영자와 복호화된 스트림을 보유한 다른 종단은 여전히 존재한다. 체인이 추적 불가능하다고 주장하기보다 그 신뢰 경계를 설명하라.

서버에 구성된 상위 경로는 또 다른 토폴로지다. A가 내부적으로 B를 선택한다면 클라이언트가 첫 연결에서 중간자 전체 목록을 보냈다고 단정할 수 없다. 모든 체인이 모든 홉을 같은 방식으로 노출한다고 주장하지 마라.

쓸모 있는 프라이버시 평가를 위해서는 관찰자, 링크, 프록시 협상, TLS 경계를 지목하라. B의 출구를 관찰하는 웹사이트와 클라이언트의 첫 연결을 지켜보는 접속망 관찰자는 서로 다른 질문에 답한다. 홉 수만 세는 것은 둘 중 어느 질문에도 답하지 못한다.