Mitmproxy 7 支援 TLS over TCP 的分析了

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 安裝的話)

讓 Tor 的 .onion 支援 HTTPS

看到 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.inkushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion 就可以了。

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

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

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

從「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 HTTPDNS over TLS,以及 ECH (Encrypted Client Hello)。

Squid + GnuTLS 不支援 Intermediate Certificate 的問題

先前在「架設 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.orgDST 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 了...

架設 Proxy over TLS

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_PROXYhttps_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,要給朋友共用也比較簡單。

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

IdenTrust 願意再幫 Let's Encrypt 交叉簽三年

先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrustLet's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期,而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證,造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。

文章出來過了一個多月後,剛剛看到 Let's Encrypt 發佈消息,IdenTrust 願意再交叉簽名三年:「Extending Android Device Compatibility for Let's Encrypt Certificates」,當時猜測發文是要讓 IdenTrust 表態,看起來目的達成了...

話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣,之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...

Cloudflare 改推 ECH 加密整個 TLS 的 ClientHello

Cloudflare 本來在推的 ESNI 現在變成 ECH 了:「Good-bye ESNI, hello ECH!」。

上面這張圖是 ESNI,下面這張是 ECH:

可以看出來 ECH 最主要的差異是把本來的 ClientHello 都加密包起來了,伺服器會先試著解內層的 ClientHelloInner,失敗的時候會用外層的 ClientHelloOuter:

The server completes the handshake with just one of these ClientHellos: if decryption succeeds, then it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter.

看得出來 ECH 的其中一個目標是讓他看起來跟一般的 TLS 連線一樣,這樣就能順便解掉 censorship 的問題...

其中一個原因應該也是因為之前中國與俄國的直接封掉 ESNI:

In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic.

In October 2020, Russian ISPs such as Rostelecom and its mobile operator Tele2 started blocking ESNI traffic.

不過仍然還有分析 HTTPS pattern 的方式可以抓 (就是文章裡提的 traffic analysis),目前看起來只處理了 ClientHello 本身,現在還是有機會分析 handshake 過程來擋,必須繼續改善 ECH 的協定,讓整個流程看起來都跟一般的 TLS 一樣...

可以等著看,到時候在中國的效果如何了,會不會讓國外的各大服務直接打進去呢...

Dehydrated 使用 ZeroSSL 的方式

上一篇「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」提到 ZeroSSL 的服務,而各家 acme client 也都陸陸續續支援了。

Dehydrated 是在 2020/09/15 的時候實做:「EAB + ZeroSSL support」,我就抓了個新版,更新之前自己包的 PPA dehydrated-lite...

Dehydrated 的設定方式還蠻簡單的,在 /etc/dehydrated/config 裡面這樣寫:

CA=zerossl
EAB_HMAC_KEY=x
EAB_KID=y

其中兩個 EAB 的資訊可以在 ZeroSSL 網站上面取得,然後其他就照舊跑...

ZeroSSL 也提供免費的 SSL Certificate (DV) 了

Facebook 上被朋友敲可以測 ZeroSSL,另外一個透過 ACME 協定提供免費的 SSL Certificate,不過目前只有支援單一網域名稱 (DV):「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」。

我先前就有在測 ZeroSSL,不過驗證一直過不去,當時有在 Twitter 上找 ZeroSSL 帳號問,但 ZeroSSL 的人說 ACME 的部份不在客服範圍,就先丟著...

剛剛發現是自己耍笨了,原因是 nginx 沒設好造成驗證卡住,一改好後就正常了。

SSL LabsSSL Server Test 翻了一下,他的 Root CA 看起來歷史更久,應該是有機會解決 Let's Encrypt 明年會產生的 Root CA 憑證信任問題,也就是先前在「Let's Encrypt 在 Android 平台上遇到的問題」提到的問題,在 Hacker News 上的討論也可以看到有人提到這點:

Good to know, and I'm glad there's an alternative to Let's Encrypt, just in case. Is ZeroSSL trusted by old Android devices? If so, that might be a work-around for Let's Encrypt's cross-signing from IdenTrust expiring.

不過也有些人有疑慮,畢竟提供這個服務後面的公司幹過不少壞事:

If zerossl is reselling/a subsidiary of sectigo, that’s enough reason to never use this.
Sectigo is the new name for Comodo. The same bunch of pricks who tried to trademark “Let’s Encrypt”.

Other players in the acme cert “business” is great. Renaming a slime ball name and carrying on like nothing happened is not ok.

但看起來至少是多了一個選擇...

Let's Encrypt 在 Android 平台上遇到的問題

同樣是「Standing on Our Own Two Feet」這篇文章,Let's Encrypt 預期明年九月後會在 Android 上遇到嚴重的相容性問題。

很舊的裝置主要是透過 IdenTrust 的 Root CA (DST Root CA X3) 對 Let's Encrypt 的 Intermediate CA (目前主要是 Let's Encrypt Authority X3) 簽名,從而建立憑證的信任鍊,而新的裝置除了 IdenTrust 的 CA 外,也信任了 Let's Encrypt 自家的 Root CA (ISRG Root X1):(出自「Chain of Trust」)

在 2016 年四月正式對外啟用時主要是靠 IdenTrust 的 cross-sign,而也是在 2016 年時 Let's Encrypt 自家的 Root CA (ISRG Root X1) 陸陸續續被各家收進 CA store。

所以這個時間點之前的 Android (大約是 7.1.1) 算是個相容性的分界線,在這個版本前 (而且系統無法更新的) 都只能靠 IdenTrust 的 cross-sign,這看起來大約有 33.8%,實際的流量大約是 1%~5%:

Currently, 66.2% of Android devices are running version 7.1 or above. The remaining 33.8% of Android devices will eventually start getting certificate errors when users visit sites that have a Let’s Encrypt certificate. In our communications with large integrators, we have found that this represents around 1-5% of traffic to their sites. Hopefully these numbers will be lower by the time DST Root X3 expires next year, but the change may not be very significant.

目前還有大約十個月左右的緩衝期,但大家都知道 Android 的更新速度,就十個月來說看起來不太樂觀...

官方有給他們不願意再取得一次 cross-sign 的原因,不過我覺得這個理由就很怪了,這個描述看起來是 IdenTrust 不願意再簽發一次?直覺覺得 IdenTrust 站在商業立場應該是很願意才對?而且除了 IdenTrust,應該也有其他家會有興趣?

Can we get another cross-signature? We’ve explored this option and it seems unlikely. It’s a big risk for a CA to cross-sign another CA’s certificate, since they become responsible for everything that CA does.

也有可能是放個話讓 IdenTrust 表態?先繼續看下去...

最差的情況應該就是沒有 cross-sign,然後也沒提供其他的 workaround,這樣就是買一般的 SSL certificate 來解了...