▲

Matrix를 포기한 이유 (2024)

 (forum.hackliberty.org)
1P by GN⁺ 13일전 | ★ favorite | 댓글 1개
  • Matrix 프로토콜의 구조적 보안 한계와 운영상의 문제로 인해 Hack Liberty 커뮤니티가 SimpleX로 이전함
  • 메타데이터 노출, 관리자 권한 남용, 암호화 취약점 등으로 인해 사용자 프라이버시와 안전이 심각하게 훼손됨
  • Matrix.org 조직이 수집하는 개인 데이터와 Cloudflare 중간자 개입, Tor 브라우저 지원 중단 등도 신뢰 저하 요인으로 지적됨
  • SimpleX는 사용자 식별자 없이 메시지를 전달하고, 2-hop onion 라우팅과 포스트 양자 암호화 키 교환으로 보안을 강화함
  • 이러한 전환은 탈중앙화 커뮤니티의 보안·프라이버시 확보를 위한 실질적 대안으로 제시됨

연합형 프로토콜의 한계

  • 연합형(federated) 네트워크는 여러 서버 간 상호작용을 통해 검열 저항성을 제공하지만, 설계상 근본적인 보안 문제를 내포함
    • 2년 이상 Matrix와 Lemmy 같은 공개 연합 서비스를 운영한 결과, 모든 연합형 프로토콜이 공통적으로 갖는 구조적 결함이 확인됨

Matrix 프로토콜의 문제점

메타데이터 노출

  • Matrix는 메시지 송신자, 닉네임, 프로필 사진, 반응, 읽음 표시, 타임스탬프 등이 암호화되지 않음
    • 메시지 검증, 성능 요구, 프로토콜 설계 미비 등으로 인해 일부 메타데이터 노출이 의도적 혹은 설계적 결함으로 존재
    • 예시 링크로 실제 누출 사례가 제시됨

관리자 중간자 공격(Admin in the Middle)

  • 악의적인 서버 관리자는 Synapse 데이터베이스 조회만으로 사용자 정보, 반응, 방 메타데이터 등을 수집 가능
    • 사용자 사칭, 방 주제 변경, 임의 초대·추방, 권한 조작 등 적극적 공격 수행 가능
    • 새 기기를 추가해 E2EE 메시지 접근도 가능하며, 사용자 경고를 무시하도록 설정할 수도 있음

프로토콜 구조적 약점

  • Matrix는 부분 복제 그래프 데이터베이스 형태로 동작하며, 다음과 같은 22가지 주요 취약점이 지적됨
    • 삭제 불가 이벤트, 스팸 취약성, 이력 불일치, 메시지 위조 가능성, 선택적 암호화, 서명 불일치, Split-brain 방 생성, 불법 미디어 복제 위험 등
    • 서버 간 상태 불일치로 인해 관리 권한 상실이나 방 폐쇄 불가 문제가 발생

Megolm 암호화 취약점

  • Matrix의 Megolm 프로토콜에서 다수의 실질적 암호학적 취약점이 보고됨
    • 기밀성 붕괴, 검증 공격, 신뢰된 사칭, IND-CCA 공격 등 다양한 공격 시나리오 존재
    • 공격은 서버 협조를 전제로 하며, Element 클라이언트의 핵심 라이브러리(matrix-js-sdk 등) 에서 재현 가능

리소스 과소비

  • Synapse 서버는 높은 CPU, 메모리, 디스크, 대역폭을 요구
    • 사용자 수에 따라 4~12개의 인스턴스가 필요하며, 운영 비용이 과도함

Matrix.org 조직의 문제

데이터 수집

  • matrix.org와 vector.im은 사용자 이메일, 전화번호, IP, 기기 정보, 사용 패턴, 대화방 ID 등을 정기적으로 수집
    • 기본 설정에서 개인정보가 공개되며, 업로드된 파일·이미지·프로필 정보가 공개 접근 가능
    • 자체 서버를 사용하더라도 중앙 서버로 민감 데이터가 전송됨

아동 성착취물 유통

  • Matrix.org의 느린 대응으로 인해 수만 명의 소아성애자들이 불법 콘텐츠를 유포
    • 방 폐쇄 불가, 미검증 미디어 업로드, 자동 복제 기능으로 인해 불법 자료가 연합 전체에 확산
    • 각 홈서버가 불법 콘텐츠를 호스팅할 가능성이 높음

Cloudflare 중간자 개입

  • matrix.org와 vector.im의 TLS 트래픽이 Cloudflare에서 종료됨이 확인되어, 중간자 공격 가능성 존재

Tor 브라우저 지원 중단

  • Element 웹클라이언트가 Tor 브라우저를 더 이상 지원하지 않음
    • Tor의 구버전 Firefox 기반, 테스트 불가, 자금 부족 등을 이유로 지원 계획 없음으로 종료

Lemmy 관련 문제

  • Matrix와 동일한 연합형 구조로 인해 데이터 복제, 검열, 불법 콘텐츠 책임 문제가 동일하게 발생
    • “de-federation”을 통한 검열형 탈중앙화, 집단사고(groupthink) 유도, 업·다운보트 조작 등으로 자유로운 토론이 제한됨

SimpleX로의 전환

식별자 없는 통신 구조

  • SimpleX는 사용자 식별자(전화번호, 이메일, 공개키 등)를 전혀 사용하지 않음
    • 각 대화마다 독립된 단방향 메시지 큐 주소를 사용해 상대방과의 연결을 익명화
    • 향후 자동 큐 교체 기능으로 서버 간 이동 및 추적 방지 지원 예정

스팸 및 남용 방지

  • 초대 링크나 임시 주소를 직접 공유해야만 연락 가능, 원치 않는 접근 차단
    • 주소 변경 또는 삭제로 스팸 완전 차단 가능

데이터 완전 소유

  • 모든 사용자 데이터는 클라이언트 기기에만 저장, 서버는 임시 릴레이 역할만 수행
    • 서버 간 트래픽에서도 송수신자 식별 불가, 추적 불가능한 메시지 전달 구조

사용자 운영 네트워크

  • 누구나 자체 SimpleX 서버를 운영할 수 있으며, SDK와 오픈 프로토콜로 봇·서비스 개발 가능

Matrix와의 비교

항목 SimpleX Matrix
암호화 이중 암호화 + 포스트 양자 키 교환 Megolm (취약점 존재)
메시지 라우팅 2-hop onion 라우팅 연합형 구조, 메타데이터 노출
탈중앙화 중앙 구성요소 없음 중앙 부트스트랩 노드 존재
미디어 처리 로컬 암호화 및 수동 큐 회전 미검증 업로드, 자동 복제
Tor 지원 지원 및 onion 라우팅 제공 지원 중단
Cloudflare 비사용 TLS 종료 Cloudflare

SimpleX의 기술적 특징

  • 더블 래칫 기반 종단간 암호화, 포스트 양자 키 교환, 2-hop onion 라우팅
  • Tor 및 SOCKS 프록시 지원, TLS 1.2/1.3 보안 채널, 재전송 방지 서명 구조
  • 완전한 탈중앙 네트워크, Flux 통합으로 메타데이터 보호 강화

사용자 경험 및 추가 기능

  • E2EE 음성·영상 통화, 암호화된 알림, 로컬 파일 암호화, 메시지 편집·반응, 배터리 절약형 그룹 채팅
  • 익명 모드, 콘솔 클라이언트, 봇 SDK, Linode 원클릭 서버 배포 등 다양한 확장 기능 제공

향후 로드맵

  • 안정성 향상, 대규모 커뮤니티 지원, 프라이버시·보안 슬라이더, 에페메랄 대화, 위치 공유, 자동화 규칙 등 개발 예정

결론: Hack Liberty는 Matrix의 구조적 보안 결함과 운영 불신으로 인해 SimpleX 기반의 완전한 프라이버시 중심 네트워크로 이동함. SimpleX는 식별자 없는 통신, 강력한 암호화, 탈중앙 구조를 통해 차세대 안전한 커뮤니티 플랫폼으로 제시됨.

▲
GN⁺ 13일전  [-]
Hacker News 의견들

  • 나는 Matrix가 성공하길 정말 바랐지만 이제 완전히 포기했음
    상태 해결(state resolution) 시스템이 너무 복잡하고 자원 소모가 심함. 방이 망가지는 일도 여전히 발생함. 단순히 방의 멤버 리스트를 계산하는 것조차 DB 용량이 수 GB에 달할 정도로 비효율적임.
    게다가 몇 년이 지나도 커스텀 이모지, 사용자 상태, 초대 링크 같은 기본 기능조차 없음
    관련 이슈: #339, #573, #426
    요즘은 SimpleX가 Signal과 비슷한 타깃을 노리지만 다른 접근을 취하는 것 같아 흥미로움. 다만 아직 대중적으로 확산된 느낌은 없음

    • 나도 Matrix가 성공하길 바랐지만 절반쯤 포기한 상태임. 예전엔 Synapse 홈서버를 직접 운영했는데, 리소스 소모가 너무 심했음. 그래서 다시 XMPP로 돌아감. 단순히 채팅만 제공하려면 XMPP가 훨씬 효율적임. SimpleX는 아직 좀 더 성숙해질 때까지 기다릴 생각임
    • 상태 해결 문제는 Project Hydra 이후로 많이 개선되었음. DB 용량 문제는 Synapse의 저장 효율성 문제 때문임. 내가 이 영상에서 해결 방법을 보여줬지만, 우선순위는 상태 리셋 수정이었음.
      커스텀 이모지나 사용자 상태 같은 기능은 이미 MSC 제안이 존재하고 구현이 진행 중임. 2023년 이후 자금난으로 생존을 위해 정부 프로젝트 위주로 개발을 집중했기 때문임
    • XMPP 써봤는지 물어보고 싶음
    • 나는 1년 정도 SimpleX를 기본 서버로 사용했는데 잘 작동했음. Signal 그룹을 SimpleX로 옮기려 했지만 실패했고, 결국 사용이 중단됨
    • 나는 몇 년째 같은 Matrix 방을 유지 중임

  • 나와 내 주변 사람들은 Matrix 경험이 매우 긍정적이었음. Beeper와 Element를 통해 수십 명의 비기술 사용자들을 온보딩했는데, 다들 잘 쓰고 있음. 기기 변경도 문제없고, Discord와 비교해도 UX가 꽤 경쟁력 있음.
    그래서 HN에서 나오는 불만들이 이해가 안 됨. 아마도 오래된 서버나 비호환 클라이언트를 쓰는 게 아닐까 추측함

    • Matrix가 거의 완성 단계에 가까워서, 남은 결함에 사람들이 더 민감하게 반응하는 것 같음. 최근 몇 년간은 공공 부문 배포에 집중하느라 Discord 경쟁 기능은 후순위였음
    • 셀프 호스팅은 괜찮았지만, Discord에서 옮겨온 사람들에게는 초대 링크나 등록 절차가 너무 복잡했음. 특히 음성 채팅 시스템 변경으로 기존 설치가 깨졌고, 문서화도 부족했음
    • 나도 개인 서버를 ansible 스크립트(matrix-docker-ansible-deploy)로 관리 중인데, 안정적으로 잘 작동함. 아마도 공용 서버(matrix.org) 와의 경험 차이일 듯함
    • 나도 문제 없이 잘 쓰고 있음. 친구들과의 소규모 채팅에서는 완벽하게 작동함
    • 보안 측면에서의 경험은 어떤지 궁금함

  • SimpleX가 “사용자 식별자가 없다”고 주장하지만, 실제로는 IP 주소가 그대로 노출됨. 전체 퍼블릭 네트워크가 Akamai와 Runonflux 두 회사에 의해 호스팅되고 있음.
    Tor를 기본 번들로 제공하고, IP 마스킹 옵션을 명확히 설명해야 함. 현재는 “추가 식별자를 만들지 않는다”는 의미일 뿐, IP 자체는 보호되지 않음

    • 나는 SimpleX 네트워크 설계자임. IP 주소는 인터넷 식별자이지 SimpleX 식별자가 아님. SimpleX의 목표는 IP 간 상호 연관을 막고, 사용자가 선택하지 않은 서버로의 노출을 방지하는 것임.
      Tor를 내장하지 않는 이유는 FAQ에 설명되어 있음
    • SimpleX가 자체 암호화폐를 만들려는 움직임이 있어서 걱정됨

  • 나는 Matrix에 대한 의견은 없지만, Nebuchadnezzar 논문을 꼭 읽어보길 권함. 그룹 보안 메시징의 핵심은 암호화가 아니라 그룹 멤버십 관리임
    논문 링크

    • 여기에 FOKS(https://foks.pub) 같은 시스템을 결합하면 흥미로울 것 같음
    • 처음 Matrix 프로토콜 문서를 읽었는데, 분산 시스템 이해가 부족한 사람이 만든 듯한 인상임. Lamport clock이나 virtual synchrony 개념도 없이 IRC와 XMPP를 섞은 느낌임.
      여러 번의 DAG 정렬 시도로 합의를 시도하는 부분에서 프로젝트가 근본적으로 잘못되었다는 생각이 들었음. 차라리 NNTP + GnuPG로 직접 그룹 채팅을 만드는 게 나을 듯함

  • Matrix의 연말 업데이트를 올렸음: Matrix Holiday Special 2025
    모두 즐거운 연말 보내길 바람 :)

  • 나는 6년째 Matrix를 사용 중임. 2020년 대규모 유입 때는 힘들었지만 지금은 안정적임.
    여전히 Element Web의 버그와 느림이 불만이지만, 가벼운 대안 클라이언트들이 많음.
    메타데이터 암호화는 아직 완전하지 않지만, 내 일상 대화에서는 큰 문제 아님.
    Matrix를 계속 쓰는 이유는 분산형 구조, E2EE, 멀티디바이스, 자유 소프트웨어, 셀프 호스팅 가능성 등 대체 불가능한 조합 때문임.
    프로젝트 리더의 침착한 리더십도 신뢰감을 줌

    • 나도 동의함. Element Web의 메모리 누수 문제 때문에 커스텀 포크를 쓰고 있음(이슈 링크).
      matrix-rust-sdk로 전환되면 큰 개선이 있을 듯. Aurora 프로젝트도 기대됨
    • XMPP도 거의 같은 기능을 훨씬 적은 자원으로 구현 가능함. 영상 통화에는 TURN 서버가 필요하지만 잘 작동함

  • Moxie (Signal 창립자) 가 2020년 CCC에서 연합형(federation) 시스템의 문제를 지적한 강연이 있음.
    영상 링크

  • “Why Federation Must Die” 주장에는 동의하지 않음. 연합형은 어렵지만, Chatcontrol 같은 규제 속에서도 EU 내에서 안전한 통신을 유지할 유일한 방법임.
    중앙화된 시스템은 한 조직만 압박하면 되지만, 연합형은 모두가 서버를 운영하므로 통제하기 어려움

    • 그 글은 연합형이 아니라 완전한 탈중앙화를 주장하는 내용임
    • 나도 연합형을 지지함. Mastodon을 보면 중앙화보다 자유로운 구조가 얼마나 중요한지 알 수 있음. 발견성(discoverability)은 어렵지만, 그만큼 자율성이 큼

  • 반(反) 빅테크 진영은 사실 여러 가치관의 연합체임.
    한쪽은 연합과 자율성을, 다른 쪽은 암호화와 프라이버시를 우선시함.
    서로의 우선순위가 다르다는 걸 인식하면, 완벽히 일치하지 않아도 더 관대한 협력이 가능할 것 같음

    • 나도 같은 생각임. 나는 자기 호스팅과 상호운용성을 중시하지만, 다른 사람들은 E2EE와 메타데이터 최소화를 더 중요하게 봄.
      Matrix 같은 프로젝트가 이 두 진영을 모두 만족시키기란 거의 불가능함.
      게다가 보안·프라이버시 진영의 목소리가 더 크기 때문에, 담론이 실제보다 부정적으로 들릴 때가 많음

  • 올해 우리는 Matrix의 메타데이터 보호를 개선 중임.

    • MSC4362: 룸 상태 암호화
    • MSC4256: 송신자 제거 및 MLS 기반 암호화
      과거에는 분산형 암호화 안정화에 집중하느라 메타데이터 보호가 후순위였음.
      또한 네트워크 트래픽 자체가 이미 많은 메타데이터를 노출하기 때문에 완전한 은닉은 어려움.
      그래도 2026년에는 더 나은 개선이 예정되어 있음
      참고로 2016년 발표 자료도 있음: Matrix Jardin Entropique (PDF)
      일부 주장(예: 중앙 서버로 데이터 전송)은 사실이 아님. 미디어 인증은 2024년 6월부터 적용되었고, 2025년에는 신뢰·안전 팀도 강화됨
    • 사람들은 스스로 호스팅하고 싶어 하지만, 결국 유료 호스팅 서비스를 원하게 됨. 보안 이슈가 많다면 오히려 호스팅 비즈니스 기회가 될 수도 있음
    • “직접 서버를 운영하라”는 태도는 장기적으로 지지를 얻기 어려움. 일반 사용자가 반(半)시스템 관리자가 되길 기대하는 건 현실적이지 않음
답변달기