이렇게 하는 게 다음과 같은 이유로 쉽기 때문입니다:
먼저 이렇게 해야 Tor가 VoIP와 같은 신규 프로토콜을 다루기 더 쉬워집니다.
애플리케이션에 SKCOS를 적용하는 데 필요한 사항이 모두 해결됩니다.
출구 연결(exit connection)을 대상으로 출구 중계서버에 그렇게 많은 파일 기술자(descriptor)를 할당할 필요가 없습니다.
이러한 방향으로 진행하려 합니다만, 몇몇 문제가 있습니다:
IP 패킷에 운영체제 속성이 드러난다는 것입니다.
TCP 핑거프린팅 공격 등을 막으려면, IP 수준의 패킷 정규화가 현 단계에서 여전히 필요합니다.
TCP 스택이 지닌 분산성과 복잡성, 그리고 기기 핑거프린팅 공격을 고려했을 때, 사용자 영역(user space)에 Tor만의 TCP 스택을 따로 제공하는 게 가장 나아보입니다.
애플리케이션 단 스트림의 정화가 여전히 필요합니다.
Tor 프로젝트는 Torbutton과 같은 사용자 측에서의 애플리케이션이 계속 필요합니다.
그래서 패킷을 포착하고 IP 계층에서 패킷을 익명화하는 수준의 문제에 머무르진 않을 겁니다.
특정한 프로토콜에서 여전히 정보가 새고 있습니다.
Tor 프로젝트는 사용자의 ISP 내의 DNS 서버가 아닌 연결되지 않을 법한 DNS 서버로 전송될 수 있도록 DNS 요청을 다시 작성합니다. 따라서 전송되는 프로토콜을 반드시 파악해야 합니다.
DTLS (datagram TLS)엔 기본적으로 사용자가 없으며, IPsec은 확실히 큽니다.
Tor 프로젝트에서 전송 메커니즘(transport mechanism)을 선정하면, 그 후엔 tagging 공격과 다른 잠재적 익명성 및 현재 중단, 재전송 등과 같이 일어나고 있는 무결성 이슈에 대응할 수 있는 새로운 종단간 Tor 프로토콜을 설계하는 것입니다.
임의의 IP 패킷에 대한 '출구 정책'은 곧 보안 상 안전한 침입 탐지 시스템(Intrusion Detection System, IDS)를 세우는 겁니다.
Tor 노드 운영자 분들의 말씀에 따르면, Tor를 운영하고 싶지 않은 이유 중 하나가 '출구 정책'(exit policies)라고 합니다.
IDS를 추가해 출구 정책을 관리한다면 Tor의 보인이 지닌 복잡도를 제고하고, Tor가 작동 불능에 빠질 가능성이 낮아집니다. IDS와 카운터 IDS 관련 논문에서 이 효능이 검증됐습니다.
Tor가 (변조된 패킷이나 IP 플러드와 같은 임의의 IP와 달리) 적합한(valid) TCP 스트림(TCP stream)만 전송한다는 사실만 봐도 Tor가 잠재적 남용 문제의 산실이란 의심이 해명됩니다.
'출구 정책'은 IP 패킷을 전송할 수 있게 됨에 따라 훨씬 더 중요한 요소로 자리잡았습니다.
Tor 디렉터리 내 출구 정책을 요지만 간추려 설명할 필요가 있습니다. 그래야 어떤 노드에서 패킷이 나가는 걸 허용할지 클라이언트가 예측할 수 있으니까요.
더욱이 클라이언트는 출구 노드를 선정하기 전에 세션에 보내고자 하는 패킷 모두를 예측해야 합니다!
Tor 내부 명 공간(Tor-internal name space)을 재설계 해야 합니다.
Tor는 onion 서비스가 Tor 클라이언트로 전송되는 과정에서 이를 가로채는 방식으로 onion 서비스의 '.onion' 주소를 지원하고 있습니다.
IP 단에서 행하는 이와 같은 방식은 Tor와 현지 DNS 리졸버 사이의 복잡한 인터페이스가 요구됩니다.
아니요, 경로를 선택하는 네트워크를 신뢰할 수 없습니다.
악의적인 중계서버에서 귀하의 연결을 그들과 유착한 곳으로 보낼 수 있습니다.
그렇게 될 경우 적들이 귀하 트래픽의 처음부터 끝까지 조회할 수 있게 됩니다.
모든 Tor 유저를 관장할만큼 네트워크 크기를 조정해주시면 모든 Tor 사용자가 중계서버가 되는데 도움이 됩니다. 또한 Tor 중계서버를 돌리는 게 귀하의 익명성 증진에도 도움이 되고요.
하지만 많은 Tor 사용자는 좋은 환경의 중계서버가 되기 어렵습니다.가령, Tor 클라이언트가 제한적인 방화벽을 거쳐 구동될 수도 있고, 모뎀을 통해 연결되는 경우, 이에 해당하지 않더라도 우회로의 트래픽로 자리잡을 수 없는 경우 좋은 중계서버라 보기 어렵습니다.
이러한 클라이언트에 서비스를 제공하는 건 유효한 익명성을 모두에게 제공하는 데 있어 매우 위협적입니다. 많은 Tor 사용자들은 이와 같거나 유사한 제약을 받는 환경에 놓여있기 때문에, 이러한 사용자가 서비스에 포함되면 익명성 기능의 규모를 늘릴 수 있기 때문입니다.
Tor 프로젝트는 Tor 사용자가 중계서버를 운영할 수 있도록 장려하고 싶습니다. 따라서 Tor 프로젝트가 하고자 하는 건 곧 중계서버의 설정 및 유지보수에 이르는 프로세스를 간단하게 만드는 것입니다.
지난 몇 년간 중계서버를 쉽게 구성할 수 있도록 많은 개선이 이루어져 왔습니다: Tor는 이제 주어진 중계서버의 연결이 다른 노드로 도달할 수 있는지(reachable), 해당 중계서버에서 제공 가능한 대역폭은 어느 정도인지 자동으로 탐지할 수 있습니다.
다만, 다만 이와 같은 자동화 시스템을 하기 위해선 네 요소의 개선이 필요합니다:
첫 번째, 허용할 대역폭의 적절한 양을 자동으로 추산할 수 있도록 여전히 개선할 필요가 있습니다.
이 경우엔 UDP 트랜스포트로 전환하는 게 가장 간단한 답이 될 듯 합니다. 사실 슬프게도 그리 간단한 대답은 아니지만요.
두 번쨰, Tor 프로젝트는 사용자 수가 늘어날 때에도 시스템이 유연하게 작동하도록(scalability) Tor를 설계해야 합니다. 네트워크의 확장성 측면도 고려해야 하고(모든 Tor 중계서버가 모든 tor 중계서버에 연결할 수 있어야 한다고 요구하는 걸 막는 방법) , 디렉터리의 확장성도 고려해야 합니다(모든 Tor 사용자가 모든 Tor 중계서버를 알고 있어야 한다고 요구하는 걸 막는 방법).
이러한 변화는 익명성에 잠재적으로나 실질적으로나 큰 영향을 미칩니다.
'난제'(Challenges) 보고서의 다섯 번째 항목에서 더 자세히 살펴보세요.
다시 말씀 드리지만, 이 경우엔 UDP 트랜스포트가 유효할 겁니다.
세 번째, 귀하가 익명화된 트래픽을 보내는 과정에서, 공격자가 귀하의 중계서버를 통해 트래픽을 전송할 수 있는 리스크의 여지가 있음을 이해할 필요가 있습니다.
세 종류의 연구 논문에서 '후보 중계서버(candidate relay)를 통해 우회로 내 중계서버의 신원을 특정하는 방법과 우회로가 활성화된 상황에서 트래픽 내 딥(dip)을 찾아내는 방법을 다루었습니다.
이러한 방해 공격(clogging attack)은 중계서버가 중계서버 역할 외에 클라이언트까지 했던 게 아닌 이상, Tor 환경에선 그렇게 위협적이지 않습니다.
하지만 Tor 프로젝트에서 더 많은 클라이언트가 (브리지 중계서버든 일반 중계서버든 간에) 중계서버 기능을 활성화하도록 장려할 수록, 해당 공격 방식을 더 잘 파악해 막을 태세를 갖춰야만 할 것입니다.
네 번째, Tor 프로젝트 입장에선 더 많은 사람들이 다른 사람의 트래픽을 중계할만한 장려책(incentive scheme)이 필요하기 때문입니다.
Tor 프로젝트가 현재까지 생각해본 Tor 인센티브를 확인해보세요.
이 모든 거에 손을 보태주세요!
중계서버 운영자가 출구 정책으로 reject www.slashdot.org 과 같은 사항을 집어넣었다면 괜찮은 것입니다. 주어진 웹사이트에서 관장하는 모든 IP 주소를 파악하겠다고(거기다 해당 IP 주소 대상으로 다른 사이트도 차단하겠다고) 적어둔 것은 바람직하지 않습니다.
그럼에도 두 문제가 있습니다.
첫 번째로 이러한 차단의 손길이 사용자에게 미칠 수 있다는 겁니다.
가령 중계서버 운영자가 Tor 네트워크에서 나갈 때 호스트명이 아니라 IP 주소를 요청할 수 있습니다.
즉 운영자가 문제의 목적지 IP 주소 전부를 파악하길 요구한다는 겁니다.
두 번째 문제는 원격 공격으로 인해 임의의 사이트가 검열되는 일이 발생할 수 있는 점입니다.
예를 들어, Tor 운영자가 www1.slashdot.org 를 차단하고 몇몇 공격자가 Tor 중계서버의 DNS에 독을 풀어두었든가 주요 뉴스 사이트의 IP 주소를 분해하기 위해 호스트네임을 변경했다면, 갑자기 해당 Tor 중계서버는 그 뉴스 사이트를 차단하게 됩니다.
