탈중앙 코드 협업 도구인 Radicle이 자사 노드 간 네트워크 프로토콜에서 두 건의 심각한 보안 취약점을 공개했다. Radicle은 Git 위에 구축된 P2P·로컬 우선(local-first) 방식의 코드 협업 스택으로, 중앙 서버 없이 개발자들이 서로의 저장소를 직접 동기화한다는 점을 내세워 왔다. 이번 발표에서 개발팀은 지금까지 배포된 모든 버전이 이 문제에 노출되어 있으며, 수정판이 나오기 전에 먼저 사실을 알린다는 점을 분명히 했다. 즉, 사용자는 오늘 당장 대응할 수 있지만 나중에 배포될 어떤 패치도 이미 발생한 노출을 되돌리지는 못한다.
문제의 핵심은 평문 전송
첫 번째이자 근본적인 결함은 노드 간 트래픽이 암호화되지도, 인증되지도 않는다는 데 있다. 다만 Radicle은 저장소 콘텐츠를 서명된 참조(Signed References)로 검증하기 때문에, 전송 경로 중간에 있는 공격자가 객체를 위조하거나 변조하면 이를 탐지할 수 있다. 따라서 실질적인 위협은 위조가 아니라 정보 유출, 즉 경로상의 공격자가 오가는 객체를 그대로 읽어낼 수 있다는 점이다. 공개 저장소라면 유출의 의미가 크지 않지만, 비공개 저장소에서는 전송 구간 암호화가 결정적으로 중요하다. 개발팀이 수정판이 나올 때까지 비공개 저장소 사용을 중단할 것을 권고한 이유가 여기에 있다.
두 번째 결함은 허용 목록(allow-list)에 등록된 Node ID를 사칭할 수 있다는 것인데, 단독으로는 들리는 것만큼 악용하기 쉽지 않다. 사칭하려면 유효한 Node ID를 알아야 하고 허용 목록은 공개되지 않으므로, 경로 밖에 있는 공격자는 이를 추측하는 수밖에 없다. 문제는 두 결함이 결합될 때다. 연결 경로상에 있는 공격자는 양쪽 끝단의 Node ID를 볼 수 있고 이들은 대개 허용 목록에 올라 있다. 그러면 공격자는 지켜보는 동안 오가는 내용을 읽는 것을 넘어, 확인한 Node ID를 이용해 원하는 시점에 저장소 전체를 통째로 가져올 수 있다. 현실적인 위협은 내 노드와 동기화 상대 노드 사이 경로에 자리 잡을 수 있는 누구든이며, 어떤 설정이나 허용 목록도 이를 막지 못한다.
지금 할 수 있는 임시 조치
개발팀이 제시한 완화책은 비공개 저장소를 사실상 배포하지 않는 것이다. 먼저 스토리지에 보관된 비공개 저장소 목록을 확인한 뒤, 개별 저장소의 시딩(seeding) 정책을 하나씩 '차단(block)'으로 바꾸는 방식이다. 이때 rad unseed 대신 rad block을 쓰라는 권고가 실무적으로 중요하다. rad unseed는 저장소의 시딩 정책을 제거해 노드의 기본 정책으로 되돌리는데, 기본값이 block인 표준 설정에서는 이것으로 충분하다. 그러나 기본 정책을 allow로 바꿔 둔 노드라면 unseed 이후에도 저장소를 계속 제공하게 된다. 반면 rad block은 명시적 차단을 설정하고 노드가 이를 우선 확인하므로 어느 설정에서든 안전하게 동작한다.
한 가지 분명히 해 둘 점은, 두 결함 모두 노드 전송 계층에 있을 뿐 저장소 데이터 모델에는 영향이 없다는 것이다. Git 객체와 서명된 참조는 기존과 동일하게 스토리지 계층에서 검증되며, 공격자가 코드나 신원을 위조할 수는 없다. 이번 사안은 데이터 무결성이 아니라 전송 구간의 기밀성 문제로 좁혀서 이해하는 편이 정확하다.
해법은 프로토콜 자체의 교체
근본 수정은 Radicle이 자체 개발한 프로토콜(Noise 기반)을 iroh로 교체하는 방향으로 진행된다. iroh는 개방형 표준 위에 만들어진 오픈소스 P2P 네트워킹 스택으로, 개발팀은 이미 마이그레이션 계획을 공유한 바 있으며 이번 취약점이 전환을 앞당길 추가 명분이 됐다고 밝혔다. iroh는 취약점 해소뿐 아니라 NAT 통과 같은 기능을 제공해 네트워크의 안정성과 복원력도 높인다고 한다.
다만 대가도 분명하다. 버전 협상 기능이 없고 수정 내용이 전선(wire) 수준에서 호환되지 않기 때문에 하위 호환 완화가 불가능하며, 결국 메이저 버전을 올리는 파괴적 릴리스가 된다. 전송 방식이 바뀌면 네트워크는 업그레이드된 클러스터와 그렇지 않은 클러스터로 분할되어 서로 통신하지 못한다. 개발팀은 파괴 범위를 네트워크 쪽으로 한정하고 스토리지 레이아웃 호환성은 유지해 업그레이드 경로를 최대한 부드럽게 만들겠다고 설명했다. 실무자 입장에서는 단순한 패치 적용이 아니라 네트워크 전환에 맞춰 조직 내 노드들을 동시에 업그레이드해야 하는 계획으로 접근할 필요가 있다. 이번 취약점은 Konstantinos Maninakis와 cryptocode의 책임 있는 제보로 알려졌으며, 보안 이슈 신고 절차는 Radicle의 security.txt에서 확인할 수 있다.