요약
Xray-core가 인증서 검증 우회 취약점을 조용히 고치고 반년 가까이 알리지 않았습니다.
취약점을 직접 신고한 사람이 검열 우회 커뮤니티 net4people 게시판에 경위를 공개했습니다. 신고자는 '인증서 검증 건너뛰기' 옵션을 깎아내리던 관리자들이 정작 자기 코드의 허점은 숨겼다고 비판합니다.
왜 중요한가
- 약 6개월 동안 이용자는 중간자 공격(통신 중간에서 엿보거나 바꾸는 공격)에 노출된 줄 모르고 지냈습니다.
- 보안을 이유로 사용자 선택지를 줄인 설계가 오히려 방어를 한 곳에 몰아 위험을 키운 사례입니다.
핵심 내용
- 2026년 1월 도입한 pinnedPeerCertSha256 옵션은 공격자가 체인 아무 곳에 끼워 넣은 인증서도 고정된(미리 믿기로 한) 인증서로 받아들였습니다.
- 1월 16일부터는 이 옵션을 쓰면 일반 인증서 검증을 늘 건너뛰어, 고정 검사가 뚫리면 남는 방어가 없었습니다.
- 2월 6일 비공개 신고 당일 고쳤지만 커밋 메시지는 "코드 단순화"였고, v26.2.6 릴리스에도 보안 언급이 없었습니다.
- 7월 3일 신고자는 수정이 불완전해 특정 조건에서 여전히 우회된다는 점을 찾아 GitHub 보안 권고로 신고했습니다.
- 관리자들은 allowInsecure 옵션을 쓰면 사용자가 "알몸"이 된다고 비판해 왔고, 신고자는 이를 위선이라고 지적합니다.
HN 반응
- 코드 수정은 사고 대응의 절반일 뿐이며, 보안 공지와 영향받는 버전 범위가 없으면 이용자는 위험한지 알 수 없다는 지적이 나왔습니다.
- Xray를 누가 쓰느냐는 질문에 러시아에서는 외부 인터넷으로 나가는 사실상 유일한 터널이라는 답과, TLS는 앞단 리버스 프록시에 맡기라는 조언이 나왔습니다.
Xray는 쓰는 사람 대부분이 중국 본토에 있는 것 같던데, 다른 곳에서도 많이 쓰나요? 안 쓴다면 왜 그럴까요?
순진하게 생각하면, 중국 본토는 인터넷 규제가 있고 인터넷에 연결된 사람도 많으니까 그쪽에서 나온 솔루션이 더 정교할 거라고 기대하게 되거든요.
그래도 방화벽(GFW) 밖에서는 보기 힘든 용도를 겨냥한 걸지도 모르겠네요.
캡티브 포털(captive portal)에서 일부 트래픽만 허용될 때 우회하는 데도 쓸 수 있습니다. 메신저 서비스를 무료로 쓰게 해주는 일부 항공편은 SNI만 확인하기 때문에, Xray 도메인을 whatsapp.com 같은 것으로 설정하면 대개 통합니다.
ESNI/ECH를 쓰고 있으면 어떻게 되나요?
캡티브 포털의 DNS를 쓰도록 설정해야 할 텐데, 그러면 ECH가 무력화될 거라고 생각합니다. 제가 캡티브 포털 우회에 성공했던 유일한 경우에는 Xray 호스트를 원격 IP로 하드코딩해 둔 상태였기 때문에 DNS는 문제가 되지 않았습니다.
그게 어떻게 가능한지 모르겠네요. DNS 요청은 기술적으로 웹 요청과 아무 연결이 없잖아요. 가끔 시간상 가깝게 발생할 뿐이고, 캐싱 때문에 그마저도 항상 그런 건 아니고요.
캡티브 포털에는 그냥 1.2.3.4로 접속하면 되긴 하죠. 하지만 제 질문은 "SNI도 암호화돼 있는데 어떻게 SNI를 기준으로 허용할 수 있느냐"에 가까웠습니다.
DNS 서버가 뭐든 간에, 제가 웹사이트로 보내는 접속 요청은(진짜 메신저 사이트든, 가짜 xray 사이트든, 뭐든) ECH를 쓸 수 있는데, 그 경우에 어떻게 요청을 허용할 수 있죠? 그 메신저 서비스들이 ECH를 쓸지 말지를 그쪽에서 통제할 수 있는 것도 아닐 거고요.
ECH는 DoH를 통해 부트스트랩됩니다. 제 기억으로는 초기 핸드셰이크 암호화에 쓰는 키를 배포하는 TXT 레코드 같은 것이 있습니다.
DoH만 막아도 클라이언트가 일반 DNS로 되돌아가게 만들기에는 아마 충분할 겁니다. 화이트리스트를 쓰는 캡티브 포털에서는 이런 일이 자동으로 일어납니다. 캐시를 가진 클라이언트는 읽을 수 있는 SNI가 없는 연결을 그냥 끊어버리면 처리할 수 있을 테고요. 구현에 따라 다르겠지만, 대부분의 클라이언트는 어차피 ECH 없는 연결로 되돌아갈 거라고 봅니다(사실 ECH가 별로 보탬이 되지도 않으니까요. DNS만 엿봐도 클라이언트가 어느 도메인에 접속하려는지 알 수 있잖아요).
하지만 모두가 DHCP가 알려주는 DNS를 쓰도록 시스템을 설정해 두는 건 아니고, 브라우저나 일부 기기는 기본값으로(또는 옵션으로) 다른 공용 DoH 제공자로 덮어쓰기도 하잖아요. 그걸 막으면 접속이 안 되는 사람이 너무 많아질 겁니다.
그 메신저 서비스 IP만 단순하게 차단하거나 화이트리스트에 올리는 편이 이런 SNI 얘기보다 훨씬 쉬울 것 같아요. 어차피 xray 방식으로 가더라도, 특정 SNI의 인증서를 진짜 인증서와 대조해서 확인하지 못하게 막을 방법도 없고요.
Xray는 지금 러시아에서 엄청나게 쓰입니다. 바깥 인터넷으로 터널을 뚫을 유일한 방법인 경우도 많고요.
보고된 취약점에 대해서는, 그래도 Xray를 리버스 프록시 뒤에 두고 TLS 관련 처리는 그쪽에 맡기는 편이 낫다고 생각합니다.
이란이나 러시아처럼 트래픽을 일상적으로 차단하는 나라가 또 있습니다. 그런데 GFW를 그냥 통과해 버리는 간단한 방법도 꽤 많습니다. 일반 TLS로 터널링한 VPN 트래픽이나 심지어 평범한 SSH 같은 것들이죠.
요즘 "새로 뜨는 방식"은 TLS 핑거프린트를 무작위로 바꾸고 정상적인 웹 트래픽·도메인인 척 위장하는 것, 그리고 여러 엔드포인트를 동시에 쓰는 터널/프록시/VPN 구성으로 모든 트래픽이 한 호스트로만 계속 나가면서 생기는 "의심"을 분산시키는 것입니다.
Xray-core의 pinnedPeerCertSha256은 끼워 넣은 리프 인증서를 고정(pin)된 인증서로 취급했는데, 수정 커밋은 이를 취약점이라고 한 번도 부르지 않았습니다.
당신의 LLM이 뻔한 위선이랑, 수정된 버전에도 여전히 취약점이 있었다는 대목은 빼먹었네요.
그분 댓글은 실제로 가치를 더했는데, 당신 댓글은 같은 가치가 있어 보이지 않네요.
제 댓글은 빠졌다고 생각한 내용을 구체적으로 짚었는데요?
코드를 고치는 건 사고 대응의 절반일 뿐입니다. 보안 공지, 영향받는 버전 범위, 다운스트림 통지가 없으면 사용자는 자신이 계속 노출돼 있는지 알 수 없습니다.
Xray-core를 둘러싼 반응은 실망스럽습니다.