Tor, 온리온 서비스에 프루프-오브-워크 방어 도입
(blog.torproject.org)- Tor 0.4.8은 온리온 서비스가 DoS 공격을 받을 때 검증된 네트워크 트래픽을 우선 처리하는 방어를 도입함
- IP 주소를 숨기는 온리온 서비스 구조에서는 IP 기반 속도 제한이 불완전해, 프라이버시를 해치지 않는 클라이언트 퍼즐 방식이 필요했음
- 서비스가 압박을 받으면 클라이언트는 점점 더 어려운 퍼즐 연산으로 작업량을 증명하고, 그 수준에 따라 연결 우선순위가 달라짐
- 일반 사용자의 초기 풀이 시간은 빠른 컴퓨터 약 5ms, 느린 하드웨어 최대 30ms 수준이라 대부분의 기기에서 감당 가능함
- 공격 트래픽이 늘면 요구 작업량이 약 1분까지 증가해 대량 연결 시도를 비싸게 만들고, 정상 사용자는 혼잡한 상황에서도 접근 기회를 얻음
Tor 0.4.8의 온리온 서비스 PoW 방어
- Tor는 Tor 0.4.8 릴리스와 함께 온리온 서비스용 프루프-오브-워크(PoW) 방어를 공식 도입함
- 목표는 DoS 공격을 억제하면서 검증된 트래픽을 우선 처리하는 것임
- 온리온 서비스 운영자는 버전 0.4.8로 업데이트하는 것이 권장됨
- 온리온 서비스는 사용자 프라이버시를 위해 IP 주소를 가리기 때문에 DoS 공격에 취약할 수 있으며, 전통적인 IP 기반 속도 제한만으로는 보호가 불완전함
클라이언트 퍼즐과 우선순위 처리
- PoW는 기본적으로 꺼져 있는 티켓 시스템처럼 동작하다가, 네트워크 스트레스가 발생하면 우선순위 큐를 만듦
- 클라이언트는 온리온 서비스에 접근하기 전 작은 퍼즐을 풀어 일정한 작업량을 수행했음을 증명해야 함
- 퍼즐이 어려울수록 더 많은 작업을 수행했다는 뜻이 됨
- 온리온 서비스는 클라이언트가 보여준 노력 수준에 따라 연결 우선순위를 정함
- 공격자가 많은 요청으로 온리온 서비스를 플러딩하면 .onion 사이트 접근에 필요한 계산 노력이 늘어남
- 대량 연결 시도는 더 많은 계산 자원을 요구함
- 작업량이 증가할수록 공격자의 수익성은 낮아지는 구조임
일반 사용자에게 보이는 영향
- 일반 사용자는 보통 한 번에 적은 요청만 보내므로 퍼즐 풀이 부담이 대부분의 기기에서 관리 가능한 수준임
- 초기 풀이 시간은 빠른 컴퓨터에서 약 5ms
- 느린 하드웨어에서는 최대 30ms
- 공격 트래픽이 늘면 작업량은 대략 1분까지 증가할 수 있음
- 이 과정은 사용자에게 보이지 않으며, PoW 해답을 기다리는 경험은 느린 네트워크 연결을 기다리는 것과 비슷함
- 주요 사이트들이 이 방식을 채택하면 표적 공격이 네트워크 속도에 미치는 부정적 영향을 줄일 수 있고, 갑작스러운 트래픽 급증 시 부하 균형을 도와 온리온 서비스 접근을 더 일관되고 신뢰 가능하게 만들 수 있음
댓글과 토론
Hacker News 의견들
-
흥미로움. 제안서를 보면 기대치가 명확함: 대형 봇넷을 막는 건 아니고, 스크립트 키디나 소규모 봇넷 방어를 목표로 함
DoS 공격 중에도 정말 접속하려는 사용자는 통과할 수 있지만, 어느 정도 수고가 필요할 수 있음
작업 증명 알고리즘으로 https://github.com/tevador/equix를 고른 것도 흥미로움
Bitcoin처럼 정적 목표값 아래로 내려가야 성공하는 방식이 아니라, 클라이언트가 작업 증명 노력으로 “입찰”하고 더 많은 노력을 들일수록 우선순위가 높아지는 구조임. 코인을 예치하는 대신 작업을 예치한다는 점에서 지분 증명과 비슷하다는 설명
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...- CPP, 즉 클라이언트 퍼즐 프로토콜은 처음 들어봄. 대형 봇넷은 다른 포트에서 난동을 부리는 식으로 우회할 수 있는 건지 궁금함
- 작업 증명 방어가 사용자 쪽 자원만 태우는 대신, 사용자에서 제공자로 어떤 가치 이전을 포함했으면 좋겠음
이 버전도 좋지만, 가치 이전이 추가되면 더 낫다고 봄 - 이제 양쪽 단점도 같이 생김. 가장 많은 연산 자원을 토스터처럼 쓸 수 있는 사람이 다른 모두를 DoS할 수 있음
게다가 작업 증명은 낭비되는 불필요한 계산일 뿐임. 계산은 공짜가 아니고, 작업 증명에 쓰는 모든 와트는 현재의 기후 위기를 더 악화시킴
며칠 안에 체감 120도, 실제 109도까지 올라갈 지역에 사는 입장에서는, 정중히 말해 작업 증명이 무엇에든 좋은 아이디어라고 제안하는 사람은 엿 먹으라고 하고 싶음
흥미로운 게 아니라, 지구상에서 가장 노골적인 과시적 소비 사례임
-
더 나은 글, 즉 실제 기술 세부사항은 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...임
선택한 작업 증명 함수는 equi-X로 보임 -
이런 게 더 일찍 안 들어간 게 놀랍고, 제안서 [0]를 충분히 자세히 읽지는 않아서 사용자 익명성에 영향을 주는 데이터가 늘어날지는 아직 모르겠음. 그래도 사용자-서비스 단위로 묶이고 어디에도 저장되지 않는다면 괜찮아 보임
프록시되는 서비스의 부하와 노드 자체의 부하를 각각 얼마나 줄일지도 궁금함. 접근이 여러 노드로 분산되니 서비스 쪽에 더 이득이 클 것 같음
[0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...- 진작 했어야 했지만, 바다가 끓는다고 소리치는 사람들 때문에 지연됐음
-
좋음. 곧 DDoS 방어용 CDN이 필요 없어질지도 모름. API를 Onion 서비스로 제공하면 됨
-
이 방식은 예전에 이메일 스팸 방지용으로도 제안된 적 있음
Cloudflare도 할 수 있음. 바쁜 사이트에 접속할 때마다 몇 초에서 몇 분 동안 쓸모없는 계산을 돌리게 되는 식임. 전체 효과는 전 세계 배터리를 빨아먹는 것일 듯- 이메일 보증금용 작업 증명 제안은 Adam Back의 Hashcash였고, 부분 해시 충돌을 사용했음
http://www.hashcash.org/
흥미롭게도 Bitcoin 작업 증명 채굴의 영감이 됐음 - Cloudflare는 이미 이걸 함. “연결을 확인 중” 화면이 뜨고 브라우저에서 해시를 돌림
- 광고랑 똑같음. 동의 없이 배터리를 닳게 함
- 그 평가는 공정하지 않음
온실가스도 대기에 뿜어낼 테니까 - 이 개념을 중심으로 만든 Bitmessage라는 앱이 있었는데, 지금은 방치된 프로젝트로 보임
- 이메일 보증금용 작업 증명 제안은 Adam Back의 Hashcash였고, 부분 해시 충돌을 사용했음
-
작업 증명이 작동하기 시작했을 때 악용자가 새 신원을 얻고 DDoS를 계속하는 걸 막는 건 무엇인지 궁금함
수정: 클라이언트가 아니라 공격받는 “서비스” 단위로 작업 증명이 설정되는 것 같음- 서비스별로 적용되고, Onion 서비스를 압도할 수 있던 상황에서 서버가 요청을 처리하는 것보다 더 많은 연산 자원을 써야 하는 상황으로 바뀜. 도움이 됨
- 맞음. 작업 증명은 요청별이기도 해서, 신원이 새것인지 기존 것인지는 상관없음
- 맞음, 클라이언트별이 아님. 클라이언트별이었다면 작업 증명을 요구하는 대신 악성 클라이언트를 차단하면 됐을 것임
익명성이나 자유롭게 새 신원을 만들 수 있는 특성 때문에 공격자는 시빌 공격으로 용량을 고갈시켜 서비스 거부를 일으킬 수 있음
-
여기서 시빌 공격을 더 우아하게 해결할 방법이 있는지 궁금함. 예를 들어 많은 CPU에는 프로세서마다 고유한 키 쌍이 들어 있고, 발급자 Intel, AMD 등의 CA 루트 인증서로 검증할 수 있음. 작업 증명을 연속 서명과 묶고 병렬 검증을 허용하면, 모든 작업 증명이 CPU별로 고유해져서 봇넷으로 병렬화할 수 없게 됨
이들은 봇넷 비용을 높이기 위해 메모리를 겨냥하는 것 같음. 이 공격 시나리오를 줄일 다른 방법도 많아 보임. 같은 논리를 ESIM을 쓰는 휴대폰에도 적용할 수 있을 듯함. 이후 이동통신망 인증은 공개키 암호를 쓰니 고유 증명도 가능할 것 같음
그냥 떠올린 생각이라, 이 방식의 뻔한 문제를 놓치고 있을 가능성이 큼- 불변 하드웨어 키와 제조사 인증 공급망을 기반으로 한 해법을 제안하는 거라면, Tor가 무엇인지 이해하고 있는지 묻고 싶음
- 다른 Onion 서비스 사용과 연결될 수 있는 방식으로 Onion 서비스에 신원을 증명하는 건 나쁜 결과를 낳을 수 있어 보임
- DDoS는 시빌 공격과 관계없음. DoS는 제한된 자원, 여기서는 연결 시작이 무료로 제공되기 때문에 발생함
메모리를 많이 쓰는 알고리즘을 고른 이유는 특정 하드웨어, 즉 ASIC 사용을 막기 위해서임 - 물론 Intel, AMD 등의 인증서를 신뢰하지 않는다면 이 방식은 동작하지 않음. 이 용도에서 왜 신뢰해야 하는지도 모르겠음
- “쌍을 이룬 클라이언트 연결을 기다리는 중”이라니 대단하긴 하겠음. 흥미로운 생각이지만 여러 문제가 떠오름
비슷한 방향으로, 서버가 여러 IP 풀을 들고 있고 클라이언트가 포트 노킹 증명을 반환하게 하는 건 어떨까 싶음. 예를 들어 토큰을 주고, 이 IP:포트로 보내고, 내가 검증할 수 있는 고유 응답을 기다리게 하는 식임. 이를 지연 시간 증명이라고 부를 수 있음. CPU 사용은 낮고 부하를 여러 머신과 포트로 분산할 수 있음. 단점은 당연히 여러 IP와 잠재적으로 여러 서버가 필요하다는 점임. 같은 머신에서도 구현할 수는 있겠지만, 그러면 CPU 부하가 포트 연결로 옮겨갈 뿐임
-
Tor 네트워크의 트래픽을 줄이거나 더 빠르게 만드는 아이디어가 있음. 네트워크를 CDN처럼 쓸 수 있어야 함. 파일을 공개하고 싶다면, 허락한 노드들에게 파일 조각을 보내고, 파일 요청이 오면 그 노드들을 가리킬 수 있어야 함
물론 Tor 네트워크가 “익명 토렌트 대체재”가 되어 목적을 훼손하지 않도록 주의해야 함
현재 제안은 “검증된 네트워크 트래픽 우선순위화”를 말함. 실제로 네트워크를 돕는 것이니 “파일 조각” 공유가 트래픽 우선순위를 높여줄 수 있다면 흥미로울 듯함. “작업 증명” 대신 대역폭 기여 증명이 되는 셈임- 그건 Tor보다는 콘텐츠 기반인 Freenet 모델에 가까움. Tor는 전통적으로 익명 TCP 실시간 네트워킹임
그래도 이게 네트워크 트래픽을 어떻게 줄이는지는 잘 모르겠음. 어차피 CDN 노드와 통신해야 함
- 그건 Tor보다는 콘텐츠 기반인 Freenet 모델에 가까움. Tor는 전통적으로 익명 TCP 실시간 네트워킹임
-
이 제안이 세운 목표와 한계를 보면 합리적이고, 아마 그 목표는 달성할 것 같음. 말했듯 소규모 봇넷에는 작동하겠지만, 대형 봇넷은 여전히 개별 클라이언트의 가용 자원을 압도할 수 있음
개인적으로 작업 증명을 좋아하지 않음. 여기서는 방어 메커니즘으로서의 비대화에 가깝고, 오래된 하드웨어를 빠르게 구식으로 만들 수 있으며, 영향받는 기기 전체로 보면 전력을 꽤 많이 쓸 가능성이 큼. 대규모로 적용되면 상당한 환경 부담이 됨
공격자 입장에서는 난이도를 그렇게 높게 만드는 것 자체도 성공으로 볼 것임. 사용자가 기기를 100%로 돌리며 1분을 기다려야 한다면 많은 경우 그냥 이탈할 테니까
그래도 사용자 익명성을 해치지 않으면서 DoS 공격을 완화하는 꽤 좋은 방식이라, 그 관점에서는 단점에도 불구하고 좋은 해법임. Tor에 존재하는 한 큰 문제는 없지만, 일반 웹에 적용된다면 완전한 재앙이라고 봄 -
글에서는 고급 서버와 저사양 휴대폰의 풀이 시간 차이가 6배뿐이라고 함. 이게 어떻게 가능한지 모르겠음. 서버는 휴대폰보다 RAM과 CPU 개수가 6배보다 훨씬 많고 CPU도 더 빠를 가능성이 큼
또한 DDoS라면 서버의 작업은 난처할 정도로 병렬화가 잘 되지만, 클라이언트 작업은 반드시 병렬화되지 않을 수 있음
그 차이가 6배, 혹은 1배뿐이라 해도, DDoS가 감지되면 풀이 시간이 1분이라고 함. 그 시점이면 서비스는 사실상 내려간 것 아닌가?- equihash라면 제한 요인이 메모리 대역폭이라고 알려져 있는데, 서버와 휴대폰 사이에서 그 차이가 생각보다 크지 않을 수도 있음
- 알고리즘 설명은 여기 좋음: https://github.com/tevador/equix/blob/master/devlog.md
DDoS가 감지되면 풀이 시간이 1분이라는 부분의 핵심은, 기존의 쉬운 DoS 공격인 introduction flooding을 부분 장애나 속도 저하로 바꾸는 것임. 어려운 문제에 대한 점진적 개선임 - 그 추정치는 적어도 한 자릿수, 어쩌면 두 자릿수 이상 틀렸을 것 같음. GPU 가속이 가능하다면 더 클 수도 있음