Quantcast
Channel: https – Gea-Suan Lin's BLOG
Viewing all 267 articles
Browse latest View live
↧

RFC 定義的 application/problem+json (或是 xml)

February 11, 2021, 1:26 am
$
0
0

剛剛在 Clubhouse 上聽到保哥提到了 RFC 7807 這個東西 (Problem Details for HTTP APIs)，剛剛翻瀏覽器累積的 tab，發現原來先前有看到，而且有打算要出新版的消息：

RFC 7807 裡面這樣定義的方式可以讓 client 端直接判斷 Content-Type 知道這個回傳資料是不是錯誤訊息，不然以前都是 JSON 就得再另外包裝。用 Content-Type 的作法可以讓判斷條件變得清晰不少。

除了 application/problem+json 與 application/problem+xml 以外，在「3.1. Members of a Problem Details Object」裡面則是說明 JSON (或是 XML) 裡面有哪些必要以及可選的資訊要填，然後「3.2. Extension Members」這邊則大概描述一下怎麼擴充。

先有個印象，之後新規劃的東西可以考慮進去...

↧
Search

Dehydrated 取得憑證的預設演算法改成 secp384r1

February 13, 2021, 8:55 pm
$
0
0

這兩天弄 dehydrated，結果發現 v0.7.0 取得憑證的預設演算法改成 ECC 的 secp384r1 了：

Using EC secp384r1 as default certificate type

這會導致很多「稍微舊一點」的 client 失效 (瀏覽器與 library)，不知道為什麼要預設... 目前避開的方法是強制在 /etc/dehydrated/config 內設定使用 rsa：

KEY_ALGO=rsa

剛剛把公司一堆機器改上去，然後把自己的 server 也加一加...

↧
↧

架設 Proxy over TLS

March 10, 2021, 10:03 am
$
0
0

HTTP Proxy 算是很好用的跳板手段，瀏覽器有很多套件可以依照各種條件自動切換到不同的 Proxy 上面。

但一般在使用 HTTP Proxy (走 Port 3128 或是 8080 的那種) 使用明文傳輸，就不適合使用 Proxy-Authenticate 把帳號密碼帶進去 (出自 RFC 7235 的「Hypertext Transfer Protocol (HTTP/1.1): Authentication」)，查了一些資料後發現，現在的瀏覽器基本上都支援 Proxy over TLS 了，也就是 Proxy Protocol 外面包一層 TLS，保護瀏覽器到 Proxy 中間的流量。

順便說一下，這邊講的 HTTPS Proxy 跟環境變數裡的 HTTPS_PROXY 與 https_proxy 不太一樣，這兩個環境變數是說「HTTPS 協定要走哪個 Proxy 設定」。

HTTPS Proxy 主要有幾份文件可以參考，第一份可以是 Squid 的「Feature: HTTPS (HTTP Secure or HTTP over TLS)」，裡面提到了伺服器上的設定 https_port，以及瀏覽器的支援度。

第二份是認證的部份，也是 Squid 的文章「Proxy Authentication」這篇，走 ncsa 認證基本上就可以吃熟悉的 .htpasswd 格式了。

接下來就是安裝與設定了，在 Ubuntu 20.04 可以直接用 apt 裝 squid4，因為有包括了 --enable-gnutls；而在 Ubuntu 18.04 就不能這樣做了，因為 Ubuntu 裡面是 squid3，而且沒有加上 --enable-openssl 或是 --enable-gnutls，會比較麻煩...

其他基本上就是塞設定進去就可以了... 然後 Google Chrome 這邊可以裝「Proxy SwitchyOmega」這種套件，他可以設定 HTTPS Proxy 的 Profile，然後依照網域名稱來設定要用哪個 Profile。

這樣做的好處就是不需要連 VPN 改變 routing table (通常需要登入)，就有類似 VPN 的效果，而且可以很細緻的調整流量要怎麼繞。

而且機器上也不需要 shell account 讓人跑 ssh -D1080 之類的指令開 Socks Proxy，要給朋友共用也比較簡單。

先架了台灣跟美國的，找機會再多架一些伺服器起來用...

↧

T-Mobile US 打算要賣使用者的瀏覽記錄了

March 10, 2021, 9:08 pm
$
0
0

全美第二大的 T-Mobile US 打算要賣使用者的瀏覽記錄了，除非你登入進去選擇退出：「T-Mobile to Step Up Ad Targeting of Cellphone Customers」，Hacker News 上的討論則可以看「T-Mobile to share customers' data with advertisers unless they opt out (thehill.com)」這邊。

The No. 2 U.S. carrier by subscribers said in a recent privacy-policy update that unless they opt out it will share customers’ web and mobile-app data with advertisers starting April 26.

這次的改變包括了 2020 年併購 Sprint 的使用者：

T-Mobile’s new policy will also cover Sprint customers acquired through the carriers’ 2020 merger. Sprint had previously shared similar data only from customers who opted into its third-party ad program.

所以連在美國都有 DNS over HTTPS (或是 DNS over TLS) 與 ESNI 需求了...

↧

Squid + GnuTLS 不支援 Intermediate Certificate 的問題

March 12, 2021, 11:01 am
$
0
0

先前在「架設 Proxy over TLS」這邊提到了我用 Squid 架 Proxy over TLS 的服務起來用，本來在家裡跑得好好的，但到了公司發現卻不能用，追蹤後發現是目前 Ubuntu 裡面包的 Squid + GnuTLS 沒有辦法支援 intermediate certificate 的問題，而且有人問過了：「[squid-users] HTTPS_PORT AND SSL CERT」。

這邊先講測試的方法，然後後面再講解法。

測試的方式可以用 openssl s_client -connect hostname:port 測，正常的情況會可以看到兩層。

在這邊的例子裡，R3 簽了 home.gslin.org，DST Root CA X3 簽了 R3，而 DST Root CA X3 則在 root certificate 名單中：

$ openssl s_client -connect home.gslin.org:443
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = home.gslin.org
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN = home.gslin.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

如果沒有送出 Intermediate Certificate 的話就會導致信任鏈無法建立，像是我故意設計的 nointermediate.gslin.com 這樣，R3 簽了 nointermediate.gslin.com，但 R3 並沒有在 root certificate 的名單中：

$ openssl s_client -connect nointermediate.gslin.com:443
CONNECTED(00000003)
depth=0 CN = nointermediate.gslin.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = nointermediate.gslin.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = nointermediate.gslin.com
verify return:1
---
Certificate chain
 0 s:CN = nointermediate.gslin.com
   i:C = US, O = Let's Encrypt, CN = R3                                
---

而想到的解法就是重新包一份 Squid 出來用，把本來的 --with-gnutls 改成 --with-openssl。

這邊會先裝 Build-Depends 裡面指定的東西，然後加裝 libssl-dev，接著換掉 --with-gnutls 後編譯，最後產生 .deb：

sudo apt install -y ed libltdl-dev pkg-config build-essential cdbs debhelper dpkg-dev lsb-release dh-apparmor libcppunit-dev libcap2-dev libdb-dev libecap3-dev libexpat1-dev libgnutls28-dev libkrb5-dev comerr-dev libldap2-dev libnetfilter-conntrack-dev libpam0g-dev libsasl2-dev libxml2-dev nettle-dev libssl-dev
apt-get source squid
cd squid/squid-4.10
sed -i -e 's/--with-gnutls/--with-openssl/' debian/rules
cd ..
dpkg-buildpackage -rfakeroot -uc -b

編好的 .deb 就可以拿到其他機器上裝了，然後就可以吐出 intermediate certificate 了...

↧
↧

英國的 ISP 開始記錄使用者的連線資訊

March 15, 2021, 1:10 am
$
0
0

從「Two UK Broadband ISPs Trial New Internet Snooping System」這邊看到英國的 ISP 開始記錄使用者的連線資訊，簡化後的 log 樣子像是這樣：

Two unnamed broadband or mobile ISPs are reportedly helping the UK Home Office and the National Crime Agency (NCA) to trial a new internet snooping system on their customers, which is being conducted as part of the controversial 2016 UK Investigatory Powers Act (aka – snoopers charter).

加上「T-Mobile US 打算要賣使用者的瀏覽記錄了」這篇，繼續推廣 DNS over HTTP、DNS over TLS，以及 ECH (Encrypted Client Hello)。

↧

Google Chrome 要推動預設使用 HTTPS 連線

March 24, 2021, 6:07 pm
↧

讓 Tor 的 .onion 支援 HTTPS

March 25, 2021, 4:31 pm
$
0
0

看到 Tor 官方的「Get a TLS certificate for your onion site」這篇，查了一下發現先前漏掉一些資訊...

首先是 2020 年二月的時候 CA/Browser Forum 就已經在投票是否有開放 v3 .onion 的憑證：「[Servercert-wg] Voting Begins: Ballot SC27v3: Version 3 Onion Certificates」，而結果也順利通過：「Ballot SC27v3: Version 3 Onion Certificates - CAB Forum」。

而一直到今年才有消息，希臘的 Harica CA 在月初時正式支援 v3 .onion：「Harica CA now supports issuance of DV .onion certificates」，不過拿 SSL Lab 的工具翻了一下，發現不是所有的平台都有認 Harica CA：「SSL Report: www.harica.gr (155.207.1.46)」，裡面可以看到 Java 的 trust store 裡面沒有 Harica CA：

實際測了一下流程，Harica CA 的網站會等到認證完後收費，看起來可以透過信用卡，但我就沒走下去了：

想要看看的人可以看 Kushal Das 的 kushaldas.in 與 kushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion 就可以了。

另外查了一下 Certificate Transparency，可以看到我自己的 onion server 先被簽出來了：「5g4ukauwohjqjpydwqnkfkxxtcxkgtusr5twji53stfdzbz54xrmckid.onion」。

等 Let's Encrypt 出來後再說吧，目前看起來「Support for FQDNs under .onion」這邊沒有什麼進度...

↧
Search

試用 Cloudflare 的 Argo Tunnel

April 18, 2021, 12:22 pm
$
0
0

Cloudflare 宣佈讓大家免費使用 Argo Tunnel 了，也順便改名為 Cloudflare Tunnel 了：「A Boring Announcement: Free Tunnels for Everyone」。

Starting today, we’re excited to announce that any organization can use the secure, outbound-only connection feature of the product at no cost. You can still add the paid Argo Smart Routing feature to accelerate traffic.

As part of that change (and to reduce confusion), we’re also renaming the product to Cloudflare Tunnel. To get started, sign up today.

Cloudflare Tunnel 的功能就像 ngrok，在用戶端的機器上跑一隻 agent 連到 Cloudflare 或是 ngrok 的伺服器，這樣外部連到 Cloudflare 或是 ngrok 的伺服器後就可以透過這組預先建好的連線連上本機的服務了，常見的應用當然就是 HTTP(S) server。

本來是付費功能，一般使用者應該也不會需要這個功能，這次把這個功能免費丟出來的用意不知道是什麼...

不過既然都免費了，還是花了點時間測了一下，可以發現 ngrok 的設定比較簡單，Cloudflare 的 cloudflared 設定起來複雜不少，不過文件還算清楚，照著設就好。

Anyway，有些事情有了 Cloudflare Tunnel 就更方便了，像是有些超小型的 VPS 是共用 IPv4 address 而且沒有 IPv6 address 的，可以透過 cloudflared 反向打進去提供服務，同樣的，在 NAT 後面的機器也可以透過這個方法很簡單的打通。

順便說一下，現在的 blog.gslin.org 就是跑在 cloudflared 上面了，官方提供的 ARM64 binary 跑在 EC2 的 t4g 上面目前看起來沒有什麼問題，而且比起本來 nginx 都是抓到 Cloudflare 本身的 IP，現在加上這兩行後反而就可以抓到真的使用者 IP address 了：

    set_real_ip_from 127.0.0.1;
    real_ip_header X-Forwarded-For;

跑一陣子看看效果如何...

↧
↧

QUIC 成為標準，從 RFC 8999 到 RFC 9002

May 28, 2021, 2:56 pm
$
0
0

前幾天的新聞了，這兩天 Fastly 與 Cloudflare 也都發文章出來了，QUIC 成為標準：「QUIC is now RFC 9000」、「QUIC Version 1 is live on Cloudflare」。

主要是這兩家都發稿宣傳他們的平台都支援 QUIC 了，接下來可以等一些測試報告，看看在 web 這種已經有不少複雜的 workaround 機制下，TCP BBR 環境的 HTTP/2 跟 QUIC 環境會有多少差異... 記得 QUIC 也是 BBR-based 的演算法。

在 QUIC 下的 https 協定會走 443/udp，如果防火牆是預設阻擋所有連線，然後逐條開放的話，需要另外開這組設定。

另外就是等 nginx 支援了，在「NGINX QUIC Preview」這邊有些資料，然後「">nginx-quic: log」裡面可以看到東西，裡面不少 commit 只是跟 nginx 本家同步而已，不過還是可以看到一些跟 QUIC 有關的...

↧

CloudFront 宣佈支援 ECDSA 的 Certificate

July 15, 2021, 7:06 pm
$
0
0

Amazon CloudFront 宣佈支援 ECDSA 的 certificate：「Amazon CloudFront now supports ECDSA certificates for HTTPS connections to viewers」。

用主要是讓 certificate 更小，讓 HTTPS 建立時的過程更快 (包括了傳輸的速度與計算的速度)：

As a result, conducting TLS handshakes with ECDSA certificates requires less networking and computing resources making them a good option for IoT devices that have limited storage and processing capabilities.

很久以前好像有看到資料說 256 bits 的 EC 運算量跟 768～1024 bits 的 RSA 差不多，但一時間找不到資料...

目前 CloudFront 只支援 NIST P-256 (secp256r1，或稱作 prime256v1)：

Starting today, you can use Elliptic Curve Digital Signature Algorithm (ECDSA) P256 certificates to negotiate HTTPS connections between your viewers and Amazon CloudFront.

但 NIST P-256 一直為人詬病，在「SafeCurves: choosing safe curves for elliptic-curve cryptography」這邊可以看到 NIST 宣稱的效率設計實際上都不是真的：

Subsequent research (and to some extent previous research) showed that essentially all of these efficiency-related decisions were suboptimal, that many of them actively damaged efficiency, and that some of them were bad for security.

但目前標準是往 NIST P-256、NIST P-384 與 NIST P-521 靠攏 (主要是受到 CA/Browser Forum 的限制)，要其他 curve 的 certificate 也沒辦法生，目前可能還是繼續觀望...

↧

Chromium 系列瀏覽器對 Google Search Engine 的不公平最佳化

July 15, 2021, 9:34 pm
$
0
0

在 tab 上放了一陣子的連結，忘記是哪邊看到的，在講 Chromium 系列瀏覽器會針對 Google Search Engine 最佳化：「Google’s unfair performance advantage in Chrome」。

作者發現 Chromium 瀏覽器會預先開 HTTPS 連線連到搜尋引擎，這樣可以大幅降低建立 HTTPS 連線時所需要的時間，包括了 DNS 查詢、TCP handshake 與 TLS handshake：

I was looking for something else when I stumbled upon a feature called PreconnectToSearch. When enabled, the feature preemptively opens and maintains a connection to the default search engine.

問題在於這個功能只開給 Google Search 使用：

There’s just one small catch: Chromium checks the default search engine setting, and only enables the feature when it’s set to Google Search.

在 search_engine_preconnector.cc (HEAD 版本) 這邊可以看到這段程式碼：

// Feature to limit experimentation to Google search only.
const base::Feature kPreconnectToSearchNonGoogle{
    "PreconnectToSearchNonGoogle", base::FEATURE_DISABLED_BY_DEFAULT};
}  // namespace features

作者有提到，的確這個功能會對 search engine 有不小的衝擊，但可以透過擴充 OpenSearch Descriptions 或是 Well-Known URI 的方式提供，現在這樣寫死在程式碼裡面完全就是不公平競爭。

↧

Mitmproxy 7 支援 TLS over TCP 的分析了

July 16, 2021, 9:26 pm
$
0
0

在 Hacker News 首頁上看到 Mitmproxy 7 的消息：「Mitmproxy 7」。

比較重要的功能應該就是可以針對任意的 TLS 連線攔截分析了：

不過像是 STARTTLS 這類先在 plaintext 溝通，然後送出指令進入 TLS 的方式，目前就還沒支援：

Opportunistic TLS (STARTTLS) is not supported yet, but regular TCP-over-TLS just works!

另外是可以分析 WebSocket 內的傳輸資料：

應該是跑個 pip install -U mitmproxy 就可以升級了... (如果先前是用 pip 安裝的話)

↧
↧

Firefox 支援 HTTPS RR

September 12, 2021, 1:51 am
$
0
0

在「Firefox 92.0, See All New Features, Updates and Fixes」這邊看到支援 HTTPS RR：

More secure connections: Firefox can now automatically upgrade to HTTPS using HTTPS RR as Alt-Svc headers.

在「Enabling HTTPS RR on release」這邊決定啟用的，使用的標準是「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」這個，可以看到目前還是 draft (draft-ietf-dnsop-svcb-https-07)。

HSTS 是 Trust on first use，也就是在第一次連線時 server side 會送出 HSTS header，之後瀏覽器遇到同一個網站時就會都強制使用 HTTPS。

如果要確保第一次也是強制使用 HTTPS，在這之前必須靠瀏覽器內建的清單 HSTS Preload List 才能確保安全性，這次的 HTTPS RR 算是補上這個缺口。

在使用者環境有 DNS over HTTPS (DoH) 或是 DNS over TLS (DoT)，再加上 DNS resolver 會檢查 DNSSEC 的前提下，整條環境就接起來了。

不過實際讀了 spec 會發現 SVCB RR 與 HTTPS RR 想做的事情太多了，話說愈複雜的東西愈容易出包，先放著觀望看看好了...

↧

前幾天綠界 *.ecpay.com.tw 憑證爆掉的事情

October 19, 2021, 11:16 am
$
0
0

前幾天社群蠻熱鬧在討論綠界的 *.ecpay.com.tw 憑證被上游 Sectigo 給 revoke，而導致 login.ecpay.com.tw 無法連線的問題 (ba:d3:26:14:db:53:1b:56:49:8d:de:d5:0c:68:b9 這張，另外參考點了 OCSP 檢查的 https://crt.sh/?id=3608838685&opt=ocsp 結果)，可以看 domain 知道這個網域比較偏使用者的用途 (而非 API 類)，會買 EV 主要就是要用在瀏覽器上，所以這邊主要就討論瀏覽器受到影響的部份...

因為 Sectigo 是透過 CRL 與 OCSP 兩個機制把 revoke 資訊送出來，所以各家瀏覽器的處理方式會不太一樣...

首先是市占率最高的 Chrome，因為有自家的機制在處理 revoke，不走 CRL 或是 OCSP，所以大多數的使用者應該都沒有受到影響 (不確定...)，但 Firefox 與 Safari 都吃 OCSP，所以都會炸掉。

這次有看到兩個社群有一些討論，一個是「https://www.facebook.com/groups/rayforum/posts/4417812681632189/」，另外一個是「https://www.facebook.com/groups/616369245163622/posts/2497356027064925/」這邊。

Vincent Liang 有貼了 Sectigo 送 revoke 的原因，在 Mozilla 的 Bugzilla 上面有 Sectigo 的主動通報：「Sectigo: Subject field with unvalidated information included in certificates」，看起來是因為在內部 code review 的時候發現 postOfficeBox (以台灣來說就是郵遞區號郵政信箱) 這個欄位的問題：

Though the postOfficeBox field is permissible for inclusion in OV certificates, any field containing unvalidated information is not permissible. Furthermore, the EV Guidelines prohibit this field at all for EV certificates.

也就是說，在 OV 憑證內可以列入 postOfficeBox，但需要確認後才能列進去；而 EV 憑證則是不允許列 postOfficeBox 的；因為這兩個原因，這些憑證都要 revoke，另外也因為 Baseline Requirements 與 EV SSL Certificate Gudidelines 的要求而需要主動通報。

Sectigo 有列出 453 個受到影響的憑證，不過發文者 Lorex L. Yang 有注意到綠界的這個憑證沒有被列在這 453 個受到影響的憑證內，但是後來也有被 revoke 掉...

所以現在問題就來了，會不會 Sectigo 根本沒通知綠界要換憑證？另外 Sectigo 的通報內容不實也是一個大問題，因為沒有人在 Bugzilla 上提到，所以我就在上面回個 comment 把這個議題拋出來，讓 Mozilla 的人知道後繼續查下去...

當然綠界花了十八個小時解決也是個問題，不過那個就不是我們能管到的了...

↧
Search

Let's Encrypt 撤銷了兩百萬個以 tls-alpn-01 驗證的憑證

January 31, 2022, 7:10 am
$
0
0

前幾天 Let's Encrypt 決定撤銷大約兩百萬個以 tls-alpn-01 簽發的憑證：「2022.01.25 Issue with TLS-ALPN-01 Validation Method」，在 Hacker News 上的討論「Issue with TLS-ALPN-01 Validation Method (letsencrypt.org)」也可以翻一下。

這次主要是有兩個修改，第一個是要 TLSv1.2 以上，不支援舊版的 TLS 驗證：

First, we now guarantee that our client which reaches out to conduct the “acme-tls/1” handshake will negotiate TLS version 1.2 or higher. If your ACME client or integration only supports a maximum TLS version of 1.1 when conducting the TLS-ALPN-01 challenge, it will break. We are not aware of any ACME clients with this limitation.

另外一個是淘汰掉 legacy OID：

Second, we no longer support the legacy 1.3.6.1.5.5.7.1.30.1 OID which was used to identify the acmeIdentifier extension in earlier drafts of RFC 8737. We now only accept the standardized OID 1.3.6.1.5.5.7.1.31. If your client uses the wrong OID when constructing the certificate used for the TLS-ALPN-01 handshake, it will break. Please either update your client, or switch to using a different validation method.

目前還是以 http-01 與 dns-01 為主，暫時不用管，但如果有人用 tls-alpn-01 的稍微注意一下吧...

↧

AWS 增加 CloudFront 的 AWS-managed prefix list 讓管理者使用

February 10, 2022, 9:04 am
$
0
0

看到 AWS 公告提供 CloudFront 的 origin subnet 資訊 (AWS-managed prefix list) 讓管理者可以用：「Amazon VPC now supports an AWS-managed prefix list for Amazon CloudFront」。

以往會自己去「AWS IP address ranges」這邊提供的 JSON 檔案定時撈出來再丟到 managed prefix list 裡面，這次的功能等於是 AWS 自己管理這個 prefix list 讓管理者使用。

馬上想的到的用途就是 HTTP/HTTPS port 了，只開放給 CloudFront 的伺服器存取：

Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself.

要注意的是這不應該當作唯一的 ACL 手段，因為其他人也可以建立 CloudFront distribution 來穿透打進你的 origin server。

另外有個比較特別的地方，這個 prefix list 的權重很重，使用他會算 55 條 rule 的量，在 security group 內很容易撞到 60 條的限制，在 route table 裡面則是直接撞到 50 條的限制；不過這兩個限制都可以跟 AWS 申請調昇：

The Amazon CloudFront managed prefix list weight is unique in how it affects Amazon VPC quotas:

  • It counts as 55 rules in a security group. The default quota is 60 rules, leaving room for only 5 additional rules in a security group. You can request a quota increase for this quota.
  • It counts as 55 routes in a route table. The default quota is 50 routes, so you must request a quota increase before you can add the prefix list to a route table.

如果 HTTP 一條，HTTPS 也一條，那就會算 110 rules 了，有暴力的感覺...

↧
↧

修正 Curl 的 TLS handshake，避開 bot 偵測機制

February 18, 2022, 12:17 am
$
0
0

利用 TLS handshake 的 pattern 可以當作是某種 fingerprint，就可以知道你是用 Curl，這個方式在蠻多 CDN 都會用在 anti-bot 機制 (像是 Cloudflare)，而剛剛看到有人投稿自己的 patch，試著將 Curl 修改成 Firefox 的 pattern：「curl-impersonate」，Hacker News 上的討論在這邊可以看到：「Show HN: Curl modified to impersonate Firefox and mimic its TLS handshake (github.com/lwthiker)」。

作者有提到這次的 patch 偏 hack，不太可能整進上游，但希望未來改的乾淨一點，然後整進上游：

I hope to do so in the future, for now the implementation is extremely hacky so I doubt it can get accepted into curl.

另外有人提出來說應該要用 Firefox ESR 版本的 pattern 而非 stable channel，也有人提出來說用 Google Chrome 的更好，不過我覺得有人開始做就已經很棒了 XD

↧

自動偵測 DNS over HTTPS 或是 DNS over TLS 的 Discovery of Designated Resolvers (DDR)

March 9, 2022, 9:30 pm
$
0
0

看到 Cloudflare 宣佈支援 Discovery of Designated Resolvers (DDR)：「Announcing experimental DDR in 1.1.1.1」。

看了一下這以後會是新的標準 (現在還在 draft)，可以自動偵測現在用的 DNS resolver 是否支援 DNS over HTTPS 或是 DNS over TLS，如果有的話就 upgrade 到 DoH 或 DoT：

This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.

目前的 spec 是去查 _dns.resolver.arpa，下面第一個是支援 DoH 的回應，第二個則是支援 DoT 的回應：

_dns.resolver.arpa  7200  IN SVCB 1 doh.example.net ( alpn=h2 dohpath=/dns-query{?dns} )
_dns.example.net  7200  IN SVCB 1 dot.example.net ( alpn=dot port=8530 )

實際上拿 1.1.1.1 測試，在 Ubuntu 20.04 下用 dig 可以看到一堆亂碼 XDDD

;; ANSWER SECTION:
_dns.resolver.arpa.     300     IN      TYPE64  \# 104 0001036F6E65036F6E65036F6E65036F6E6500000100060268320268 330003000201BB000400080101010101000001000600202606470047 00000000000000000011112606470047000000000000000000100100 0700112F646E732D71756572797B3F6E616D657D
_dns.resolver.arpa.     300     IN      TYPE64  \# 81 0002036F6E65036F6E65036F6E65036F6E65000001000403646F7400 03000203550004000801010101010000010006002026064700470000 00000000000000111126064700470000000000000000001001

改用 Docker 開了 Ubuntu 22.04 (jammy) 的 image 後，裡面的 dig 可以用 SVCB 查詢 (本來的 type64 也還是會動)，另外也把內容解出來了：

;; ANSWER SECTION:
_dns.resolver.arpa.     300     IN      SVCB    1 one.one.one.one. alpn="h2,h3" port=443 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001 key7="/dns-query{?name}"
_dns.resolver.arpa.     300     IN      SVCB    2 one.one.one.one. alpn="dot" port=853 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001

這樣就不需要寫死在系統內，但要注意這樣還是會有 attacker 擋住讓你 upgrade 的問題...

↧

使用 Tor 的 .onion 位置，而非透過 Exit Node 存取網站的好處

March 10, 2022, 3:03 am
$
0
0

在「Twitter 的 Tor Onion 位置」與「BBC 這次拿出短波廣播...」這兩篇我都有在懷疑為什麼要提供 Tor 的 .onion 位置，不是直接透過 exit node 連出去就好了嗎，結果今天看到「Why offer an Onion Address rather than just encourage browsing-over-Tor?」這篇在解釋。

對使用者來說，用 .onion 的好處是隱私性會更好，因為 exit node 本身不一定安全，必須透過 HTTPS 保護才有基本的防護，而且就算用了 HTTPS 還是可以從 HTTPS 的 handshake 得到不少資訊。

對網路本身來說，exit node 算是稀缺資源，大多數人可以架 Tor 的 relay node，但沒辦法做 exit node，因為 exit node 的特性會導致常常收到各種警告。因此能用 .onion 位置存取，也會降低對 exit node 的壓力。

另外 CA/Browser 在 2020 的時候就允許發出 .onion 憑證：「讓 Tor 的 .onion 支援 HTTPS」，看起來應該也是多一層保護...

↧
Viewing all 267 articles
Browse latest View live
Search

Latest Images

AI开始接管年轻人的「精神自留地」

AI开始接管年轻人的「精神自留地」

May 8, 2026, 7:54 pm
Brake-by-wire 時代降臨　Brembo Sensify 無煞車油制動系統登場

Brake-by-wire 時代降臨　Brembo Sensify 無煞車油制動系統登場

May 8, 2026, 7:35 pm
Brake-by-wire 時代降臨　Brembo Sensify 無煞車油制動系統登場

Brake-by-wire 時代降臨　Brembo Sensify 無煞車油制動系統登場

May 8, 2026, 7:35 pm
四川乘客吓坏全国人！全球紧急警报 汉坦病毒多国扩散？ (图)

四川乘客吓坏全国人！全球紧急警报 汉坦病毒多国扩散？ (图)

May 8, 2026, 6:52 pm
行业巨无霸诞生！Native Instruments 宣布被 inMusic 集团收购

行业巨无霸诞生！Native Instruments 宣布被 inMusic 集团收购

May 9, 2026, 12:00 am
［第4530天］無課金日記

［第4530天］無課金日記

May 8, 2026, 9:29 am
求助各位大大有無筆電推薦

求助各位大大有無筆電推薦

May 8, 2026, 8:34 am
贺信及视频：加拿大政要恭贺世界法轮大法日

贺信及视频：加拿大政要恭贺世界法轮大法日

May 8, 2026, 8:10 am
Citi AAdvantage Executive 信用卡【2026.5 更新：100k 开卡奖励】

Citi AAdvantage Executive 信用卡【2026.5 更新：100k 开卡奖励】

May 8, 2026, 7:00 am
【宏福苑五級火】七幢樓宇居民5.21至5.29再返回單位執拾 維持4人上樓、每次3小時

【宏福苑五級火】七幢樓宇居民5.21至5.29再返回單位執拾 維持4人上樓、每次3小時

May 8, 2026, 6:37 am