@Iam54r1n4 @iyedoost دم کلاد گرم. ما صرفا داشتیم هرکاری میکردیم که leak نداشته باشیم.
ولی من حس میکنم که اطلاع ندارن. کلاد میگفت یکی از فیکس هاش اینه که draft کردن که پاکش کنن اصلا و دقیقا پرفورمنس رو میاره پایین.
Xray-core#6110 t.co
1 like · 31 views
Nếu Việt Nam có Vạn Lý Tường Lửa
Nếu ngày mai có đi thì chúng ta tính sao giờ?
Chào nha nếu tò mò hãy đọc tiếp, bài viết này có thể sẽ trùng 1 vài bài viết trong quá khứ hay trên mạng gì đó nhưng tui đăng lại coi như là kiến thức tui tự học hỏi được nên tiện chia sẻ lại thôi. Ai rảnh thì ôn lại kiến thức chung luôn với tui.
Bây giờ nếu Việt Nam giờ có 1 vạn lý tường lửa và thành mini China thì làm sao để vượt? Tui sẽ chỉ 1 vài khái niệm bỏ túi để nếu nó xảy ra trong tương lai gần còn biết cách ứng phó. Tui sẽ cố mô phỏng lại những gì đã và đang xảy ra ở Trung Quốc ngắn nhất và dễ hiểu, vì nó ngắn nên có thể sẽ sai và thiếu sót nhưng ai biết được và đây cũng không phải là hướng dẫn kỹ thuật hay phân tích kỹ thuật từ A-Z. Bạn tự lo liệu lấy sau khi đọc xong đi.
Khái niệm
Nói chung 1 khi đi qua nhà mạng kiểu gì cũng sẽ bị họ kiểm soát nhưng quan trọng ta phải đoán ở 1 mức độ nào? Và để biết mức độ nào trước hết để phải hiểu được cơ bản cách mạng máy tính hoạt động, đây là sơ đồ cơ bản nhất cho dễ hình dung.
Hình 1: Mô phỏng đơn giản mạng máy tính hoạt động
Thiết bị cần địa chỉ IP để giao tiếp trên mạng IP, nhưng không phải mỗi máy luôn có một IP công khai riêng. NAT, IPv4 dùng chung, Ipv6 và địa chỉ IP động khá phổ biến. Có rất nhiều giao thức và mỗi ứng dụng sẽ xài các giao thức khác nhau để giao tiếp có thể kể tên như HTTP/HTTPS, DNS, SMTP, WebSocket, WebRTC, ... còn rất nhiều nữa nếu liệt kê cũng quá dài cho 1 bài post ngắn.
1. Chặn DNS (Domain Name System)
Như đã nói, địa chỉ IP là các con số khó nhớ nên chúng ta sử dụng DNS để phân giải tên miền, chẳng hạn từ example.com sang địa chỉ IP tương ứng.
Khi người dùng truy cập một website, thiết bị thường cần hỏi máy chủ DNS để tìm địa chỉ IP của tên miền đó. Nếu nhà mạng can thiệp vào quá trình này, họ có thể trả về địa chỉ sai, trả về trang cảnh báo hoặc khiến truy vấn thất bại.
Giải pháp: Đổi nhà cung cấp DNS khác như Cloudflare hoặc Google. Tuy nhiên, đổi DNS không phải giải pháp vạn năng: nếu nhà mạng chặn trực tiếp IP, chặn kết nối HTTPS hoặc dùng những phương pháp khác thì việc đổi DNS sẽ không giải quyết được vấn đề. Ngoài ra, DNS thông thường và DNS mã hóa như DoH, DoT cũng khác nhau. DNS mã hóa giúp bảo vệ truy vấn trên đường truyền, nhưng bản thân nó không đảm bảo mọi kết nối đến website đều không thể bị chặn.
Hình 2: Mô phỏng đơn giản sử dụng DNS thành công
2. Chặn địa chỉ IP
Đây là cách chặn dựa trên địa chỉ mạng đích thay vì phải xác định chính xác nội dung của website.
Ví dụ, nếu một website được lưu trữ tại địa chỉ IP 203.0.113.10, nhà mạng có thể thiết lập quy tắc khiến lưu lượng đến địa chỉ đó bị loại bỏ hoặc không thể thiết lập kết nối.
Người dùng có thể vẫn phân giải được tên miền thành IP, nhưng khi trình duyệt cố gắng kết nối đến máy chủ, kết nối sẽ thất bại hoặc hết thời gian chờ.
Nhược điểm của phương pháp này là nhiều website có thể cùng sử dụng một địa chỉ IP, chẳng hạn khi chúng được lưu trữ trên cùng một máy chủ hoặc sử dụng chung hạ tầng CDN. Chặn một IP trong trường hợp đó có thể ảnh hưởng đến nhiều dịch vụ không liên quan.
Ngược lại, một website cũng có thể sử dụng nhiều địa chỉ IP khác nhau. Vì thế, danh sách chặn cần được cập nhật và quản lý cẩn thận nếu muốn hạn chế chặn nhầm.
Giải pháp: Sử dụng proxy và VPN nhưng nó chỉ hiệu quả khi kết nối đến máy chủ trung gian không bị chặn và giao thức chưa bị nhận diện.
Hình 3: Mô phỏng đơn giản sử dụng VPN hoặc Proxy thành công (1 số dịch vụ có thể dùng protocol giao tiếp khác xem tiếp ở hình 4)
3. Chặn proxy hoặc VPN
Proxy là máy chủ trung gian chuyển tiếp kết nối của người dùng đến máy chủ đích. VPN cũng có thể chuyển tiếp lưu lượng thông qua một đường hầm mạng được bảo vệ.
Ví dụ, người dùng ở Việt Nam kết nối đến một proxy đặt tại Singapore rồi yêu cầu proxy truy cập một website nước ngoài. Nhà mạng có thể không nhìn thấy trực tiếp nội dung HTTPS bên trong kết nối, nhưng vẫn có thể nhìn thấy địa chỉ IP của máy chủ proxy và một số đặc điểm của lưu lượng.
Có nhiều cách chặn proxy:
- Chặn IP máy chủ: Nếu biết địa chỉ IP của máy chủ proxy hoặc VPN, nhà mạng có thể chặn kết nối đến địa chỉ đó.
- Chặn theo giao thức: Hệ thống kiểm duyệt có thể nhận diện dấu hiệu đặc trưng của một số giao thức proxy hoặc VPN rồi làm gián đoạn kết nối.
- Phân tích lưu lượng: Ngay cả khi dữ liệu được mã hóa, kích thước gói tin, thời điểm truyền và một số đặc điểm khi thiết lập kết nối vẫn có thể cung cấp dấu hiệu để phân loại lưu lượng.
- Dò tìm chủ động: Trong một số hệ thống kiểm duyệt, máy chủ bị nghi ngờ có thể nhận các kết nối kiểm tra từ bên ngoài. Nếu phản hồi xác nhận dịch vụ proxy đang hoạt động, địa chỉ IP hoặc cổng tương ứng có thể bị chặn.
Vì vậy, proxy không nhất thiết bị chặn vì nội dung mà người dùng truy cập. Đôi khi, chính kết nối đến máy chủ trung gian mới là đối tượng bị nhắm đến.
Giải pháp: Vì các địa chỉ IP phổ biến có thể đã bị cấm,hãy bắt đầu tìm kiếm các dịch vụ VPN ngầm, hay tự mở VPS ở "nước lạ" để tạo proxy và VPN riêng.
4. DPI — Deep Packet Inspection (Kiểm tra sâu gói tin)
Khi các thiết bị giao tiếp qua Internet, dữ liệu được chia thành những gói tin để truyền qua mạng. Mỗi gói tin có phần thông tin điều khiển và phần dữ liệu.
Một thiết bị mạng thông thường có thể xử lý gói tin dựa trên địa chỉ IP, cổng và giao thức vận chuyển. DPI đi xa hơn bằng cách phân tích thêm dữ liệu và đặc điểm của luồng kết nối để nhận diện loại lưu lượng hoặc tìm kiếm dấu hiệu cụ thể.
Ví dụ, một hệ thống kiểm duyệt có thể phân tích yêu cầu HTTP không mã hóa để tìm một tên miền hoặc từ khóa nằm trong danh sách chặn. Nó cũng có thể nhận diện một số dấu hiệu của giao thức proxy dựa trên cấu trúc gói tin hoặc cách kết nối được thiết lập.
Giải pháp: các VPN ngầm hay VPS tự self host có thể sẽ phải giả 1 vài các giao thức bình thường được cho phép để qua mắt nhà mạng. Nếu hệ thống phát hiện dấu hiệu phù hợp với quy tắc chặn, nó có thể làm gián đoạn kết nối hoặc khiến yêu cầu không đến được máy chủ đích. Tuy nhiên, DPI không có nghĩa là nhà mạng có thể đọc toàn bộ nội dung của mọi kết nối. Với HTTPS được cấu hình đúng, nội dung ứng dụng đã được TLS mã hóa. Hệ thống kiểm duyệt vẫn có thể quan sát một số metadata hoặc dấu hiệu giao thức, nhưng điều đó không đồng nghĩa với việc giải mã được nội dung bên trong. DPI cũng có giới hạn: hệ thống phải cân bằng giữa khả năng nhận diện, chi phí xử lý, tốc độ mạng và nguy cơ chặn nhầm các kết nối hợp pháp.
Hình 4: Mô phỏng vượt qua DPI thành công nhờ các protocol mã hoá
Kết thúc
Vì 1 lý do nào đó? Chính trị, kinh tế, lãnh đạo bị xúc phạm mà họ làm gắt hơn? Bất cứ cái gì, nhưng nếu là lãnh đạo ở trên tầm nhìn của họ khá lạnh lùng nếu họ biết đám dân ở dưới cũng ngu mà nên cứ ra luật ngu ngu vô lý hết sức có chết khối đứa cũng chả ai quan tâm đâu. Đâu có ai quan tâm đâu, nếu có thì thỉnh thoảng lên chấm tý nước như 1 nhà lãnh tụ vĩ đại nào đó hay khỏi cần lên truyền hình và ra lệnh cho đàn em nói đỡ như 1 anh nào đó lái xe lạ tông vô gốc cây. 1 thời gian sau không có chuyện gì xảy ra ở quốc gia đáng sống nhất thế giới. Hãy tự hào vì chúng ta ở xứ đó đi!
Giờ hãy nhìn Trung quốc, tiềm lực họ khổng lồ cũng chỉ có thể cấm ở 1 khung nào đó và vẫn phải tốn kinh phí để thiết lập hạ tầng trong nước nhằm phát triển và thay thế hệ sinh thái điều này khiến đa phần dân thường bỏ cuộc và thấy không cần thiết để tìm kiếm giải pháp thay thế nhưng vẫn khó mà cấm cản hết VPS hay 1 số địa chỉ dịch vụ IP nước ngoài khác vì nếu làm thế sẽ rất tốn nguồn lực và có thể doanh nghiệp nội địa của họ cũng sẽ ảnh hưởng. Quay lại với Việt Nam, họ dư sức làm và có thể làm từ rất sớm nhưng vì sao không thể cứ cấm hết? Vì kinh tế Việt Nam có độ mở và nếu cấm hoàn toàn 1 khi tự cô lập chính mình họ có cách nào để tự phát triển và tự bảo vệ thể chế về lâu và dài không? Hay chỉ bằng cách trở về tư duy thời tiền sử thằng nào sử dụng máy tính là quỷ dữ, là phù thuỷ cần phải đập đầu nó vào cây? Trước khi Trung Quốc áp dụng chế tài cực đoan trên, lưu ý rằng họ cũng phải để mở cửa nghiên cứu của chính họ, họ đầu tư các data center từ các trường đại học TUNA, USTC từ hàng trăm GB hàng chục TB dự án mã nguồn mở và băng thông mạng xịn xò gần như quá đỗi ngon để sử dụng. Liệu Việt Nam có đủ điện, hạ tầng và tiềm lực để làm hay cứ mỗi lần sinh viên tràn vào đăng ký môn học là kẹt và chết máy sụp server? Nếu có làm ở hiện tại cũng không ai rõ sẽ tốn bao nhiêu ngân sách và ảnh hưởng kinh tế cho công cuộc này. Những ai đọc được bài viết này đừng nghĩ rằng chỉ cần mình ngoan ngoãn, tin tưởng hay không đụng chạm đến ai thì quyền lực sẽ luôn chừa mình ra. Khi quyền lực không bị kiểm soát, hôm nay bạn có thể là người đứng ngoài cuộc; ngày mai, chỉ cần một quy định mới hay một cách diễn giải mới, bạn cũng có thể trở thành kẻ chống đối trong mắt họ. Và khi ấy, bạn sẽ hiểu rằng thứ đáng sợ nhất không phải là một lệnh cấm cụ thể, mà là việc người nắm quyền có thể tùy ý quyết định ranh giới giữa đúng và sai.
>Bạn có biết?💡
>1 người nước lạ tạo ra shadowsocks đã bị bắt? Sốc chưa?
>Và bạn có thể bị cấm phát ngôn công khai, nhưng không vì thế mà mọi cuộc trò chuyện riêng tư đều biến mất, hay suy nghĩ trong đầu bạn tự động tuân theo lệnh cấm.
Thôi nói luyên thuyên đủ rồi, cố gắng sinh tồn nhé. Gặp lại sau.
Nguồn tham khảo thêm
Nguồn tham khảo: rfc-editor.org
Cách đổi DNS server trên Windows: thegioididong.com
Setup server wireguard trên VPS: digitalocean.com
Protocol chống kiểm duyệt: XTLS/Xray-core
Server trung quốc data center cho mấy con bò chưa tin. Tự hỏi nếu cấm hết thì giải pháp thay thế đâu?
TUNA server: mirrors.tuna.tsinghua.edu.cn
USTC server: mirrors.ustc.edu.cn
2 points · 4 comments
10月17日 eMudhra 8 張中間證書的私鑰過於簡單被破解, 強烈建議更新所有電腦, 路由器, 手機平板的系統, 證書, 瀏覽器及_翻牆軟件_, 中國浪友在確認修補漏洞前可考慮暫時先不翻牆鍵政
如果用 xray 翻牆, 需服務器端和客戶端先更新至 v26.10.21 測試版
github.com/XTLS/Xray-core/releases/tag/v26.10.21
因為是 TLS 證書問題, 基於 wireguard 的應該不受影響 (但 wireguard 翻牆特徵明顯也不推薦長期使用)
關於自己具體該如何操作, 建議詢問 Claude / Chatgpt (開啟最高 effort) 或者您最喜歡的 AI.
這是非常嚴重的一個安全漏洞, 您使用的翻牆服務若 1-2 個星期內沒有任何通知或者更新操作, 考慮放棄 ( a.k.a. "我勸你多用")
關於這次證書漏洞的簡要:
################################
週二，全球資安人員因為發現八張私鑰極度脆弱的 TLS 憑證而進入高度戒備狀態。這些私鑰的強度低到可能讓任何人都能為網際網路上的任何網站，製作出受瀏覽器與應用程式信任的憑證。
截至週二接近中午時，瀏覽器開發商，以及部分主要應用程式和程式語言，都已封鎖這八張中繼憑證。憑證透明度紀錄會追蹤所有受瀏覽器信任之憑證的簽發情況，目前尚無報告指出，這些紀錄顯示失守的金鑰曾遭惡意使用。然而，威脅遠未結束，因為要更新網際網路的其他重要組成部分，例如 Linux 發行版、嵌入式裝置與物聯網裝置，將會十分困難且耗時。
一個詞：荒唐
這八張中繼憑證屬於總部位於印度的憑證機構 eMudhra Limited。週二，emudhra.we-have-a-problem.com 網站發布了一份非正式安全通報，其中寫道："We have a problem here – Wayne." (我們這裡出問題了，Wayne). 這段文字使用其中一張 eMudhra 憑證的私鑰進行數位簽署。這證明通報者確實掌握了該私鑰，讓資安防禦人員緊急展開應對，因為同一把私鑰也能用來簽署未經授權的憑證，而全球數百萬台伺服器都會信任這些憑證。
「這將是一項規模龐大的善後工作，比 Heartbleed 還要大，」密碼學工程師、開源程式語言 Go 的密碼學元件維護者 Filippo Valsorda 向 Ars 表示。「後續清理會拖得非常、非常久，包括物聯網裝置、Docker 容器、被遺忘的 Linux 機器，以及無人維護、卻自行附帶根憑證副本的命令列工具，這在某些生態系統中很常見，例如 Python。此外，Linux 發行版仍在陸續推出更新，有些甚至還沒準備好，接著系統管理員還得把更新套用到大量機器上。」
Heartbleed 是 OpenSSL 密碼學函式庫中一個重大漏洞的名稱。2014 年，這個漏洞遭到大規模利用。許多彼此沒有關聯的駭客藉此解密通訊雙方之間受 TLS 保護的資料交換。他們也取得了 TLS 憑證私鑰、工作階段 Cookie 與密碼。這些攻擊導致數千台伺服器失守，其中部分屬於世界各地的大型企業與政府機關。
復原工作需要一連串繁複步驟，歷時多年。這些步驟包括修補所有受影響裝置上的 OpenSSL、重新產生數百萬組 TLS 金鑰並重新簽發憑證、撤銷舊憑證、更換密碼與工作階段權杖，以及更新嵌入式裝置和其他被遺忘的系統。這些工作極度耗費時間與資源，尤其是在整個網際網路的規模下。
「每當你需要許多處於不同環境的人一起採取行動，就會花上很長時間，」Valsorda 解釋。「這次情況更糟，因為涉及的環境更多、人更多，系統之間的差異也更大。」
這些失守的 eMudhra 金鑰，其缺陷之離譜，讓許多研究這起事件的工程師都難以想像。正常的 NIST P-384 橢圓曲線密碼學私鑰，通常具有約 384 位元的熵，代表可能的組合數接近 2³⁸⁴，也就是一個長達 116 位數的數字。然而，這些失守私鑰的大小卻只有 3 至 8 位元。令人震驚的是，這些私鑰的值竟然是：4、56、66、115、155、156、230、237。
「這完全屬於『這根本不該發生』的情況，」Valsorda 說。「難道是某個危險至極的金鑰產生介面有個『size』參數，而他們不小心把它設成了 1？？？」
bgp.tools 負責人 Ben Cartwright-Cox 表示：「我猜可能是範例程式碼不小心被用進正式環境，但很難確定。不過，竟然一直沒有人發現，實在太荒唐了。」
在事件初期，最迫切的威脅似乎落在 VPN 使用者身上，尤其是那些政府可能惡意攔截流量的國家。很可能還有許多其他值得擔憂的情境。一般使用者幾乎無計可施，只能在獲得更新已到位的確認之前，暫緩使用許多透過瀏覽器以外方式進行的 TLS 通訊。
如前所述，多數瀏覽器已經封鎖這些中繼憑證。例外似乎是執行於 Windows 10 上的 Edge，在本文發布時，它仍能連線至 12 個受此問題影響的主機。記者詢問微軟原因，以及是否有處理計畫，一名微軟代表回覆，如果公司有任何可以「分享」的資訊，將會再聯絡。另一方面，Signal、WhatsApp、WireGuard，以及其他不依賴 TLS 保護通訊機密性的應用程式，則不受影響。這個頁面與 emudhra.we-have-a-problem.com 網站，列出了目前已知完成修補的應用程式。
這起事件再次暴露了 TLS 體系的一項致命缺陷：整體安全性取決於其中最薄弱的一環，而這次就是 eMudhra。幸好，透明度紀錄在很大程度上彌補了這項缺陷，但這項措施需要相關人員主動監控海量紀錄，而且只有在未經授權的憑證已經簽發之後才能發揮作用。記者未能即時聯絡到 eMudhra 代表回答問題。
不過，有一點需要注意：要利用這些失守的憑證，攻擊者必須發動主動式中間人攻擊，也就是在 TLS 通訊雙方之間充當代理，接收加密流量、解密、重新加密，再傳送給另一方。在某些情況下，通常只有資源最充足的攻擊者才具備這種能力。但對於掌控區域網路的人，例如掌控咖啡店、大學或其他機構網路的人，實行這類攻擊的難度就低得多。
################################
Source: arstechnica.com
來自 bleeping computer 的報道:
################################
憑證機構 eMudhra 撤銷了八張私鑰已失守的中繼憑證。研究人員發現，這些私鑰極度脆弱，任何人幾乎都能在瞬間推算出來，並用來偽造合法網站的受信任憑證。
各大瀏覽器與作業系統原本都信任這些失守的憑證，因此攻擊者可能藉此冒充合法網站，並攔截加密通訊。
一名化名 Wayne 的資安研究人員，於 10 月 17 日掃描公開的憑證資料時發現了這個弱點。
根據 Mozilla 的事件報告，這八張憑證使用的 P-384 私鑰均產生於 2025 年 4 月，而且數值都小於 256，任何人只需測試 256 個可能的數字，就能推算出私鑰。
為了展示這個弱點，資安研究人員 Flüpke 在 GitHub 上公開了其中一把失守的私鑰，顯示 eMudhra 的「EM OV TLS CA - G3C」憑證，其私鑰數值竟然只有 4。
BleepingComputer 已獨立驗證，確認公開的私鑰與其中一張已撤銷憑證相符。
eMudhra 在回覆 Mozilla 時表示，問題源於 2025 年 4 月用來產生憑證的一份指令碼出現錯誤。該公司表示，這個錯誤產生了第二組強度較弱的金鑰，由於其標籤與正確產生的金鑰相似，因而被誤選用於憑證簽署。
部分由此產生的憑證，也提交給 Sectigo 進行交叉簽署。
eMudhra 表示，多數受影響的中繼憑證從未用於正式環境，而且尚未發現它們曾被用來向終端使用者簽發憑證的證據。
不過，自這些弱金鑰於 2025 年 4 月產生以來，攻擊者就可能已經推算出它們並加以濫用，只是目前沒有證據顯示曾發生這類情況。
事件公開後，eMudhra 撤銷了這八張失守的憑證，並停止在其 G3 根憑證之下簽發新憑證。
瀏覽器開發商與軟體供應商發布修補更新
Mozilla 表示，已於 10 月 17 日透過 Firefox 的 OneCRL 系統封鎖這些失守的憑證，使用者無須更新或重新啟動瀏覽器，即可獲得保護。
Google Chrome 也在同一天封鎖了其中六張獲准簽發 TLS 憑證的失守中繼憑證，Apple 則於 10 月 19 日加入防護措施。
Mozilla 另外於 10 月 20 日發布 Firefox 158.0.1 及 ESR 版本更新，以保護那些因瀏覽器設定而無法接收先前憑證撤銷更新的使用者。
然而，使用自有憑證存放區，或不檢查憑證撤銷狀態的軟體，在更新之前，可能仍會繼續信任這些失守的中繼憑證。
Go 開發團隊已發布 1.27.3 與 1.26.10 版本，處理這個編號為 CVE-2026-111943 的問題。
Mozilla 密碼學工程師 Dennis Jackson 也建立了事件追蹤網站，列出受影響的軟體及可用的安全性更新。
|軟體|已修補版本／狀態|
|:-|:-|
|Ubuntu ca-certificates|20260816ubuntu0.22.04.120260816ubuntu0.24.04.120260816ubuntu0.26.04.120260816ubuntu0.26.10.1|
|Debian ca-certificates|待發布|
|Arch Linux ca-certificates-mozilla|3.131.1-1|
|Gentoo ca-certificates|20260816.3.125|
|FreeBSD ca_root_nss|待發布|
|Chainguard ca-certificates|20260909-r3|
|Alpine Linux ca-certificates|20261020-r0|
|NSS|3.131.1|
|curl CA 憑證組合包|2026-10-20|
|Homebrew ca-certificates|2026-09-25_1|
|Go|1.27.3、1.26.10|
|Node.js|待發布|
|Python certifi|2026.10.19|
|pip|26.2.2|
|uv|0.13.4|
|Rust rustls-webpki|0.103.16|
|Rust webpki-roots / webpki-root-certs|1.0.10|
|Electron|44.9.1、43.8.1、42.11.16|
|Bun|待發布|
|Composer ca-bundle|1.4.16、1.6.0|
|Elixir castore|1.0.22|
Jackson 也提醒，macOS 內建的 /usr/bin/curl 工具可能仍會信任這些失守的憑證，因為其使用的憑證組合包不會檢查撤銷資訊。
管理員可以使用安全通報提供的測試端點與緩解措施說明，確認系統是否仍受影響。
使用者與管理員應安裝可用的軟體更新，確保系統不再信任這些失守的憑證。
文章圖片（圖片）
攻擊者一旦取得有效的登入憑證，只有 37% 的操作會遭到攔阻
整體防禦評分可能掩蓋攻擊者取得初始存取權限之後的實際情況。一旦攻擊者開始使用有效的登入憑證，防禦攔阻效果就會大幅下降。
《Blue Report 2026》根據在客戶正式環境中執行的 3.38 億次模擬，逐項評估針對各種攻擊技術的防禦效果。
################################
Source: bleepingcomputer.com
4 points · 1 comment
We sent it upstream with an integration test:
hysteria#1703
Xray-core#7169
Full report: lab.colitu.com
#QUIC #golang #opensource
1 like
Our Hysteria2 connections died after every upload speed test. The fix was 37 lines.
We build Colitu, a VPN with open-source apps for Android, iOS, Windows, Linux and a browser extension. The apps carry traffic over several transports. Hysteria2 is a QUIC-based one that our apps prefer on many networks, because it holds up well on lossy mobile links.
The apps also check their own connection. Every 5 seconds they send a small request through the tunnel. If three checks in a row get no answer within 4 seconds, the transport is declared dead, and traffic moves to a TCP spare that is already connected. Users stay online. But a transport that keeps getting declared dead is a bug, even if nobody notices.
How we noticed
We were testing port hopping for Hysteria2 on an Android phone on home Wi-Fi. With port hopping, the client moves to a new UDP port every ~30 seconds, so networks that slow down long-running UDP flows have a harder time doing it.
Hopping itself worked. We saw five hops, and the server's replies arrived on every new port.
Then we ran a speed test. Hysteria2 carried traffic for about 50–60 seconds and then stopped for good. The health check gave up and traffic went to the spare. It happened every time.
We repeated the test on a server without port hopping and got the same result. So hopping was not the cause; it was just the test that showed the bug.
What the packets said
We captured traffic on the phone. After the stall:
- the QUIC connection was alive: ACKs and small control packets went both ways;
- UDP datagrams still flowed: DNS and the apps' own QUIC traffic, which Hysteria carries as datagrams;
- the client sent no new TCP stream data at all, not even for brand-new requests;
- the server logged nothing unusual.
A connection that is alive but will not send stream data points at flow control, not at the network.
What we ruled out first
We tested each of these instead of assuming:
| Suspect | How we tested it | Result |
|---|---|---|
| ISP shaping UDP | read the capture | packets kept flowing both ways; the client stopped sending |
| Probe starvation under load | watched after the load ended | the stall lasted for minutes after the load was gone |
| Congestion control | A/B build with Reno instead of BBR | died the same way |
| Xray's "Chrome parrot" QUIC mode | A/B build with it disabled | died the same way |
| Stream limit | counted streams | ~90 open against a limit of 1,024 |
| Many connections in general | 1,400 short sequential connections | all fine |
One more thing we tried: a bigger flow-control window (64 MB per connection, 4 MB per stream). It did not fix anything. It only delayed the stall: with 6 parallel streams it failed in round 3, with 20 streams immediately. That was the strongest hint about where to look.
Reproducing it on one PC
To get rid of the network entirely, we built the official Hysteria server v2.11.0 from source and ran it on loopback with an Xray 26.10.10 client. A small Python harness opened parallel uploads through the client, aborted them with a TCP reset, and then checked whether new requests still worked.
The only thing we changed between runs was how the upload's destination behaved:
| Target mode | What the destination does | Connection stalled? |
|---|---|---|
| fast | reads everything | no |
| slow | reads 1 MB/s | no |
| upclose | closes the connection first | no |
| stall | stops reading but keeps the connection open | yes: 0 of 5 new requests worked, no recovery in 30 s |
An upload speed test behaves exactly like stall. The test server stops reading once it has measured enough, while the browser's upload request is still open.
The mechanism
!Image description
QUIC limits how much unread data a peer may have in flight, per stream and for the whole connection. Hysteria's defaults are 8 MB per stream and 20 MB per connection. Received bytes count against both windows until the application actually reads them.
Here is what happens:
client (Xray) Hysteria server target
| upload on stream A -> | io.Copy(target, stream A) -> |
| | | stops reading,
| | target's TCP buffer full | keeps conn open
| | write to target BLOCKS |
| | -> server stops reading A |
| A's unread bytes keep counting against the connection window
| (a few streams like A fill all 20 MB)
|
| new request on stream B: blocked, no connection credit left
| writer for A: blocked on the same window, so the client
| never gets to cancel A either
|
| UDP datagrams: not flow-controlled -> still flowing
1. The client uploads through a Hysteria2 stream. The server dials the target over TCP and copies the stream into it.
2. The target stops reading but does not close. Its receive buffer fills, the server's Write into the target blocks, and the server stops reading from the stream.
3. The stream's unread upload data keeps occupying the connection-level receive window. A few such streams use up the whole window. From then on the client cannot send on any stream of the connection, including brand-new ones.
4. The client never gives the stream up, because its own writer is blocked on the same window. On an instrumented server, the "stream given up" signal only arrived when we killed the client process.
5. UDP datagrams are not covered by stream flow control, which is why DNS kept working and the connection looked healthy.
Interesting detail: we first suspected the server never calls CancelRead on dead streams. That was wrong. The stream's Close already does that. The real problem is that nothing ever reaches that Close, because the copy into the target is stuck in a blocking Write.
The fix
!Image description
The server cannot tell a stalled target from a slow one by looking at the stream. It can tell by progress: a single write that makes no progress for a long time.
So the patch does two things:
1. Every write into a TCP target gets a fresh 10-second budget. If one write makes no progress for 10 s, the target is closed. The normal cleanup then closes the stream, which releases its share of the connection window.
2. When the client gives the stream up, the target is closed immediately, so both copy directions end even when the target is silent.
A slow target that keeps moving is never cut off, because every write starts a new timer. Only a target that has stopped accepting data is closed.
This is the version we sent upstream in PR #1703:
if h.config.TCPStallTimeout > 0 {
guard := newStallGuardConn(tConn, h.config.TCPStallTimeout)
tConn = guard
stop := context.AfterFunc(stream.Context(), func() { _ = guard.Close() })
defer stop()
}
// stallGuardConn closes the wrapped connection when a single Write makes no
// progress for timeout, and makes Close idempotent. Every Write gets a fresh
// timeout, so a slow target that keeps accepting data is never closed.
type stallGuardConn struct {
net.Conn
timeout time.Duration
timer *time.Timer
closeOnce sync.Once
closeErr error
}
func newStallGuardConn(conn net.Conn, timeout time.Duration) *stallGuardConn {
c := &stallGuardConn{Conn: conn, timeout: timeout}
c.timer = time.AfterFunc(timeout, func() { _ = c.Close() })
c.timer.Stop()
return c
}
func (c *stallGuardConn) Write(p []byte) (int, error) {
c.timer.Reset(c.timeout)
n, err := c.Conn.Write(p)
c.timer.Stop()
return n, err
}
func (c *stallGuardConn) Close() error {
c.closeOnce.Do(func() { c.closeErr = c.Conn.Close() })
return c.closeErr
}
Our production build (v2.11.0-colitu1) does the same thing with SetWriteDeadline before each write. For the upstream version we made three changes:
- the check closes the connection from a timer, so it only needs Close and works with any net.Conn an outbound returns;
- the timeout is configurable as server.Config.TCPStallTimeout (default 10 s, negative disables it);
- Close is idempotent, because two paths can now close the target.
The PR also adds an integration test. Four streams upload into targets that never read (one end of a net.Pipe()), then a new request to an echo server must complete on the same connection. Without the fix it times out after 10 s. With it, it passes in about 3.5 s, with the stall timeout set to 2 s for the test.
One gotcha while writing that test: with one stalled stream it passed even without the fix. One stream can only fill its own 8 MB window, not the 20 MB connection window. It takes three or four.
Results
!Image description
In the loopback lab:
| Server | Target | Streams | New requests work again after |
|---|---|---|---|
| official v2.11.0 | stall | 6 | never (> 30 s) |
| patched | stall | 6 | 7.8 s |
| patched | stall | 20 | 7.8 s |
| patched | fast / slow / upclose | — | 0.0 s (no regression) |
On the phone, we ran four speed tests in a row over 160 seconds on a patched server in Berlin. Hysteria2 was never declared dead. Before the patch it died at ~60 s every time, both in Berlin and on a server in Vilnius.
Rollout without an app update
Because the bug was on the server, the fix did not need a new app release. Our node image now builds Hysteria from the official source tag with the patch applied. We rolled it out the same night, one server at a time. Each server's VPN service restarted for about 2 seconds. Android, iOS, Windows and Linux users all got the fix at once.
Upstream
The bug is in the open-source Hysteria server, and its client-side half is in Xray, so every service that runs them is affected, not only ours. We reported both:
- HyNetworks/hysteria#1702: the bug, how to reproduce it, and everything we ruled out.
- HyNetworks/hysteria#1703: the fix on the current development branch, with the configurable timeout and the integration test.
- XTLS/Xray-core#7169: the client side. A client that cancels the write side of a stream it no longer needs (CancelWrite, i.e. RESET_STREAM) would release the window even on servers without the fix. A contributor has since traced it on Xray's main branch, reproduced the stall on loopback, and plans a CancelWrite-based fix.
Limitations
- The lab runs on loopback: no packet loss, no added latency. It shows the mechanism and the effect of the patch, not real-world timings.
- The device result is one phone on one network, four speed tests over 160 seconds. Encouraging, not a long-term measurement.
- For up to 10 seconds before the timer fires, TCP over that connection can still pause. The patch makes the stall short; it does not make it zero. A client-side fix would complement it.
Takeaways
- "Connected but silent" usually means flow control. If ACKs and datagrams flow but stream data doesn't, look at windows before you blame the network.
- A bigger window that only delays a failure is a clue, not a fix.
- Make the destination's behaviour a test variable. Four target modes (fast, slow, upclose, stall) narrowed this down faster than any amount of packet reading.
- Write the test that fails first. Ours passed until we used enough streams to exhaust the connection window, which taught us something about the bug itself.
If you run Hysteria2 and your users see TCP die after big uploads while DNS keeps working, this is probably it. The PR is small and easy to apply to v2.11.0.
---
Full report with setup details: lab.colitu.com. Our apps are open source at github.com/colitu. Questions and corrections are welcome in the comments.
Xray-core#6477
Unfortunately, the Xray author publicly downplayed the severity of the vulnerability and used insulting language toward the vulnerability reporter.
Xray-core: Xray, Penetrates Everything. Also the best v2ray-core (42k stars)
What it does
All text below is quoted directly from the project README and repository description.
>Xray, Penetrates Everything. Also the best v2ray-core. Where the magic happens. An open platform for various uses.
>Project X originates from XTLS protocol, providing a set of network tools such as Xray-core and REALITY.
Installation:
- Linux Script
- XTLS/Xray-install (Official)
- Docker
- ghcr.io/xtls/xray-core (Official)
- Web Panel
- Remnawave
- 3X-UI
- Marzban
- Hiddify
- Homebrew
- brew install xray
Related links: VLESS Post-Quantum Encryption, XHTTP: Beyond REALITY
Repository
XTLS/Xray-core
Repository stats
|Metric|Value|
|:-|:-|
|Stars|41,946|
|Forks|5,946|
|Last release|v26.3.27 (2026-03-27)|
|Languages|Go 99.8%|
|Contributors|294|
|AI contributor accounts (Claude / Codex / Cursor / Copilot)|Claude: 3, Copilot: 8|
|AI co-authored commits|Claude: 3, Copilot: 2|
Main contributor
|Field|Value|
|:-|:-|
|GitHub|@RPRX|
|Commits to this repo|508 (top contributor)|
|Bio|VLESS & XTLS & REALITY & XHTTP|
|Company / Location|Member of Project X Community, Ásgarðr|
|Website|t.me|
|Followers|3,199|
|Public repos|11|
|On GitHub since|2020-04-08|
5 points
Mentions
@Iam54r1n4 @iyedoost دم کلاد گرم. ما صرفا داشتیم هرکاری میکردیم که leak نداشته باشیم. ولی من حس میکنم که اطلاع ندارن. کلاد میگفت یکی از فیکس هاش اینه که draft کردن که پاکش کنن اصلا و دقیقا پرفورمنس رو میاره پایین. Xray-core#6110 t.co
Nếu Việt Nam có Vạn Lý Tường Lửa Nếu ngày mai có đi thì chúng ta tính sao giờ? Chào nha nếu tò mò hãy đọc tiếp, bài viết này có thể sẽ trùng 1 vài bài viết trong quá khứ hay trên mạng gì đó nhưng tui đăng lại coi như là kiến thức tui tự học hỏi được nên tiện chia sẻ lại thôi. Ai rảnh thì ôn lại kiến thức chung luôn với tui. Bây giờ nếu Việt Nam giờ có 1 vạn lý tường lửa và thành mini China thì làm sao để vượt? Tui sẽ chỉ 1 vài khái niệm bỏ túi để nếu nó xảy ra trong tương lai gần còn biết cách ứng phó. Tui sẽ cố mô phỏng lại những gì đã và đang xảy ra ở Trung Quốc ngắn nhất và dễ hiểu, vì nó ngắn nên có thể sẽ sai và thiếu sót nhưng ai biết được và đây cũng không phải là hướng dẫn kỹ thuật hay phân tích kỹ thuật từ A-Z. Bạn tự lo liệu lấy sau khi đọc xong đi. Khái niệm Nói chung 1 khi đi qua nhà mạng kiểu gì cũng sẽ bị họ kiểm soát nhưng quan trọng ta phải đoán ở 1 mức độ nào? Và để biết mức độ nào trước hết để phải hiểu được cơ bản cách mạng máy tính hoạt động, đây là sơ đồ cơ bản nhất cho dễ hình dung. Hình 1: Mô phỏng đơn giản mạng máy tính hoạt động Thiết bị cần địa chỉ IP để giao tiếp trên mạng IP, nhưng không phải mỗi máy luôn có một IP công khai riêng. NAT, IPv4 dùng chung, Ipv6 và địa chỉ IP động khá phổ biến. Có rất nhiều giao thức và mỗi ứng dụng sẽ xài các giao thức khác nhau để giao tiếp có thể kể tên như HTTP/HTTPS, DNS, SMTP, WebSocket, WebRTC, ... còn rất nhiều nữa nếu liệt kê cũng quá dài cho 1 bài post ngắn. 1. Chặn DNS (Domain Name System) Như đã nói, địa chỉ IP là các con số khó nhớ nên chúng ta sử dụng DNS để phân giải tên miền, chẳng hạn từ example.com sang địa chỉ IP tương ứng. Khi người dùng truy cập một website, thiết bị thường cần hỏi máy chủ DNS để tìm địa chỉ IP của tên miền đó. Nếu nhà mạng can thiệp vào quá trình này, họ có thể trả về địa chỉ sai, trả về trang cảnh báo hoặc khiến truy vấn thất bại. Giải pháp: Đổi nhà cung cấp DNS khác như Cloudflare hoặc Google. Tuy nhiên, đổi DNS không phải giải pháp vạn năng: nếu nhà mạng chặn trực tiếp IP, chặn kết nối HTTPS hoặc dùng những phương pháp khác thì việc đổi DNS sẽ không giải quyết được vấn đề. Ngoài ra, DNS thông thường và DNS mã hóa như DoH, DoT cũng khác nhau. DNS mã hóa giúp bảo vệ truy vấn trên đường truyền, nhưng bản thân nó không đảm bảo mọi kết nối đến website đều không thể bị chặn. Hình 2: Mô phỏng đơn giản sử dụng DNS thành công 2. Chặn địa chỉ IP Đây là cách chặn dựa trên địa chỉ mạng đích thay vì phải xác định chính xác nội dung của website. Ví dụ, nếu một website được lưu trữ tại địa chỉ IP 203.0.113.10, nhà mạng có thể thiết lập quy tắc khiến lưu lượng đến địa chỉ đó bị loại bỏ hoặc không thể thiết lập kết nối. Người dùng có thể vẫn phân giải được tên miền thành IP, nhưng khi trình duyệt cố gắng kết nối đến máy chủ, kết nối sẽ thất bại hoặc hết thời gian chờ. Nhược điểm của phương pháp này là nhiều website có thể cùng sử dụng một địa chỉ IP, chẳng hạn khi chúng được lưu trữ trên cùng một máy chủ hoặc sử dụng chung hạ tầng CDN. Chặn một IP trong trường hợp đó có thể ảnh hưởng đến nhiều dịch vụ không liên quan. Ngược lại, một website cũng có thể sử dụng nhiều địa chỉ IP khác nhau. Vì thế, danh sách chặn cần được cập nhật và quản lý cẩn thận nếu muốn hạn chế chặn nhầm. Giải pháp: Sử dụng proxy và VPN nhưng nó chỉ hiệu quả khi kết nối đến máy chủ trung gian không bị chặn và giao thức chưa bị nhận diện. Hình 3: Mô phỏng đơn giản sử dụng VPN hoặc Proxy thành công (1 số dịch vụ có thể dùng protocol giao tiếp khác xem tiếp ở hình 4) 3. Chặn proxy hoặc VPN Proxy là máy chủ trung gian chuyển tiếp kết nối của người dùng đến máy chủ đích. VPN cũng có thể chuyển tiếp lưu lượng thông qua một đường hầm mạng được bảo vệ. Ví dụ, người dùng ở Việt Nam kết nối đến một proxy đặt tại Singapore rồi yêu cầu proxy truy cập một website nước ngoài. Nhà mạng có thể không nhìn thấy trực tiếp nội dung HTTPS bên trong kết nối, nhưng vẫn có thể nhìn thấy địa chỉ IP của máy chủ proxy và một số đặc điểm của lưu lượng. Có nhiều cách chặn proxy: - Chặn IP máy chủ: Nếu biết địa chỉ IP của máy chủ proxy hoặc VPN, nhà mạng có thể chặn kết nối đến địa chỉ đó. - Chặn theo giao thức: Hệ thống kiểm duyệt có thể nhận diện dấu hiệu đặc trưng của một số giao thức proxy hoặc VPN rồi làm gián đoạn kết nối. - Phân tích lưu lượng: Ngay cả khi dữ liệu được mã hóa, kích thước gói tin, thời điểm truyền và một số đặc điểm khi thiết lập kết nối vẫn có thể cung cấp dấu hiệu để phân loại lưu lượng. - Dò tìm chủ động: Trong một số hệ thống kiểm duyệt, máy chủ bị nghi ngờ có thể nhận các kết nối kiểm tra từ bên ngoài. Nếu phản hồi xác nhận dịch vụ proxy đang hoạt động, địa chỉ IP hoặc cổng tương ứng có thể bị chặn. Vì vậy, proxy không nhất thiết bị chặn vì nội dung mà người dùng truy cập. Đôi khi, chính kết nối đến máy chủ trung gian mới là đối tượng bị nhắm đến. Giải pháp: Vì các địa chỉ IP phổ biến có thể đã bị cấm,hãy bắt đầu tìm kiếm các dịch vụ VPN ngầm, hay tự mở VPS ở "nước lạ" để tạo proxy và VPN riêng. 4. DPI — Deep Packet Inspection (Kiểm tra sâu gói tin) Khi các thiết bị giao tiếp qua Internet, dữ liệu được chia thành những gói tin để truyền qua mạng. Mỗi gói tin có phần thông tin điều khiển và phần dữ liệu. Một thiết bị mạng thông thường có thể xử lý gói tin dựa trên địa chỉ IP, cổng và giao thức vận chuyển. DPI đi xa hơn bằng cách phân tích thêm dữ liệu và đặc điểm của luồng kết nối để nhận diện loại lưu lượng hoặc tìm kiếm dấu hiệu cụ thể. Ví dụ, một hệ thống kiểm duyệt có thể phân tích yêu cầu HTTP không mã hóa để tìm một tên miền hoặc từ khóa nằm trong danh sách chặn. Nó cũng có thể nhận diện một số dấu hiệu của giao thức proxy dựa trên cấu trúc gói tin hoặc cách kết nối được thiết lập. Giải pháp: các VPN ngầm hay VPS tự self host có thể sẽ phải giả 1 vài các giao thức bình thường được cho phép để qua mắt nhà mạng. Nếu hệ thống phát hiện dấu hiệu phù hợp với quy tắc chặn, nó có thể làm gián đoạn kết nối hoặc khiến yêu cầu không đến được máy chủ đích. Tuy nhiên, DPI không có nghĩa là nhà mạng có thể đọc toàn bộ nội dung của mọi kết nối. Với HTTPS được cấu hình đúng, nội dung ứng dụng đã được TLS mã hóa. Hệ thống kiểm duyệt vẫn có thể quan sát một số metadata hoặc dấu hiệu giao thức, nhưng điều đó không đồng nghĩa với việc giải mã được nội dung bên trong. DPI cũng có giới hạn: hệ thống phải cân bằng giữa khả năng nhận diện, chi phí xử lý, tốc độ mạng và nguy cơ chặn nhầm các kết nối hợp pháp. Hình 4: Mô phỏng vượt qua DPI thành công nhờ các protocol mã hoá Kết thúc Vì 1 lý do nào đó? Chính trị, kinh tế, lãnh đạo bị xúc phạm mà họ làm gắt hơn? Bất cứ cái gì, nhưng nếu là lãnh đạo ở trên tầm nhìn của họ khá lạnh lùng nếu họ biết đám dân ở dưới cũng ngu mà nên cứ ra luật ngu ngu vô lý hết sức có chết khối đứa cũng chả ai quan tâm đâu. Đâu có ai quan tâm đâu, nếu có thì thỉnh thoảng lên chấm tý nước như 1 nhà lãnh tụ vĩ đại nào đó hay khỏi cần lên truyền hình và ra lệnh cho đàn em nói đỡ như 1 anh nào đó lái xe lạ tông vô gốc cây. 1 thời gian sau không có chuyện gì xảy ra ở quốc gia đáng sống nhất thế giới. Hãy tự hào vì chúng ta ở xứ đó đi! Giờ hãy nhìn Trung quốc, tiềm lực họ khổng lồ cũng chỉ có thể cấm ở 1 khung nào đó và vẫn phải tốn kinh phí để thiết lập hạ tầng trong nước nhằm phát triển và thay thế hệ sinh thái điều này khiến đa phần dân thường bỏ cuộc và thấy không cần thiết để tìm kiếm giải pháp thay thế nhưng vẫn khó mà cấm cản hết VPS hay 1 số địa chỉ dịch vụ IP nước ngoài khác vì nếu làm thế sẽ rất tốn nguồn lực và có thể doanh nghiệp nội địa của họ cũng sẽ ảnh hưởng. Quay lại với Việt Nam, họ dư sức làm và có thể làm từ rất sớm nhưng vì sao không thể cứ cấm hết? Vì kinh tế Việt Nam có độ mở và nếu cấm hoàn toàn 1 khi tự cô lập chính mình họ có cách nào để tự phát triển và tự bảo vệ thể chế về lâu và dài không? Hay chỉ bằng cách trở về tư duy thời tiền sử thằng nào sử dụng máy tính là quỷ dữ, là phù thuỷ cần phải đập đầu nó vào cây? Trước khi Trung Quốc áp dụng chế tài cực đoan trên, lưu ý rằng họ cũng phải để mở cửa nghiên cứu của chính họ, họ đầu tư các data center từ các trường đại học TUNA, USTC từ hàng trăm GB hàng chục TB dự án mã nguồn mở và băng thông mạng xịn xò gần như quá đỗi ngon để sử dụng. Liệu Việt Nam có đủ điện, hạ tầng và tiềm lực để làm hay cứ mỗi lần sinh viên tràn vào đăng ký môn học là kẹt và chết máy sụp server? Nếu có làm ở hiện tại cũng không ai rõ sẽ tốn bao nhiêu ngân sách và ảnh hưởng kinh tế cho công cuộc này. Những ai đọc được bài viết này đừng nghĩ rằng chỉ cần mình ngoan ngoãn, tin tưởng hay không đụng chạm đến ai thì quyền lực sẽ luôn chừa mình ra. Khi quyền lực không bị kiểm soát, hôm nay bạn có thể là người đứng ngoài cuộc; ngày mai, chỉ cần một quy định mới hay một cách diễn giải mới, bạn cũng có thể trở thành kẻ chống đối trong mắt họ. Và khi ấy, bạn sẽ hiểu rằng thứ đáng sợ nhất không phải là một lệnh cấm cụ thể, mà là việc người nắm quyền có thể tùy ý quyết định ranh giới giữa đúng và sai. >Bạn có biết?💡 >1 người nước lạ tạo ra shadowsocks đã bị bắt? Sốc chưa? >Và bạn có thể bị cấm phát ngôn công khai, nhưng không vì thế mà mọi cuộc trò chuyện riêng tư đều biến mất, hay suy nghĩ trong đầu bạn tự động tuân theo lệnh cấm. Thôi nói luyên thuyên đủ rồi, cố gắng sinh tồn nhé. Gặp lại sau. Nguồn tham khảo thêm Nguồn tham khảo: rfc-editor.org Cách đổi DNS server trên Windows: thegioididong.com Setup server wireguard trên VPS: digitalocean.com Protocol chống kiểm duyệt: XTLS/Xray-core Server trung quốc data center cho mấy con bò chưa tin. Tự hỏi nếu cấm hết thì giải pháp thay thế đâu? TUNA server: mirrors.tuna.tsinghua.edu.cn USTC server: mirrors.ustc.edu.cn
10月17日 eMudhra 8 張中間證書的私鑰過於簡單被破解, 強烈建議更新所有電腦, 路由器, 手機平板的系統, 證書, 瀏覽器及_翻牆軟件_, 中國浪友在確認修補漏洞前可考慮暫時先不翻牆鍵政 如果用 xray 翻牆, 需服務器端和客戶端先更新至 v26.10.21 測試版 github.com/XTLS/Xray-core/releases/tag/v26.10.21 因為是 TLS 證書問題, 基於 wireguard 的應該不受影響 (但 wireguard 翻牆特徵明顯也不推薦長期使用) 關於自己具體該如何操作, 建議詢問 Claude / Chatgpt (開啟最高 effort) 或者您最喜歡的 AI. 這是非常嚴重的一個安全漏洞, 您使用的翻牆服務若 1-2 個星期內沒有任何通知或者更新操作, 考慮放棄 ( a.k.a. "我勸你多用") 關於這次證書漏洞的簡要: ################################ 週二，全球資安人員因為發現八張私鑰極度脆弱的 TLS 憑證而進入高度戒備狀態。這些私鑰的強度低到可能讓任何人都能為網際網路上的任何網站，製作出受瀏覽器與應用程式信任的憑證。 截至週二接近中午時，瀏覽器開發商，以及部分主要應用程式和程式語言，都已封鎖這八張中繼憑證。憑證透明度紀錄會追蹤所有受瀏覽器信任之憑證的簽發情況，目前尚無報告指出，這些紀錄顯示失守的金鑰曾遭惡意使用。然而，威脅遠未結束，因為要更新網際網路的其他重要組成部分，例如 Linux 發行版、嵌入式裝置與物聯網裝置，將會十分困難且耗時。 一個詞：荒唐 這八張中繼憑證屬於總部位於印度的憑證機構 eMudhra Limited。週二，emudhra.we-have-a-problem.com 網站發布了一份非正式安全通報，其中寫道："We have a problem here – Wayne." (我們這裡出問題了，Wayne). 這段文字使用其中一張 eMudhra 憑證的私鑰進行數位簽署。這證明通報者確實掌握了該私鑰，讓資安防禦人員緊急展開應對，因為同一把私鑰也能用來簽署未經授權的憑證，而全球數百萬台伺服器都會信任這些憑證。 「這將是一項規模龐大的善後工作，比 Heartbleed 還要大，」密碼學工程師、開源程式語言 Go 的密碼學元件維護者 Filippo Valsorda 向 Ars 表示。「後續清理會拖得非常、非常久，包括物聯網裝置、Docker 容器、被遺忘的 Linux 機器，以及無人維護、卻自行附帶根憑證副本的命令列工具，這在某些生態系統中很常見，例如 Python。此外，Linux 發行版仍在陸續推出更新，有些甚至還沒準備好，接著系統管理員還得把更新套用到大量機器上。」 Heartbleed 是 OpenSSL 密碼學函式庫中一個重大漏洞的名稱。2014 年，這個漏洞遭到大規模利用。許多彼此沒有關聯的駭客藉此解密通訊雙方之間受 TLS 保護的資料交換。他們也取得了 TLS 憑證私鑰、工作階段 Cookie 與密碼。這些攻擊導致數千台伺服器失守，其中部分屬於世界各地的大型企業與政府機關。 復原工作需要一連串繁複步驟，歷時多年。這些步驟包括修補所有受影響裝置上的 OpenSSL、重新產生數百萬組 TLS 金鑰並重新簽發憑證、撤銷舊憑證、更換密碼與工作階段權杖，以及更新嵌入式裝置和其他被遺忘的系統。這些工作極度耗費時間與資源，尤其是在整個網際網路的規模下。 「每當你需要許多處於不同環境的人一起採取行動，就會花上很長時間，」Valsorda 解釋。「這次情況更糟，因為涉及的環境更多、人更多，系統之間的差異也更大。」 這些失守的 eMudhra 金鑰，其缺陷之離譜，讓許多研究這起事件的工程師都難以想像。正常的 NIST P-384 橢圓曲線密碼學私鑰，通常具有約 384 位元的熵，代表可能的組合數接近 2³⁸⁴，也就是一個長達 116 位數的數字。然而，這些失守私鑰的大小卻只有 3 至 8 位元。令人震驚的是，這些私鑰的值竟然是：4、56、66、115、155、156、230、237。 「這完全屬於『這根本不該發生』的情況，」Valsorda 說。「難道是某個危險至極的金鑰產生介面有個『size』參數，而他們不小心把它設成了 1？？？」 bgp.tools 負責人 Ben Cartwright-Cox 表示：「我猜可能是範例程式碼不小心被用進正式環境，但很難確定。不過，竟然一直沒有人發現，實在太荒唐了。」 在事件初期，最迫切的威脅似乎落在 VPN 使用者身上，尤其是那些政府可能惡意攔截流量的國家。很可能還有許多其他值得擔憂的情境。一般使用者幾乎無計可施，只能在獲得更新已到位的確認之前，暫緩使用許多透過瀏覽器以外方式進行的 TLS 通訊。 如前所述，多數瀏覽器已經封鎖這些中繼憑證。例外似乎是執行於 Windows 10 上的 Edge，在本文發布時，它仍能連線至 12 個受此問題影響的主機。記者詢問微軟原因，以及是否有處理計畫，一名微軟代表回覆，如果公司有任何可以「分享」的資訊，將會再聯絡。另一方面，Signal、WhatsApp、WireGuard，以及其他不依賴 TLS 保護通訊機密性的應用程式，則不受影響。這個頁面與 emudhra.we-have-a-problem.com 網站，列出了目前已知完成修補的應用程式。 這起事件再次暴露了 TLS 體系的一項致命缺陷：整體安全性取決於其中最薄弱的一環，而這次就是 eMudhra。幸好，透明度紀錄在很大程度上彌補了這項缺陷，但這項措施需要相關人員主動監控海量紀錄，而且只有在未經授權的憑證已經簽發之後才能發揮作用。記者未能即時聯絡到 eMudhra 代表回答問題。 不過，有一點需要注意：要利用這些失守的憑證，攻擊者必須發動主動式中間人攻擊，也就是在 TLS 通訊雙方之間充當代理，接收加密流量、解密、重新加密，再傳送給另一方。在某些情況下，通常只有資源最充足的攻擊者才具備這種能力。但對於掌控區域網路的人，例如掌控咖啡店、大學或其他機構網路的人，實行這類攻擊的難度就低得多。 ################################ Source: arstechnica.com 來自 bleeping computer 的報道: ################################ 憑證機構 eMudhra 撤銷了八張私鑰已失守的中繼憑證。研究人員發現，這些私鑰極度脆弱，任何人幾乎都能在瞬間推算出來，並用來偽造合法網站的受信任憑證。 各大瀏覽器與作業系統原本都信任這些失守的憑證，因此攻擊者可能藉此冒充合法網站，並攔截加密通訊。 一名化名 Wayne 的資安研究人員，於 10 月 17 日掃描公開的憑證資料時發現了這個弱點。 根據 Mozilla 的事件報告，這八張憑證使用的 P-384 私鑰均產生於 2025 年 4 月，而且數值都小於 256，任何人只需測試 256 個可能的數字，就能推算出私鑰。 為了展示這個弱點，資安研究人員 Flüpke 在 GitHub 上公開了其中一把失守的私鑰，顯示 eMudhra 的「EM OV TLS CA - G3C」憑證，其私鑰數值竟然只有 4。 BleepingComputer 已獨立驗證，確認公開的私鑰與其中一張已撤銷憑證相符。 eMudhra 在回覆 Mozilla 時表示，問題源於 2025 年 4 月用來產生憑證的一份指令碼出現錯誤。該公司表示，這個錯誤產生了第二組強度較弱的金鑰，由於其標籤與正確產生的金鑰相似，因而被誤選用於憑證簽署。 部分由此產生的憑證，也提交給 Sectigo 進行交叉簽署。 eMudhra 表示，多數受影響的中繼憑證從未用於正式環境，而且尚未發現它們曾被用來向終端使用者簽發憑證的證據。 不過，自這些弱金鑰於 2025 年 4 月產生以來，攻擊者就可能已經推算出它們並加以濫用，只是目前沒有證據顯示曾發生這類情況。 事件公開後，eMudhra 撤銷了這八張失守的憑證，並停止在其 G3 根憑證之下簽發新憑證。 瀏覽器開發商與軟體供應商發布修補更新 Mozilla 表示，已於 10 月 17 日透過 Firefox 的 OneCRL 系統封鎖這些失守的憑證，使用者無須更新或重新啟動瀏覽器，即可獲得保護。 Google Chrome 也在同一天封鎖了其中六張獲准簽發 TLS 憑證的失守中繼憑證，Apple 則於 10 月 19 日加入防護措施。 Mozilla 另外於 10 月 20 日發布 Firefox 158.0.1 及 ESR 版本更新，以保護那些因瀏覽器設定而無法接收先前憑證撤銷更新的使用者。 然而，使用自有憑證存放區，或不檢查憑證撤銷狀態的軟體，在更新之前，可能仍會繼續信任這些失守的中繼憑證。 Go 開發團隊已發布 1.27.3 與 1.26.10 版本，處理這個編號為 CVE-2026-111943 的問題。 Mozilla 密碼學工程師 Dennis Jackson 也建立了事件追蹤網站，列出受影響的軟體及可用的安全性更新。 |軟體|已修補版本／狀態| |:-|:-| |Ubuntu ca-certificates|20260816ubuntu0.22.04.120260816ubuntu0.24.04.120260816ubuntu0.26.04.120260816ubuntu0.26.10.1| |Debian ca-certificates|待發布| |Arch Linux ca-certificates-mozilla|3.131.1-1| |Gentoo ca-certificates|20260816.3.125| |FreeBSD ca_root_nss|待發布| |Chainguard ca-certificates|20260909-r3| |Alpine Linux ca-certificates|20261020-r0| |NSS|3.131.1| |curl CA 憑證組合包|2026-10-20| |Homebrew ca-certificates|2026-09-25_1| |Go|1.27.3、1.26.10| |Node.js|待發布| |Python certifi|2026.10.19| |pip|26.2.2| |uv|0.13.4| |Rust rustls-webpki|0.103.16| |Rust webpki-roots / webpki-root-certs|1.0.10| |Electron|44.9.1、43.8.1、42.11.16| |Bun|待發布| |Composer ca-bundle|1.4.16、1.6.0| |Elixir castore|1.0.22| Jackson 也提醒，macOS 內建的 /usr/bin/curl 工具可能仍會信任這些失守的憑證，因為其使用的憑證組合包不會檢查撤銷資訊。 管理員可以使用安全通報提供的測試端點與緩解措施說明，確認系統是否仍受影響。 使用者與管理員應安裝可用的軟體更新，確保系統不再信任這些失守的憑證。 文章圖片（圖片） 攻擊者一旦取得有效的登入憑證，只有 37% 的操作會遭到攔阻 整體防禦評分可能掩蓋攻擊者取得初始存取權限之後的實際情況。一旦攻擊者開始使用有效的登入憑證，防禦攔阻效果就會大幅下降。 《Blue Report 2026》根據在客戶正式環境中執行的 3.38 億次模擬，逐項評估針對各種攻擊技術的防禦效果。 ################################ Source: bleepingcomputer.com
We sent it upstream with an integration test: hysteria#1703 Xray-core#7169 Full report: lab.colitu.com #QUIC #golang #opensource
Our Hysteria2 connections died after every upload speed test. The fix was 37 lines. We build Colitu, a VPN with open-source apps for Android, iOS, Windows, Linux and a browser extension. The apps carry traffic over several transports. Hysteria2 is a QUIC-based one that our apps prefer on many networks, because it holds up well on lossy mobile links. The apps also check their own connection. Every 5 seconds they send a small request through the tunnel. If three checks in a row get no answer within 4 seconds, the transport is declared dead, and traffic moves to a TCP spare that is already connected. Users stay online. But a transport that keeps getting declared dead is a bug, even if nobody notices. How we noticed We were testing port hopping for Hysteria2 on an Android phone on home Wi-Fi. With port hopping, the client moves to a new UDP port every ~30 seconds, so networks that slow down long-running UDP flows have a harder time doing it. Hopping itself worked. We saw five hops, and the server's replies arrived on every new port. Then we ran a speed test. Hysteria2 carried traffic for about 50–60 seconds and then stopped for good. The health check gave up and traffic went to the spare. It happened every time. We repeated the test on a server without port hopping and got the same result. So hopping was not the cause; it was just the test that showed the bug. What the packets said We captured traffic on the phone. After the stall: - the QUIC connection was alive: ACKs and small control packets went both ways; - UDP datagrams still flowed: DNS and the apps' own QUIC traffic, which Hysteria carries as datagrams; - the client sent no new TCP stream data at all, not even for brand-new requests; - the server logged nothing unusual. A connection that is alive but will not send stream data points at flow control, not at the network. What we ruled out first We tested each of these instead of assuming: | Suspect | How we tested it | Result | |---|---|---| | ISP shaping UDP | read the capture | packets kept flowing both ways; the client stopped sending | | Probe starvation under load | watched after the load ended | the stall lasted for minutes after the load was gone | | Congestion control | A/B build with Reno instead of BBR | died the same way | | Xray's "Chrome parrot" QUIC mode | A/B build with it disabled | died the same way | | Stream limit | counted streams | ~90 open against a limit of 1,024 | | Many connections in general | 1,400 short sequential connections | all fine | One more thing we tried: a bigger flow-control window (64 MB per connection, 4 MB per stream). It did not fix anything. It only delayed the stall: with 6 parallel streams it failed in round 3, with 20 streams immediately. That was the strongest hint about where to look. Reproducing it on one PC To get rid of the network entirely, we built the official Hysteria server v2.11.0 from source and ran it on loopback with an Xray 26.10.10 client. A small Python harness opened parallel uploads through the client, aborted them with a TCP reset, and then checked whether new requests still worked. The only thing we changed between runs was how the upload's destination behaved: | Target mode | What the destination does | Connection stalled? | |---|---|---| | fast | reads everything | no | | slow | reads 1 MB/s | no | | upclose | closes the connection first | no | | stall | stops reading but keeps the connection open | yes: 0 of 5 new requests worked, no recovery in 30 s | An upload speed test behaves exactly like stall. The test server stops reading once it has measured enough, while the browser's upload request is still open. The mechanism !Image description QUIC limits how much unread data a peer may have in flight, per stream and for the whole connection. Hysteria's defaults are 8 MB per stream and 20 MB per connection. Received bytes count against both windows until the application actually reads them. Here is what happens: client (Xray) Hysteria server target | upload on stream A -> | io.Copy(target, stream A) -> | | | | stops reading, | | target's TCP buffer full | keeps conn open | | write to target BLOCKS | | | -> server stops reading A | | A's unread bytes keep counting against the connection window | (a few streams like A fill all 20 MB) | | new request on stream B: blocked, no connection credit left | writer for A: blocked on the same window, so the client | never gets to cancel A either | | UDP datagrams: not flow-controlled -> still flowing 1. The client uploads through a Hysteria2 stream. The server dials the target over TCP and copies the stream into it. 2. The target stops reading but does not close. Its receive buffer fills, the server's Write into the target blocks, and the server stops reading from the stream. 3. The stream's unread upload data keeps occupying the connection-level receive window. A few such streams use up the whole window. From then on the client cannot send on any stream of the connection, including brand-new ones. 4. The client never gives the stream up, because its own writer is blocked on the same window. On an instrumented server, the "stream given up" signal only arrived when we killed the client process. 5. UDP datagrams are not covered by stream flow control, which is why DNS kept working and the connection looked healthy. Interesting detail: we first suspected the server never calls CancelRead on dead streams. That was wrong. The stream's Close already does that. The real problem is that nothing ever reaches that Close, because the copy into the target is stuck in a blocking Write. The fix !Image description The server cannot tell a stalled target from a slow one by looking at the stream. It can tell by progress: a single write that makes no progress for a long time. So the patch does two things: 1. Every write into a TCP target gets a fresh 10-second budget. If one write makes no progress for 10 s, the target is closed. The normal cleanup then closes the stream, which releases its share of the connection window. 2. When the client gives the stream up, the target is closed immediately, so both copy directions end even when the target is silent. A slow target that keeps moving is never cut off, because every write starts a new timer. Only a target that has stopped accepting data is closed. This is the version we sent upstream in PR #1703: if h.config.TCPStallTimeout > 0 { guard := newStallGuardConn(tConn, h.config.TCPStallTimeout) tConn = guard stop := context.AfterFunc(stream.Context(), func() { _ = guard.Close() }) defer stop() } // stallGuardConn closes the wrapped connection when a single Write makes no // progress for timeout, and makes Close idempotent. Every Write gets a fresh // timeout, so a slow target that keeps accepting data is never closed. type stallGuardConn struct { net.Conn timeout time.Duration timer *time.Timer closeOnce sync.Once closeErr error } func newStallGuardConn(conn net.Conn, timeout time.Duration) *stallGuardConn { c := &stallGuardConn{Conn: conn, timeout: timeout} c.timer = time.AfterFunc(timeout, func() { _ = c.Close() }) c.timer.Stop() return c } func (c *stallGuardConn) Write(p []byte) (int, error) { c.timer.Reset(c.timeout) n, err := c.Conn.Write(p) c.timer.Stop() return n, err } func (c *stallGuardConn) Close() error { c.closeOnce.Do(func() { c.closeErr = c.Conn.Close() }) return c.closeErr } Our production build (v2.11.0-colitu1) does the same thing with SetWriteDeadline before each write. For the upstream version we made three changes: - the check closes the connection from a timer, so it only needs Close and works with any net.Conn an outbound returns; - the timeout is configurable as server.Config.TCPStallTimeout (default 10 s, negative disables it); - Close is idempotent, because two paths can now close the target. The PR also adds an integration test. Four streams upload into targets that never read (one end of a net.Pipe()), then a new request to an echo server must complete on the same connection. Without the fix it times out after 10 s. With it, it passes in about 3.5 s, with the stall timeout set to 2 s for the test. One gotcha while writing that test: with one stalled stream it passed even without the fix. One stream can only fill its own 8 MB window, not the 20 MB connection window. It takes three or four. Results !Image description In the loopback lab: | Server | Target | Streams | New requests work again after | |---|---|---|---| | official v2.11.0 | stall | 6 | never (> 30 s) | | patched | stall | 6 | 7.8 s | | patched | stall | 20 | 7.8 s | | patched | fast / slow / upclose | — | 0.0 s (no regression) | On the phone, we ran four speed tests in a row over 160 seconds on a patched server in Berlin. Hysteria2 was never declared dead. Before the patch it died at ~60 s every time, both in Berlin and on a server in Vilnius. Rollout without an app update Because the bug was on the server, the fix did not need a new app release. Our node image now builds Hysteria from the official source tag with the patch applied. We rolled it out the same night, one server at a time. Each server's VPN service restarted for about 2 seconds. Android, iOS, Windows and Linux users all got the fix at once. Upstream The bug is in the open-source Hysteria server, and its client-side half is in Xray, so every service that runs them is affected, not only ours. We reported both: - HyNetworks/hysteria#1702: the bug, how to reproduce it, and everything we ruled out. - HyNetworks/hysteria#1703: the fix on the current development branch, with the configurable timeout and the integration test. - XTLS/Xray-core#7169: the client side. A client that cancels the write side of a stream it no longer needs (CancelWrite, i.e. RESET_STREAM) would release the window even on servers without the fix. A contributor has since traced it on Xray's main branch, reproduced the stall on loopback, and plans a CancelWrite-based fix. Limitations - The lab runs on loopback: no packet loss, no added latency. It shows the mechanism and the effect of the patch, not real-world timings. - The device result is one phone on one network, four speed tests over 160 seconds. Encouraging, not a long-term measurement. - For up to 10 seconds before the timer fires, TCP over that connection can still pause. The patch makes the stall short; it does not make it zero. A client-side fix would complement it. Takeaways - "Connected but silent" usually means flow control. If ACKs and datagrams flow but stream data doesn't, look at windows before you blame the network. - A bigger window that only delays a failure is a clue, not a fix. - Make the destination's behaviour a test variable. Four target modes (fast, slow, upclose, stall) narrowed this down faster than any amount of packet reading. - Write the test that fails first. Ours passed until we used enough streams to exhaust the connection window, which taught us something about the bug itself. If you run Hysteria2 and your users see TCP die after big uploads while DNS keeps working, this is probably it. The PR is small and easy to apply to v2.11.0. --- Full report with setup details: lab.colitu.com. Our apps are open source at github.com/colitu. Questions and corrections are welcome in the comments.
Xray-core#6477 Unfortunately, the Xray author publicly downplayed the severity of the vulnerability and used insulting language toward the vulnerability reporter.
Xray-core: Xray, Penetrates Everything. Also the best v2ray-core (42k stars) What it does All text below is quoted directly from the project README and repository description. >Xray, Penetrates Everything. Also the best v2ray-core. Where the magic happens. An open platform for various uses. >Project X originates from XTLS protocol, providing a set of network tools such as Xray-core and REALITY. Installation: - Linux Script - XTLS/Xray-install (Official) - Docker - ghcr.io/xtls/xray-core (Official) - Web Panel - Remnawave - 3X-UI - Marzban - Hiddify - Homebrew - brew install xray Related links: VLESS Post-Quantum Encryption, XHTTP: Beyond REALITY Repository XTLS/Xray-core Repository stats |Metric|Value| |:-|:-| |Stars|41,946| |Forks|5,946| |Last release|v26.3.27 (2026-03-27)| |Languages|Go 99.8%| |Contributors|294| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|Claude: 3, Copilot: 8| |AI co-authored commits|Claude: 3, Copilot: 2| Main contributor |Field|Value| |:-|:-| |GitHub|@RPRX| |Commits to this repo|508 (top contributor)| |Bio|VLESS & XTLS & REALITY & XHTTP| |Company / Location|Member of Project X Community, Ásgarðr| |Website|t.me| |Followers|3,199| |Public repos|11| |On GitHub since|2020-04-08|