拾叁玥

拾叁玥 私聊

普通用户正常
注册于
37
萌萌点
1
话题
0
Galgame
0
评分
2
被赞
0
被推
@ #14 鏈式代理(特指這裏提到的 WARP)的主要優點是將IP和訪問目標分離  (以低成本(註:指網絡開銷成本)的方式達成Tor網絡的主要目的之一),雖然很多問題依然存在,但速度多數情況下並不是主要問題(需要清楚的是 Cloudflare 只在大陸被戲稱爲「減速器」,在其他地區就是不折不扣的加速器,大部分地區直連CF的延遲極低。感興趣的話可以自己去ping一下)
@ #14 這裏簡單介紹一下 TLS/SSL 的運作原理 首先需要知道的是,TLS (Transport Layer Security, 傳輸層安全性) 並非由單一的加密演算法組成,而是一整套涵蓋金鑰交換,加密密碼,完整性校驗的整套協定 (Protocol) 下面以最新的 TLS 1.3 爲例,其運作過程主要可以分(感興趣的話可以去維基看完整流程): 握手與金鑰交換 (Handshake & Key Exchange): 用戶端與伺服器會先交換「隨機數」與「公鑰參數」。在 TLS 1.3 中,這主要透過 ECDHE (橢圓曲線迪菲-赫爾曼密鑰交換) 達成 (目前使用最多的是 X25519)。雙方在不直接傳輸密鑰的情況下,計算出一個只有雙方知道的「對稱密鑰」。 身份驗證 (Authentication): 伺服器出示數位憑證,證明自己是合法的網站,防止中間人攻擊 (MITM)。 對稱加密傳輸 (Symmetric Encryption): 一旦握手成功,雙方會使用剛才生成的「對稱金鑰」來加密實際傳輸的資料(如 AES-GCM 算法)。由於對稱加密效率極高,這被用於後續的所有數據通訊。 但目前的問題主要出在第一步上,現行的 ECDHE 主要依賴 ECDLP (橢圓曲線離散對數問題),具體的就不展開講了 (不然會勸退不少人),這裏直接給出結論: 如果未來出現大型量子計算機,那麼他可以使用秀爾算法解決 ECDLP, 從而破解出雙方的私鑰,進而得到「對稱密鑰」,後面的加密就形同虛設了。 這就是著名的「先存儲,後解密」(Store Now, Decrypt Later) 攻擊,目前已經有越來越多的服務商開始意識到這個問題的嚴重性, PQC (Post-Quantum Cryptography, 後量子密碼學,感興趣的可以閱讀這篇文章) 正被逐步推行. 如果你想檢查你的連接是否啓用了 PQC 可以打開 檢查一下: fl=80f200 h=www.kungal.com ip=1.1.1.1 ts=1766288587.000 visit_scheme=https uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0 colo=TPE sliver=010-tier1 http=http/3 loc=TW tls=TLSv1.3 sni=encrypted warp=off gateway=off rbi=off kex=X25519MLKEM768 如果 kex 一欄和這裏一樣是 X25519MLKEM768 就說明你正在使用抗量子的金鑰交換。 如果仍是 X25519 或是其他的演算法 也不必太過擔心 (真到了Q-Day/Y2Q 會有各種服務商催你升級的) 另外就是MITM (Man-in-the-middle),這個目前就純屬個人安全意識問題了 (雖然也出過像 CNNIC 等問題,感興趣的話可以去這裏或者這裏閱讀相關事件) 有多少人下意識的點「繼續前往網站」和「繼續前往 self-signed.badssl.com (不安全)」而不是「上一步」?
@ #13 這個我不能打包票 (說一定有或是一定沒有),但至少是小概率事件且不會明目張膽地放在明網上
@ #12 感謝總結。你提的幾點安全策略也很實用,但這裏有幾點要補充的: 各個作業系統和瀏覽器對加密 DNS 的支援度不一 一般來說 DoH (DNS Over HTTPS) 由於其復用 tcp/443 和HTTP報文,因此支援度最廣 (Google Chrome, Firefox, Safari; Windows 10/11, Android, macOS/iOS 都有提供支援,但各自的實現方式稍有不同)。但像 DoT (DNS Over TLS),DoQ (DNS Over QUIC) 相對支援程度就少很多 (特別是 DoQ .客戶端和服務端的實作少得可憐.) 關於加密 DNS 的選擇,這裏不做推薦 但請記住: DNS 服務商可以同時看到你的IP和你查詢的域名 (除非使用 ODoH 等技術) 關於 ECH (Encrypted Client Hello) 這部分可能最容易被誤解,首先一個連接是否使用 ECH 並非完全由使用者端決定. 你連接的網站必須支援 ECH (目前支援 ECH 的大型網絡基建只有 Cloudflare) 網絡中不能有節點攔截 ECH 封包 (目前 GFW 尚未主動阻斷 ECH 連接,但觀察到部分劣化情況) 你所使用的 DNS 需要支援查詢 HTTPS 記錄 (因爲目前 ECH 主要靠這個分發公鑰. 雖然原則上不強求加密 DNS,但主流客戶端都將 DoH 視作 ECH 的條件之一) 另外 ECH 並非完全抹掉了 SNI (出於兼容性考慮,ECH 會在 SNI 上放一個不相關的域名。例如 Cloudflare 使用 cloudflare-ech.com ) 而且由於目前尚未大範圍鋪開,爲了兼容性,當 ECH 連接失敗時瀏覽器會自動回退. 這意味着只要封鎖cloudflare-ech.com就能讓大部分的 ECH 失效 (目前已經出現劣化跡象) 關於混淆代理 這部分可能是變動最頻繁的技術之一了. 但從技術上主要分爲兩類: 以 Shadowsocks 爲代表的無特徵代理協議 以 Trojan/VLESS 爲代表的混淆式代理 第一種沒什麼好說的 (感興趣的話可以去看 這個 ) 這裏講下第二種: 這裏代理主要通過將流量模仿爲標準的 TLS (準確來說是 模仿 HTTPS) 流量來規避 GFW. 但實務上時常因爲模仿得不像(如 TLS 內嵌套 TLS 也就是 TLS in TLS) 帶來額外的麻煩: 2025-12-20T18:04:56+01:00       INFO    ruleset log     {"name": "block trojan", "id": 2002560879681339392, "src": "1 92.168.30.117:33512", "dst": "1.1.1.1:18249", "props": {"fet":{"ex1":2.6283524,"ex2":false,"ex3":0.20689656,"ex4 ":8,"ex5":true,"yes":false},"tls":{"req":{"alpn":["h2","http/1.1"],"ciphers":[52393,52392,49195,49199,49196,49200,491 61,49171,49162,49172,156,157,47,53,49170,10,4867,4865,4866],"compression":"AA==","random":"uOM5Tkepx4/ZOeRmBd/E2xr7Zd 1QjKplUwquPGyNEsU=","session":"gd/v6k3B5t9v3AHV3Yao98eio2czN+8ckA5pFaD1uFI=","supported_versions":[772,771],"version" :771},"resp":{"cipher":4867,"compression":0,"random":"95MrDU7yAjjSQ1XoF3+ojARuhC7Jpagm7eqyx0clkrM=","session":"gd/v6k 3B5t9v3AHV3Yao98eio2czN+8ckA5pFaD1uFI=","supported_versions":772,"version":771}},"trojan":{"seq":[419,4690,167,135]," yes":true}}} 2025-12-20T18:04:56+01:00       INFO    TCP stream action       {"id": 2002560879681339392, "src": "192.168.30.117:335 12", "dst": "1.1.1.1:18249", "action": "block"} 再比如這個: 而且長時間的向同一個IP的同一埠發起連接,(不管有沒有套TLS,盜用的是哪個網域) 本身就讓人起疑 (儘管 XHTTP 試圖通過上下行分離改善,但仍然是杯水車薪)
在互联网追求隐私和在公共浴场不愿意被他人看到裸体一样是个伪命题,或许会有少部分人在购买节点时会考虑其隐私性,但是绝大多数人追求的是节点的速度和可靠性还有价格这才是主要矛盾。我不能说你追求隐私安全不对,只能说在你使用他人提供的服务的时候隐私就注定不存在了,你唯一能做的可能是降低你隐私内容重要性的比重和降低因其带来的损失?
@ #1 只要使用互联网就没有隐私 这样说实则太过于非黑即白了喵,“隐私不绝对即不隐私” 诚然,绝对的隐私是最理想的,但是,正如我们无法保证走在路上一定不会摔跤喵 正如我们无法保证电梯一定不会故障喵,直接说“使用互联网就没有隐私” 这和“只要开车就一定会出交通事故”简直是一类的逻辑喵 实际上如果拿“某件事情不一定xx,所以这件事不xx”或者“某件事情不一定xx,所以这件事xx” 的逻辑,套在许多事情上都可以,但是它是正确的假说,无意义的结论喵 “使用互联网就没有隐私”,如“只要出门安全的家门就不存在” 但是,为什么要给家门安锁呢,安全不存在,那么直接夜不闭户不是更方便省事吗 可能是因为安装门锁带来的安全感和收益更加直观吧喵 追求隐私的收益和防患于未然类似,并不立竿见影,但是因而直接说隐私不存在显然不对喵 隐私不是非有即无,安全也是 倒不如说,很多事都是这样喵 _ 全世界都是一样 全世界都是一样的,棱镜门不知道吗? 棱镜门揭示了大规模监听不假 但是它是隐私被侵犯的实证,不是隐私不存在的实证 甚至就“全世界都是一样监听”的命题,这也只是必要不充分喵 同时,大规模监听的存在,和我们出门交通事故风险的存在相同 都不足以证明隐私不存在和安全不存在喵
在此补充一些个人见解 对于海外以口碑著称的 VPN 服务商 他们的隐私政策一般来说是相对完善的 当然,所谓无日志收集也更多是服务商的宣传,我们实际上很难去打包票 另一方面,他们存在水土不服的问题,大多在国内无法正常使用 _ 对于国内通行的“机场”,在技术上事实归属于代理 实际上处于灰色地带,即使存在隐私政策,很多也欠缺法律支持 和文中提到的“个人自建”一样,在被代理流量为正常的 TLS 流量(不讨论ECH/ESNI)情况下 代理服务商实际上可以知道:用户IP,目标网站IP,目标网站域名 一些信息常说“盗号”,实际上只要 TLS 不失效(排除MITM),这在密码学上是不可能的 目标网站的域名泄露恐怕也正是“历史记录”的来源(此外,自建的人的服务器提供商也应该可以知道这些) 它来自于 TLS 未加密的部分:SNI (URL 的路径部分是加密的,明文的只有域名,比如https://google.com/1234/1234,只有google.com是可见的,/1234/1234并不可以被窥探) 对此的解法正是 ECH(草案为 ESNI)[[1]](https://datatracker.ietf.org/doc/id/draft-ietf-tls-esni-08.html)[[2]](https://blog.cloudflare.com/announcing-encrypted-client-hello/) 如果你真打算使用它,需要注意的是,浏览器还需要 DNS over HTTPS 来获取目标域名的 HTTPS 记录以便加密 SNI (需要对浏览器本身透明代理) | 另外目前支持 ECH 的网站就供应商来说并不多 (数量上, Cloudflare CDN 免费版本的网站应该都已经支持(实际上是 Cloudflare 支持)) 这在目前仅是缓兵之计 此外,除去代理服务商,可以知道 SNI 的还有代理服务商的 ISP(互联网服务供应商) 甚至更多中间人 _ 链式代理使得流量为 你-->A代理服务-->B代理服务-->目标网站 算是个不错的解法(缺点是速度) 它不算解决了信息泄露的问题,但是使得身份关联减弱,甚至身份隔离 当然,要是目标网站知道你的电话号码那么这之前的代理其实都没有意义
@ #11 有没有可能是泄露出来的
虚拟专用网的最好应用就是其本来的用途,可控的vpn(例如自建) 从公网连接到受信任的专用网络(例如家庭内网,公司内网),其隐私和安全性是非常高的,这点是没什么疑问的,在企业上也有很多应用。而不是选择其他不靠谱的服务商,也不是用来🪜。 vpn的流量特征很明显,现在基本上过不了gfw,一般也不用,它们可能叫这个,可能用的也不是这个。 一般来说,这样代理基本上隐私性还算不错了。 启用DOH (加密 DNS 请求) 启用ECH(加密 SNI) 混淆代理(例如Trojan) 也可以再加一个cloudflare 流量转发,也算链式代理吧,有种大隐隐于市的感觉。不过完全透明还是不太可能,上述只是针对 ISP ,确实像上面所说,信任转移的问题,代理服务器虽然不知道你干了什么,但是还是知道你去了哪里。
@ #8 如果你說的是地址生成器之類的,那其實那些資訊幾乎都是根據規律生成的 (雖然不能說它一定假,因爲可能出現巧合) 以這裏拿到的一個爲例: $ curl https://www.meiguodizhi.com/api/v1/dz -X POST -d '{"method":"address","path":"/"}' | jq  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed 100  1345 100  1314 100    31   625    14   0:00:02  0:00:02 --:--:--   640 {  "address": {    "Address": "1394  Norman Street",    "Telephone": "562-244-8607",    "Address_Alias": "",    "Trans_Address": "",    "TransCnAddress": "",    "Fax": "",    "City": "Long Beach",    "Zip_Code": "90802",    "rowkey": "05be26f3-8095-4c19-ac69-c14c5f76dcca",    "State": "CA",    "State_Full": "California",    "Expires": "07/2027",    "CreditCardType": "Visa",    "CreditCardNumber": "4716556426568067",    "CVV2": "029",    "Full_Name": "Monu Ella",    "Gender": "Female",    "FullNameTran": "莫努埃拉",    "Title": "Mrs.",    "Birthday": "8/14/2008",    "Username": "provincered-hot",    "Password": "hF4DBmPMf1e0",    "Height": "5' 7\" (176cm)",    "Weight": "149.4lbs (67.8kg)",    "Temporary_mail": "[email protected]",    "System": "Windows 10",    "GUID": "c7710da7-9684-40c1-aca1-5ca7f29cf167",    "Blood_Type": "",    "BrowserUserAgent": "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.35 38.25 Safari/537.36 Core/1.70.3722.400 QQBrowser/10.5.3751.400",    "Educational_Background": "Doctorate and/or professional degree",    "Hair_Color": "Black",    "Occupation": "Plumber, Licensed Vocational Nurse",    "Website": "nvfwvvzkr.com",    "Security_Question": "what in the world is ssn?",    "Security_Answer": "cloudspiteful",    "SocialSecurityNumber": "789-40-7945",    "EmploymentStatus": "Retired", # Retired 退休的;退職的;退役的_    "Monthly_Salary": "$5,400",    "Company_Size": "33-50 employees",    "Company_Name": "Wheels Discount Auto"  },  "status": "ok" } 這份資料就是一眼假 (關於2008年出生的人已經退休了這檔事)
首先需要澄清一個誤區 你買到/找到的能在大陸使用的梯子 ≠ VPN (這兩目前的用途,技術細節都存在很大差異,而且海外的商業 VPN 大部分都不能過牆) 大部分的 VPN, Wireshark 現在都能識別了。(因此這裏假定你講的是各種過牆用的代理) 對於大部分公開的代理而言,額外的隱私安全基本上不存在 : 2025/12/19 07:05:26.277561 [Info] [3354524378] proxy/vless/inbound: received request for tcp:ipinfo.io:80 2025/12/19 07:05:26.277612 [Debug] [3354524378] proxy: Xtls Unpadding new block, content 73 padding 199 command 0 2025/12/19 07:05:26.279232 [Info] [3354524378] app/dispatcher: sniffed domain: ipinfo.io 2025/12/19 07:05:26.279266 [Info] [3354524378] app/dispatcher: taking detour [direct] for [tcp:ipinfo.io:80] 2025/12/19 07:05:26.279280 [Info] [3354524378] transport/internet/tcp: dialing TCP to tcp:ipinfo.io:80 2025/12/19 07:05:26.279292 [Debug] [3354524378] transport/internet: dialing to tcp:ipinfo.io:80 2025/12/19 07:05:26.279338 from 192.168.30.129:34996 accepted tcp:ipinfo.io:80 [vless-in -> direct] 2025/12/19 07:05:26.282673 [Info] [3354524378] proxy/freedom: connection opened to tcp:ipinfo.io:80, local endpoint 1 92.168.30.23:44732, remote endpoint 34.117.59.81:80 0000 xx xx xx xx xx xx xx xx xx xx xx xx 08 00 45 00 ............E. 0010 00 7d 91 91 40 00 40 06 6c 64 c0 a8 1e 17 22 75 .}..@[email protected]...."u 0020 3b 51 95 a6 00 50 b0 87 ed e2 80 e3 d3 bb 80 18 ;Q...P.......... 0030 01 f6 3a 21 00 00 01 01 08 0a 08 bf ff 89 9b 41 ..:!...........A 0040 c9 a6 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 ..GET / HTTP/1.1 0050 0d 0a 48 6f 73 74 3a 20 69 70 69 6e 66 6f 2e 69 ..Host: ipinfo.i 0060 6f 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 63 o..User-Agent: c 0070 75 72 6c 2f 38 2e 31 31 2e 31 0d 0a 41 63 63 65 url/8.11.1..Acce 0080 70 74 3a 20 2a 2f 2a 0d 0a 0d 0a pt: /.... 0000 xx xx xx xx xx xx xx xx xx xx xx xx 08 00 45 00 ............E. 0010 02 ae ae 83 40 00 40 06 4d 41 22 75 3b 51 c0 a8 ....@[email protected]"u;Q.. 0020   1e 17 00 50 95 a6 80 e3 d3 bb b0 87 ee 2b 80 18   ...P.........+.. 0030   01 fd 57 ab 00 00 01 01 08 0a 9b 41 cd 60 08 bf   ..W........A... 0040   ff 89 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f   ..HTTP/1.1 200 O 0050   4b 0d 0a 61 63 63 65 73 73 2d 63 6f 6e 74 72 6f   K..access-contro 0060   6c 2d 61 6c 6c 6f 77 2d 6f 72 69 67 69 6e 3a 20   l-allow-origin:  0070   2a 0d 0a 78 2d 66 72 61 6d 65 2d 6f 70 74 69 6f   *..x-frame-optio ... 01a0   73 70 6f 72 74 2d 73 65 63 75 72 69 74 79 3a 20   sport-security: 01d0 6e 73 0d 0a 0d 0a 7b 0a 20 20 22 69 70 22 3a 20 ns....{. "ip": 01e0 22 xx xx xx xx xx xx xx xx xx xx xx xx xx 22 2c "xxx.xxx.xxx.xxx", 01f0 0a 20 20 22 63 69 74 79 22 3a 20 22 54 61 69 70 . "city": "Taip 0200 65 69 22 2c 0a 20 20 22 72 65 67 69 6f 6e 22 3a ei",. "region": 0210 20 22 54 61 69 77 61 6e 22 2c 0a 20 20 22 63 6f "Taiwan",. "co 0220 75 6e 74 72 79 22 3a 20 22 54 57 22 2c 0a 20 20 untry": "TW",. 0230 22 6c 6f 63 22 3a 20 22 32 35 2e 30 35 33 31 2c "loc": "25.0531, 0240 31 32 31 2e 35 32 36 34 22 2c 0a 20 20 22 6f 72 121.5264",. "or 0250 67 22 3a 20 22 xx xx xx xx xx xx xx xx xx xx xx g": "REDACTED 0260 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx REDACTED REDACTED 0270 22 2c 0a 20 20 22 74 69 6d 65 7a 6f 6e 65 22 3a ",. "timezone": 0280   22 41 73 69 61 2f 54 61 69 70 65 69 22 2c 0a 20   "Asia/Taipei",.  0290   20 22 72 65 61 64 6d 65 22 3a 20 22 68 74 74 70    "readme": "http 02a0   73 3a 2f 2f 69 70 69 6e 66 6f 2e 69 6f 2f 6d 69   s://ipinfo.io/mi 02b0   73 73 69 6e 67 61 75 74 68 22 0a 7d               ssingauth".} 因爲代理的本質就是 信任轉移 (從信任你的 ISP ,骨幹網節點 轉移到 代理供應商/機場主) 就目前而言,大部分公網站點都有套 TLS,但你的 ClientHello 還是明文的 (雖然目前有部分站點啓用了ECH,但整體上是沒差的): 主流的代理平臺也都能辨識此類流量: 2025/12/19 07:29:17.449184 [Info] [3219161342] proxy/vless/inbound: received request for tcp:www.kungal.com:443 2025/12/19 07:29:17.449305 [Debug] [3219161342] proxy: Xtls Unpadding new block, content 517 padding 487 command 0 2025/12/19 07:29:17.449323 [Debug] [3219161342] proxy: XtlsFilterTls found tls client hello! 517 2025/12/19 07:29:17.449334 [Info] [3219161342] app/dispatcher: sniffed domain: www.kungal.com 2025/12/19 07:29:17.449347 [Info] [3219161342] app/dispatcher: taking detour [direct] for [tcp:www.kungal.com:443] 2025/12/19 07:29:17.449368 [Info] [3219161342] transport/internet/tcp: dialing TCP to tcp:www.kungal.com:443 2025/12/19 07:29:17.449379 [Debug] [3219161342] transport/internet: dialing to tcp:www.kungal.com:443 2025/12/19 07:29:17.449333 from 192.168.30.129:38824 accepted tcp:www.kungal.com:443 [vless-in -> direct] 2025/12/19 07:29:17.756774 [Info] [3219161342] proxy/freedom: connection opened to tcp:www.kungal.com:443, local endp oint 192.168.30.23:59120, remote endpoint 172.67.190.131:443 2025/12/19 07:29:18.466033 [Debug] [3219161342] proxy: XtlsFilterTls found tls 1.3! 2830 TLSAES256GCMSHA384 緩解辦法有兩個: 使用 Tor 網絡配合 TBB (Tor Browser Bundle) 上網 (當然Tor網絡也有去匿名方法,感興趣的可以去找找「traffic correlation attack」) 使用鏈式代理 (如果你希望繼續使用免費節點,又不希望暴露過多隱私可以套上WARP. Xray/Sing-box/mihomo 應該都支援。如果有人感興趣的話,這裏可以單獨出一節講講怎麼配置)
访问的网址是明文的,你都使用代理了,人家肯定首先要去获取目标网址吧。内容是加密的,至于加密到什么程度我不清楚,网上说得神乎其神。按我的理解tls加密应该没有办法破解吧
@ #6 呃,有一些网站专门提供银行卡号和身份证等信息,自然也包括外国人,关键还是免费的
@ #6 全世界都是一样的,棱镜门事件不知道吗?
你以为帽子叔叔的专业技术人员不会查吗?人家只是上面除非硬性要求懒得查罢了翻墙肯定是有记录的除非人在国外,真想查你干了啥请专业的来肯定能查到啊,但是人家也知道摸鱼啊)。人家不知道翻有翻墙的吗,但是人家一般也不知道你翻墙干嘛去了啊,总不能都抓起来吧,毕竟也有不少用公共网络外国ip翻墙学习查资料的。除非运气不好被查到了也就是被叫过去喝杯茶写份协议啥的就过去了,否则就是真的干了不该干的事情被上面查到了,那性质就没单单翻墙这么简单了,“要想人不知,除非己莫为”。一般人翻墙看黄还是浏览外国论坛啥的等等的性质到还是没那么严重
互联网就像卫星,你能看到整个世界,整个世界也能看到你。
隐私的话可以用tails系统,可以做到无痕,保密性非常强
你不要觉得使用VPN就有隐私了,其实就算你使用tor代理,还是一样能查得到。只要使用互联网就没有隐私,这一点全世界都是一样