Cloudflare 同時支援 TLS 1.2 與 TLS 1.3 的過程

Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft,但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響,所以就找了方法讓兩者並存:「Know your SCM_RIGHTS」。

這個方法就是 SCM_RIGHTS,可以讓另外一個 process 存取自己的 file description。

You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.

所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料,如果裡面有看到想要使用 TLS 1.3 的訊息,就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑:

We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.

這樣本來的 stack 就只要修改一小段程式碼,將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑,就比較不用擔心本來的 stack 會有狀況了。

HTTP-over-QUIC 將變成 HTTP/3

cURL 作者那邊看到的,之前 HTTP-over-QUIC 的名稱實在太長,想要找個短一點的名字來用,這邊算是把命字確定下來了:「HTTP/3」。從文章後的說明就可以看出來:

No more confusion. HTTP/3 is the coming new HTTP version that uses QUIC for transport!

不過這代表 HTTP/3 需要 443/udp 了,之後防火牆預設應該要打開...

Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

UpdateApple 也宣佈了,時間點跟大家都差不多:「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。

Mozilla 宣佈了「Removing Old Versions of TLS」,而 Google 也宣佈了「Modernizing Transport Security」,兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。

Mozilla 這邊的計畫是 2020 年三月移除:

In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.

Google 這邊的計畫則是 Chrome 81 移除,換算成時間會從 2020 年一月開始影響到 canary channel,到 release channel 應該跟 Firefox 差不多時間:

In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.

差不多試從現在開始的一年半。

雖然這是講瀏覽器端的支援,但如果伺服器想要只支援 TLS 1.2+ 的話,就得考慮一下舊 client 支援的情況了。

桌機影響會比較小 (升級比較方便,替代方案也比較多),而行動平台看起來需要 Android 4.4+、iOS 7+,就要看各網站或是服務的族群了...

SMTP 的強加密連線機制

RFC 8461 成為正式標準 (Standards Track),描述 Mail server 到 mail server 之間的強加密連線機制:「SMTP MTA Strict Transport Security (MTA-STS)」。

Policy 設定的方法有好幾種:

第一種是透過 _mta-stsTXT record 設定,這點通常會配合 DNSSEC 確保 DNS 的查詢沒有被改。

第二種是透過 HTTPS 在某個特定的 host (mta-sts) 取得 policy 檔案。像是對 example.com 的資料會從 https://mta-sts.example.com/.well-known/mta-sts.txt 取得。

第三種是透過 HTTPS 的 certificate 裡面帶 mta-sts 資訊出來。

不只有 DNS 可以設定,使得整個架構變得有點複雜...

Transport-Layer Encryption 與 End-to-End Encryption 的差異

EFF 的「Transport-Layer Encryption vs End-to-End Encryption - GIF」這篇文章介紹了 Transport-Layer Encryption 與 End-to-End Encryption 的差異,最後還給了一張 GIF 說明:

其實 GIF 給的範例還蠻清楚的,在 Transport-Layer Encryption 中服務提供商可以看到原始內容 (以 GIF 內提到的例子就是 Google),而在 End-to-End Encryption 中就不行,只有傳輸雙方可以知道原始內容。

然後文章裡也提到了 Tor Messenger,可以吃現有的通訊軟體,然後在上面疊出 End-to-End Encryption。

Uber 在倫敦將會被停業

Uber 在倫敦將會被停業:「Uber has license to operate in London revoked」、「London regulator announces Uber ban」、「Uber London loses licence to operate」。

更精確的說是不再續發 license,舊的 license 只到 9/30:

Transport for London (TfL), which operates public transport in the capital, has made the decision not to renew the app-based taxi’s license in the city.

The license was renewed in May, but for a period of only five months. It will run out on 30th September, though the company will be allowed to continue to operate during the appeal process.

看起來主要原因是圍繞於 Greyball (利用演算法躲避執法人員的工具):

According to the TfL regulatory board, the ‘approach and conduct’ of Uber showed a lack of corporate responsibility, which could have resulted in public safety and security issues. It also raised concerns with the company’s ‘approach to explaining the use of Greyball, software that could be used to block regulatory bodies from gaining full access to the app.’

新任 CEO 則是出來道歉:「Uber CEO apologizes for “mistakes” in London」。

其實是利益團體之間的衝突... 這戲還在繼續演。

Gmail 要開始導入 SMTP Strict Transport Security 了

SMTP MTA Strict Transport Security 算是 SMTP STARTTLS 裡的 HSTS 機制,而 Google 的人在 RSA Conference 上提出要開始用了:「SMTP STS Coming Soon to Gmail, Other Webmail Providers」。

Elie Bursztein, the head of Google’s anti-abuse research team, said at RSA Conference that SMTP STS will be a major impediment to man-in-the-middle attacks that rely on rogue certificates that are likely forged, stolen or otherwise untrusted. Google, Microsoft, Yahoo and Comcast are expected to adopt the standard this year, a draft of which was submitted to the IETF in March 2016.

補上去後對於 SMTP 的隱私保護就會更好了...

貨運公司每次都把腳踏車弄壞...

在「Our secret’s out.」這邊看到 VanMoof (腳踏車生意) 對於托運公司每次都把腳踏車給弄壞的解決方法 XDDD

因為包裝很像平板螢幕,就掛個平板螢幕的圖片上去,然後運送的損壞率就下降 70%~80%:

Earlier this year our co-founder Ties had a flash of genius. Our boxes are about the same size as a (really really reaaaally massive) flatscreen television. Flatscreen televisions always arrive in perfect condition. What if we just printed a flatscreen television on the side of our boxes?

And just like that, shipping damage to our bikes dropped by 70–80%.

然後文末偷偷爆破了是哪家負責運送 XDDD

We were hoping to keep this small tweak quiet, but thanks to Twitter, the secret’s out.

Just don’t tell FedEx.

Stripe 所提到的 TLS 1.1 不安全

Stripe 在宣佈要淘汰 TLS 1.0 與 TLS 1.1 的計畫公告中 (「Upgrading to SHA-2 and TLS 1.2」) 提到了:

Why SHA-1, TLS 1.0 and 1.1 are insecure

但在文章裡面還是沒有提到為什麼 TLS 1.1 不安全。

在維基百科的「Transport Layer Security」條目中試著找內容,發現應該是 Data integrity 這段,TLS 1.1 不支援 HMAC-SHA256/384 與 AEAD,只支援比較弱的 HMAC-MD5 或是 HMAC-SHA1。

利用 HSTS 資訊得知網站紀錄的 sniffly

看到「sniffly」這個工具,可以利用 HSTS 資訊檢測逛過哪些網站,程式碼在「diracdeltas/sniffly」這邊可以找到:

Sniffly is an attack that abuses HTTP Strict Transport Security and Content Security Policy to allow arbitrary websites to sniff a user's browsing history. It has been tested in Firefox and Chrome.

測試網站則可以在這邊看到,作者拿 Alexa 上的資料網站來掃,所以熱門網站應該都會被放進去...

主要是利用 HSTS + CSP policy 的 timing attack (有逛過網站而瀏覽器裡有 HSTS 時的 redirect 會比較快,沒有逛過的時候會因為有網路連線而比較慢):

Sniffly sets a CSP policy that restricts images to HTTP, so image sources are blocked before they are redirected to HTTPS. This is crucial! If the browser completes a request to the HTTPS site, then it will receive the HSTS pin, and the attack will no longer work when the user visits Sniffly.

When an image gets blocked by CSP, its onerror handler is called. In this case, the onerror handler does some fancy tricks to time how long it took for the image to be redirected from HTTP to HTTPS. If this time is on the order of a millisecond, it was an HSTS redirect (no network request was made), which means the user has visited the image's domain before. If it's on the order of 100 milliseconds, then a network request probably occurred, meaning that the user hasn't visited the image's domain.

由於這個技巧,HTTPS Everywhere 必須關閉才會比較準確。