Radicle 노드 간 트래픽에 암호화와 인증이 없었다, 개발사가 비공개 저장소 사용 중단 권고

화려한 공격 체인을 예상했는데 정작 결론은 "암호화를 깜빡했다" 수준이라 허탈함.

이런 실수는 생각보다 흔함. JWT의 alg:none이랑 같은 결이고, 보안 기능이 꺼져 있으면 그냥 즉시 실패하도록 설계해야 함.

거기에 인증도 없지. 핸드셰이크에서 Node ID 위장이 되는데 공개문은 되게 점잖게 써놨더라. 결국 암호화도 인증도 없는 거임. 만든 사람이 애초에 신경을 안 쓴 거지.

2026-06-24에 접수해놓고 3개월 뒤에 공개한 것도 별로임. 지금 대책이 "비공개 저장소 쓰지 말라"인데.

그리고 유저 가이드랑 FAQ는 아직도 비공개 저장소가 "네트워크의 나머지에 완전히 안 보인다"고 써있음. 문서도 아직 안 고쳤더라.

나한테는 오늘에서야 이메일이 처음 왔는데 "블로그로 상세 내용을 이미 알고 있을 거다"고 하더라고. 전혀 몰랐는데?

이름이 같은 radicale, 그 캘린더·연락처 동기화 소프트웨어 얘기인 줄 알았네. 아 다행히 그건 아니구나.

혹시 cyphernet-labs/netservices.rs를 쓰는 Nym이나 Farcaster 같은 프로젝트도 암호화랑 인증을 당연히 된다고 믿고 있었던 거 아닐까?

curl | sh 설치부터 아마추어 냄새가 나더니 이런 보안 공개까지. 전체가 아마추어 같음.

팀이 3명이라 보안팀도 전담 테스터도 없는 거임. 한동안 베타였고 실제로는 잘 동작했고.

그건 그렇고 curl 파이프 셸 설치는 대기업들도 리눅스 안내에 여전히 씀. 그건 별개 문제임.

3개월 전에 보고됐는데 대책이 "다 유출됐다고 치라"는 게 어이없음. 노드 간 트래픽이 암호화가 안 되는 걸 만든 사람이 어떻게 몰랐지?

암호화 신원 탈중앙화 기법은 다 해놓고 정작 네트워크 트래픽은 손도 안 댔다니. 나중에 하려다가 TODO에서 빠진 건가?

블로그를 읽어보니 Cyphernet 라이브러리를 암묵적으로 신뢰한 것 같음. 별 10개짜리 저활동 의존성을 검증 안 한 건데 사후에 보면 뻔함.

커스텀 프로토콜 버리고 iroh로 간다니 다행이긴 함. 이게 직접 만드는 거의 문제임.

근데 QUIC이 트래픽 위장이 된다는 건 과장임. QUIC은 지문 분류가 쉬움. iroh도 QUIC multipath가 아직 표준화가 안 됐는데 자랑만 잔뜩임.

이 프로젝트는 눈여겨봤는데 늘 뭔가 찜찜했거든. 이번에 아예 확정됐음. 비밀로 둘 거면 못 쓰는 물건임.

평문 전송이 애초에 설계 선택이었나? 이건 일반적인 취약점 치고 누락이 너무 큼.

그냥 mTLS over QUIC을 쓰면 됨. 표준화돼 있고 인증서 검증 생태계도 있는데 뭘 또 직접 만드는지 모르겠음.

다만 사용자 쪽 인증서 생태계는 아직 안 익었음. 안드로이드 폰에 인증서 넣는 게 엄청 고생이었고, 집에서 쓰는 앱들도 대부분 인증서를 못 씀.