# Tor 프로젝트가 Rust로 전환 중

> Clean Markdown view of GeekNews topic #25048. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25048](https://news.hada.io/topic?id=25048)
- GeekNews Markdown: [https://news.hada.io/topic/25048.md](https://news.hada.io/topic/25048.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-14T01:33:21+09:00
- Updated: 2025-12-14T01:33:21+09:00
- Original source: [itsfoss.com](https://itsfoss.com/news/tor-rust-rewrite-progress/)
- Points: 4
- Comments: 2

## Topic Body

- **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의 [공식 변경 로그](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHANGELOG.md)에서 확인 가능  

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

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

## Comments



### Comment 47696

- Author: xguru
- Created: 2025-12-14T07:12:52+09:00
- Points: 1

[Arti 1.0.0 릴리즈 - Rust로 작성한 Tor 구현체](https://news.hada.io/topic?id=7336)

### Comment 47689

- Author: neo
- Created: 2025-12-14T01:33:21+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46243543) 
- 최근 [EFF의 Cover Your Tracks](https://coveryourtracks.eff.org/) 테스트를 해봤는데, **Tor 브라우저에서 JS를 끈 상태**만 완전히 지문 추적에 저항하는 것으로 나왔음  
  JS를 켠 Tor조차 ‘부분적으로만’ 저항한다고 평가되었고, Firefox는 JS를 꺼도 결과가 안 나왔음. 꽤 무서운 결과라 다른 사람들의 실험도 궁금함
  - 이 도구는 **지문 보호 측정 방식이 결함**이 있음. 무작위화를 사용하는 보호는 오히려 낮게 평가하고, 구간화(binning) 방식만 높게 평가함.  
    반대로 [fingerprinting.com/demo](https://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 노드 운영 가이드](https://blog.torproject.org/tips-running-exit-node/)를 참고하면 좋음.  
    가능하면 **조직 명의 등록**이 권장되고, 더 안전하게 돕고 싶다면 [relay 운영](https://community.torproject.org/relay/)이 나음
  - 법적 주목을 피하고 싶다면 [bridge](https://community.torproject.org/relay/setup/bridge/)를 운영하는 것도 방법임.  
    또는 [guard/middle relay](https://community.torproject.org/relay/types-of-relays/)를 돌리면 네트워크에 큰 도움이 됨
  - exit 노드는 어렵지만, **리눅스 ISO 토렌트나 오픈맵 타일 서버**를 호스팅하는 식으로 대역폭을 기부할 수도 있음.  
    단, 중국 ASN 일부를 차단해야 함. 가짜 다운로드 트래픽이 많음

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

- 사실 이 결정은 최근 일이 아님. Tor는 2020년에 Rust 기반 **Arti 프로젝트**를 시작했고, 2022년에 [Arti 1.0](https://blog.torproject.org/arti_100_released/)을 발표했음  
  C 코드베이스를 점진적으로 리팩터링하기 어렵다고 판단했고, Rust의 **개발 속도·이식성·기여자 유입**에 만족했다고 함  
  최근에도 [Arti changelog](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHANGELOG.md)에 따르면 활발히 개발 중임
  - Arti는 **라이브러리 형태로 다른 앱에 내장 가능**하게 설계되어 있음.  
    예를 들어 메시징 앱이 별도 Tor 데몬 없이 네트워크를 활용할 수 있게 됨. 이게 더 큰 변화라고 생각함
  - 제목이 과장되었다는 의견도 있음. Tor 팀은 오랜 기간 신중히 진행했음
  - 이 링크가 원문보다 훨씬 좋은 참고 자료임. “왜 Rust인가” 논쟁을 미리 차단할 만큼 명확한 전략이 보임
  - Rust가 C보다 **운영체제 간 이식성**이 더 좋은지에 대한 의문도 제기됨

- Tor는 단순한 개념이 아니라 **프로토콜(onion routing)** 과 **네트워크**, 그리고 **참조 구현체**를 모두 포함하는 이름임  
  - Onion routing이 프로토콜이고, Tor는 그 위의 네트워크 및 구현체임  
  - Tor는 실제로 다운로드 가능한 **제품**이며, 여러 구성요소로 이루어짐  
  - “Tor를 Rust로 다시 쓴다”는 표현은 틀린 말은 아님

- Tor를 **Fil-C로 컴파일**하면 메모리 안전성을 공짜로 얻을 수 있지 않을까 하는 농담 섞인 제안이 있었음
  - 하지만 이 전환은 **Fil-C 등장 이전**부터 시작된 프로젝트였음