▲

Tor 프로젝트가 Rust로 전환 중

 (itsfoss.com)
1P by GN⁺ 16시간전 | ★ favorite | 댓글 2개
  • Tor 네트워크의 핵심 코드가 기존 C 언어에서 Rust 기반의 Arti로 전환되고 있음
  • 기존 C 코드에는 버퍼 오버플로우, use-after-free, 메모리 손상 등 취약점이 존재
  • 새 버전 Arti 1.8.0은 회로 타임아웃 재설계를 통해 예측 가능한 패턴을 제거하고 추적 위험을 줄임
  • onion 서비스 운영자가 C 기반 Tor에서 Arti로 키를 자동 이전할 수 있는 새 명령어가 추가됨
  • 이번 전환은 보안성과 안정성 향상을 위한 Tor 프로젝트의 중요한 기술적 진전임

Arti 1.8.0 주요 변경 사항

  • 이번 릴리스의 핵심은 회로 타임아웃 재작업(circuit timeout rework) 적용

    • 기존 Tor의 *Circuit Dirty Timeout(CDT)*은 단일 타이머로 회로 종료 시점을 제어
    • 이 방식은 예측 가능해 트래픽 감시자가 패턴을 식별할 수 있었음
    • Arti 1.8.0은 사용량 기반 타임아웃과 개별 타이머를 도입해, 회로가 새 연결을 수락하거나 유휴 상태일 때 무작위 시점에 종료되도록 변경
    • 이를 통해 지문 추적(fingerprinting) 위험을 감소시킴

  • 새 실험적 명령어 arti hsc ctor-migrate 추가

    • onion 서비스 운영자가 제한된 검색 키(restricted discovery keys) 를 C 기반 Tor에서 Arti의 키 저장소(keystore) 로 이전 가능
    • 이 키들은 클라이언트 인증에 사용되며, 새 명령어는 수동 작업 없이 자동 이전을 지원

  • 추가 개선 사항

    • 라우팅 아키텍처, 프로토콜 구현, 디렉터리 캐시 지원, OR 포트 리스너 설정 등 다수의 내부 구성 요소 개선
    • 세부 변경 내역은 Arti 1.8.0의 공식 변경 로그에서 확인 가능

Rust 전환의 배경

  • Tor 네트워크는 2000년대 초부터 C 언어 기반으로 운영되어 왔음
  • 그러나 C 코드베이스는 메모리 안전성 문제로 인해 보안 취약점이 지속적으로 발생
  • 이에 따라 Tor 프로젝트는 Rust의 메모리 안전성을 활용한 Arti 재작성 프로젝트를 추진 중
  • Arti는 Tor의 기능을 Rust로 재구현하여, 보안성·안정성·유지보수성을 강화하는 목표를 가짐

기술적 의의

  • Rust 전환은 Tor의 익명성 보장 구조를 근본적으로 강화하는 방향
  • 예측 가능한 회로 동작 제거와 키 관리 자동화는 사용자 프라이버시 보호 수준 향상에 기여
  • Arti의 지속적 업데이트는 C 기반 Tor의 단계적 대체를 가속화하는 신호로 평가됨
▲
GN⁺ 16시간전  [-]
Hacker News 의견들

  • 최근 EFF의 Cover Your Tracks 테스트를 해봤는데, Tor 브라우저에서 JS를 끈 상태만 완전히 지문 추적에 저항하는 것으로 나왔음
    JS를 켠 Tor조차 ‘부분적으로만’ 저항한다고 평가되었고, Firefox는 JS를 꺼도 결과가 안 나왔음. 꽤 무서운 결과라 다른 사람들의 실험도 궁금함

    • 이 도구는 지문 보호 측정 방식이 결함이 있음. 무작위화를 사용하는 보호는 오히려 낮게 평가하고, 구간화(binning) 방식만 높게 평가함.
      반대로 fingerprinting.com/demo처럼 지속성만 테스트하는 도구도 문제임.
      진짜 위험 신호는 두 테스트 모두에서 실패하는 경우임
    • macOS Safari로 테스트했을 때 “웹 추적에 강한 보호”라는 결과를 받았음.
      다만 Tor 브라우저는 확실히 눈에 띄지만, 이 테스트만으로 Tor 사용자 간의 지문 구분이 쉽다고 보긴 어려움
    • Tor 브라우저는 캔버스 크기 반올림 같은 방식으로 지문 버킷을 넓히려 함. 결국 피할 수 없는 가장 넓은 버킷은 “Tor 사용자” 자체임
    • Debian에서 기본 설정 Tor 브라우저로 테스트했을 때 8.24비트의 식별 정보가 나왔음.
      보안 수준을 높일수록 오히려 식별 비트가 늘다가, JS를 완전히 끄면 다시 줄어듦.
      즉, JS 비활성화가 가장 높은 익명성을 제공함

  • Mozilla가 Firefox의 Rust 전환(oxidizing) 을 더 이어갔으면 좋았을 것 같음. Rust 생태계에도 긍정적이었을 텐데 아쉬움

    • 그래도 Chrome 팀은 여전히 Rust 도입을 진행 중임
    • Mozilla가 Rust 개발자를 대거 해고한 이후에도 Firefox 코드의 Rust 비율은 12% 이상으로 증가했음. Chromium은 4% 미만이라 상대적으로 적음
      만약 Rust가 Mozilla의 ‘비밀 무기’로 남았다면 오히려 Rust 확산이 늦어졌을 수도 있음
    • Servo 프로젝트의 실패는 Rust의 문제가 아니라 Mozilla 내부의 한계 때문이라고 생각함

  • Rust를 사용하는 게 그들의 문제 해결에 도움이 된다면 합리적인 선택이라고 봄.
    언어는 프로젝트와 팀, 문제에 따라 다르게 맞춰지는 도구임

    • 이런 “언어 전환기”보다 의존성 최적화나 성능 개선 같은 이야기가 더 흥미로울 때가 많음
    • 원문 블로그는 C를 비난하지 않았는데, 굳이 언급할 필요는 없다고 생각함
    • 메모리 안전 언어가 보안 측면에서 기술적으로 우월하다는 건 자명한 사실임.
      이는 Rust 팬보이 주장이 아니라, 의사나 조종사가 체크리스트를 거부하던 시절과 비슷한 저항의 문제임
    • Rust는 이번 케이스에 적합하지만, 대부분의 UI 프로젝트에는 부적합함.
      UI는 빠른 반복과 GC가 중요하고, 성능은 덜 중요함. Rust로 UI를 짜면 유지보수 지옥이 될 수 있음
    • “모든 걸 Rust로 다시 쓰자”는 태도는 싫지만, Tor의 경우엔 Rust가 적합한 도구임.
      Tor는 보안과 성능이 모두 중요한 멀티스레드 환경이기 때문임.
      Zig도 대안이 될 수 있지만 아직 성숙하지 않음. Tigerbeetle처럼 결정적 동작(determinism) 을 중시하는 접근도 흥미로움

  • Tor 프로젝트의 가장 큰 불만은 속도 저하임. Rust로 옮긴다고 빨라질 것 같진 않음

    • Onion 라우팅은 프라이버시와 성능의 트레이드오프가 존재함. 네트워크 지연이 대부분의 원인임
    • Tor의 느림은 코드보다 노드 수 부족 때문임. 새 버전은 더 안전할 뿐 빠르진 않음
    • 트래픽이 지구를 두 바퀴 도는 구조라 물리적으로 지연이 생김. 결국 빛의 속도 한계임
    • Tor는 익명성 보장용이지, 영상 스트리밍용이 아님
    • 빠른 익명 네트워크를 만드는 건 매우 어려움. 그래도 최근 Tor는 예전보다 훨씬 빨라졌고, onion 내부에서만 활동하면 익명성이 높아짐

  • 이번 Rust 전환은 Zcash Community Grants의 지원으로 이루어졌음. 암호화폐 R&D에서도 좋은 결과가 나올 수 있음

    • 돈은 돈일 뿐이라는 의미에서 “Pecunia non olet(돈은 냄새 나지 않는다)”라는 말이 떠오름.
      다만 암호화폐는 소변보다 나쁠 수도 있다는 농담 섞인 비유를 덧붙임

  • Tor exit 노드 운영 시 법적 리스크가 걱정됨. 화이트리스트 기반으로만 허용할 수 있는 방법이 있을까 궁금함

    • Tor 공식 블로그의 exit 노드 운영 가이드를 참고하면 좋음.
      가능하면 조직 명의 등록이 권장되고, 더 안전하게 돕고 싶다면 relay 운영이 나음
    • 법적 주목을 피하고 싶다면 bridge를 운영하는 것도 방법임.
      또는 guard/middle relay를 돌리면 네트워크에 큰 도움이 됨
    • exit 노드는 어렵지만, 리눅스 ISO 토렌트나 오픈맵 타일 서버를 호스팅하는 식으로 대역폭을 기부할 수도 있음.
      단, 중국 ASN 일부를 차단해야 함. 가짜 다운로드 트래픽이 많음

  • Rust 도입은 마치 오래된 요새의 나무 기둥을 강철로 교체하는 과정 같음.
    Tor의 C 기반 코드는 수십 년간의 보안 타협과 성능 흔적을 품고 있어서, 점진적 Rust화가 가장 현실적인 안전 확보 방법임
    핵심은 “전면 재작성”이 아니라 메모리 비안전 영역 축소임.
    위험도가 높은 파싱, 암호화, 프로토콜 경계 부분만 Rust로 옮기면 Tor는 더 견고해질 것임
    앞으로 Rust 기반 플러그인 전송이나 하이브리드 런타임으로 발전할지도 흥미로운 포인트임

  • 사실 이 결정은 최근 일이 아님. Tor는 2020년에 Rust 기반 Arti 프로젝트를 시작했고, 2022년에 Arti 1.0을 발표했음
    C 코드베이스를 점진적으로 리팩터링하기 어렵다고 판단했고, Rust의 개발 속도·이식성·기여자 유입에 만족했다고 함
    최근에도 Arti changelog에 따르면 활발히 개발 중임

    • Arti는 라이브러리 형태로 다른 앱에 내장 가능하게 설계되어 있음.
      예를 들어 메시징 앱이 별도 Tor 데몬 없이 네트워크를 활용할 수 있게 됨. 이게 더 큰 변화라고 생각함
    • 제목이 과장되었다는 의견도 있음. Tor 팀은 오랜 기간 신중히 진행했음
    • 이 링크가 원문보다 훨씬 좋은 참고 자료임. “왜 Rust인가” 논쟁을 미리 차단할 만큼 명확한 전략이 보임
    • Rust가 C보다 운영체제 간 이식성이 더 좋은지에 대한 의문도 제기됨

  • Tor는 단순한 개념이 아니라 프로토콜(onion routing) 과 네트워크, 그리고 참조 구현체를 모두 포함하는 이름임

    • Onion routing이 프로토콜이고, Tor는 그 위의 네트워크 및 구현체임
    • Tor는 실제로 다운로드 가능한 제품이며, 여러 구성요소로 이루어짐
    • “Tor를 Rust로 다시 쓴다”는 표현은 틀린 말은 아님

  • Tor를 Fil-C로 컴파일하면 메모리 안전성을 공짜로 얻을 수 있지 않을까 하는 농담 섞인 제안이 있었음

    • 하지만 이 전환은 Fil-C 등장 이전부터 시작된 프로젝트였음
답변달기