保護 TLS 的 Hostname

看到「Encrypted Server Name Indication for TLS 1.3」這個,由 FastlyCloudflareApple 的人聯手推出的 draft,想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key,然後使用者用這把 public key 保護 hostname 的部分...

而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護,這樣讓 ISP 沒有任何資訊可以看到 hostname,把暴露的資訊再降低...

來繼續關注這個技術...

DNS over TLS 的 Privacy 改善

在上一篇提到 DNS over TLS 的「用 Stubby 在 Ubuntu 上跑 DNS over TLS」這篇,裡面 Gholk 留言提到:

可是 isp 還是可以從你接下來要去的 ip 知道你查了什麼吧?除非是 http proxy 多個域名一個 ip.

在「Does SNI represent a privacy concern for my website visitors?」這邊提到了 SNI 對隱私的問題,但他的想法剛好跟這個主題有關。

現代的瀏覽器架構使得使用者要在網路上保護自己很難 (這邊指的是隱私),但我們還是會利用各種方式加高 ISP 的難度,而這邊通常指的是成本:在 168.95.1.1168.95.192.1 上面記錄並且分析的成本,會比在所有的出口或是骨幹上面截聽封包的成本來的低很多,所以會走 DNS over TLS。

ALB 支援 SNI

AWS 宣佈 ALB 支援 SNI 了:「Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI」。

不過這篇比較有趣的是,他範例用的是 VimIsBetterThanEmacs.comVimIsTheBest.com 這兩個網域名稱 XDDD:

I’ll use a few example websites like VimIsBetterThanEmacs.com and VimIsTheBest.com. I’ve purchased and hosted these domains on Amazon Route 53, and provisioned two separate certificates for them in AWS Certificate Manager (ACM). If I want to securely serve both of these sites through a single ALB, I can quickly add both certificates in the console.

StackOverflow 預設全上 HTTPS 了...

HTTPS Everywhere 沒什麼感覺,但對於一般人應該不簡單,所以 Nick Craver (根本就是他們家非正式的 PR Engineer XDD 他這幾年寫了不少內部的資訊...) 寫了一篇關於上 HTTPS 的故事:「HTTPS on Stack Overflow: The End of a Long Road」。

其中他們為了支援舊設備 (沒有支援 SNI 的),決定直接把所有 wildcard 類的 SSL certificate 都包進去 (另外找 DigiCert 處理):

然後中間提到這個真的頗無奈的,抱怨 SVG 的 XML... XDDD:

Finding and killing these was a little fun because you can’t just search for "http://". Thank you so much W3C for gems like this:

<svg xmlns="http://www.w3.org/2000/svg"...

一條辛苦路 XD

Route53 的 Health Check 支援 HTTPS SNI 了...

Route53 的 Health Check 總算支援 SNI 了:「Amazon Route 53 Adds SNI Support for HTTPS Health Checks」。

With SNI and HTTPS support, you can now create health checks for secure websites that rely on SNI to serve the correct website and certificate to requests for a particular domain name.

這功能早該出現啦,等好久了...

HAProxy 1.6 的兩個大功能:Quote 以及 Lua

HAProxy 1.6.0 出版的公告文章:「[ANNOUNCE] HAProxy 1.6.0 released」。

兩個大功能,第一個是「It’s 2015, let’s use QUOTE in configuration file」,可以用引號了... 另外一個是「Lua Scripting」,需要 Lua 5.3+。

還有提到一些改進,像是支援 SNI,以及對 HTTP/2 的計畫。

為了解決 HiNet 到 CloudFlare 機房品質不好而做的掙扎...

前幾天在「TVBS 的 CloudFlare 客製化...」這邊提到這件事情,當天就先隨手測了一些東西。

首先是 CloudFlare 的服務 IP 是互通的,也就是說,我就算拿其他人的 CNAME mapping 來用,只要有送出對應的 Host: 或是 SNI (for HTTPS) 就會通,而 TVBS 當時的 IP address (以及網段) 對於台灣 HiNet 使用者剛好會導到美國機房,還算可以用。

另外 CloudFlare 有提供列表 (文字格式,一行一個網段),分別是 IPv4 的 https://www.cloudflare.com/ips-v4 以及 IPv6 的 https://www.cloudflare.com/ips-v6

所以就有幾種組合了,一種是寫 Google Chrome 的 extension 直接改 IP address,不過看了看 JavaScript APIs - Google Chrome 想不出來怎麼寫。

另外一個是先用 iptables 把這些網段的流量導去美國的 CloudFlare 機房。結果這時候發現 HiNet 到 TVBS 已經改回到香港機房了 orz

實際抓了一下發現 188.114.97.100 在巴西機房 (GRU 是 IATA 代碼),就變成只是測試看看這有沒有用了:

$ curl -x http://188.114.97.100:80/ http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004146.723
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

由於是自己機器出去的封包,不能用 PREROUTING 做,要用 OUTPUT 做:

iptables -t nat -A OUTPUT -d 190.93.240.0/20 -j DNAT --to-destination 188.114.97.100

然後再直接連到 s.plurk.com 就可以看到:

$ curl http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004011.195
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

不過巴西也太遠了點,而且不知道哪天這段 IP 又會被 anycast 進去... orz

CloudFront 支援 SNI,不需額外每個月 USD$600 的費用...

剛剛看到 Amazon CloudFront 支援 SNI,而且不像 Dedicated IP Custom SSL 需要每個月 USD$600 的費用:「New Features for Amazon CloudFront: Server Name Indication (SNI) and HTTP Redirection」。

目前最大的問題只剩下 Windows XP + IE8 不支援 SNI,台灣還有 19.86% 的人使用 IE8 (不知道 Windows XP + IE8 實際佔多少):


(出自 http://gs.statcounter.com/#browser_version-TW-monthly-201302-201402)

但至少行動裝置上的主力平台都支援了,如果大多數用戶是行動裝置,這個方式可以兼顧 custom SSL domain 與花費...

SNI 支援 (單一 IP 多個 SSL Certificate)

Twitter 上看到 yllan 提到 SSL certificate 的問題:

這是看 client 對 Server Name Indication 的支援程度而決定的。

在維基百科說明中「Browsers with support for TLS server name indication」這段裡面列出來的瀏覽器,可以看出來其實最大的問題就是 Windows XP 上的 IE{6,7,8} 不支援。(但 Windows Vista 以及 Windows 7 的 IE{7,8} 支援 SNI)

手上一時間找不到 Windows XP + IE{6,7,8} 的數量,但 gs.statcounter.com 上有幾個數字可以參考。

首先是台灣 IE8 的用戶數量:

再來是 Windows XP 數量:

以這兩個圖的資料來看,還是不太能用啊... :o

單一 IP/Port 多個 SSL Certificate:SNI

SNI 是「Server Name Indication」的縮寫,是 SSL Virtual Hosting 中很重要的一塊。

到目前為止,最主要是卡在 Windows XP 平台的 SSL/TLS 沒有支援,導致使用系統 SSL/TLS Library 的 IE6/7/8 都不支援 SNI。以 gs.statcounter.com 的數據「Top 5 Operating System from Jan 10 to Jan 11」來看,Windows XP 還有 48% 的市占率...

要等到 Windows XP 的市占率夠低後才有機會看到 SNI CDN...