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 可以設定,使得整個架構變得有點複雜...

Cloudflare 決定支援 QUIC

Cloudflare 決定支援 QUIC 了:「Get a head start with QUIC」、「The QUICening」。

QUIC 目前被使用的範圍比較小 (相較於 HTTP/2):

  • 主流瀏覽器內只有 Google Chrome 有支援 QUIC,其他主流瀏覽器都沒有支援。不過 Google Chrome 也夠大了...
  • 因為是走 UDP,所以防火牆要另外開。

而 Google Chrome 上面可以安裝「HTTP/2 and SPDY indicator」看到連線的狀態。雖然套件名稱沒有 QUIC,但實際上是可以看出 QUIC 的,基本上 Google 的服務應該都是走 QUIC。

curl 將支援 DNS over HTTPS

curl 的維護者 Daniel Stenberg 在他的 blog 上宣佈 curl 將會支援 DNS over HTTPS:「DoH in curl」。

從給的範例可以看出來就是多一個 CURLOPT_DOH_URL 可以設,對於要用的人很簡單:

curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL,
                 "https://curl.haxx.se/");
curl_easy_setopt(curl, CURLOPT_DOH_URL,
                 "https://doh.example.com/");
res = curl_easy_perform(curl);

最近討論頗多的 NordVPN

最近 NordVPN 的隱私問題被拿出來討論的蠻凶的,應該是從「Is NordVPN a Honeypot?」這篇開始的...

作者一開始就有提到並不只有 NordVPN,而是整個 VPN 產業其實都有類似的情況,只是現在可以找到比較多證據可以推測 NordVPN 後面並不單純。

首先是 NordVPN 買了大量評論,後來被發現是假的而被移除,而移除後的分數掉了非常多。再來是 NordVPN 居然花了五十萬美金在 CNN 的廣告上,這對於 VPN 產業的成本來說很不可思議...

另外一個是 NordVPN 的母公司 Tesonet 就是做 data mining 的,「整理」各種資料拿出來賣的...

基本上這類服務只能拿來翻牆用 (翻進日本或是翻進美國),不要認為隱私性有多高... 需要隱私還是得透過其他方式降低風險 (沒辦法完全保護,只能降低)。

蘋果以隱私為由,下掉 Facebook 在 App Store 上的 Onavo App

Onavo 是個提供 VPN 服務的公司,跟一般的 VPN 服務一樣,以隱私為主打,後來在 2013 年被 Facebook 買下,但在今年三月的時候就有媒體有報導 Facebook 打算蒐集 Onavo 上的資料:「Facebook-owned Onavo quietly launches Bolt App Lock, a data-tracking app that locks other apps」,當時 Facebook 不怎麼鳥各家媒體的看法,就放著...

不過直到八月的時候才被 Apple 下架:「Apple removed Facebook’s Onavo from the App Store for gathering app data」,引用 Apple 發言人給 TechCrunch 的句子:

We work hard to protect user privacy and data security throughout the Apple ecosystem. With the latest update to our guidelines, we made it explicitly clear that apps should not collect information about which other apps are installed on a user’s device for the purposes of analytics or advertising/marketing and must make it clear what user data will be collected and how it will be used.

看起來是直接改遊戲規則後強迫下架...

國內使用 Let's Encrypt 的商業網站...

因為前一篇「Symantec 系列的 SSL Certificate 陸續開始失效...」的關係,當時是針對 針對 .tw 結尾的站台,用 OpenSSL 掃了一份 issuer= 下來,剛好可以拿來翻一下有誰換去 Let's Encrypt 了...

蝦皮的主站台直接都用 Let's Encrypt 了:

host=shopee.tw  issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
host=www.shopee.tw      issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

然後在「SSL Server Test: shopee.tw (Powered by Qualys SSL Labs)」這邊可以看到是 wildcard,而且是多個 wildcard 合併一張...

如果把 Let's Encrypt 自動化,省下來最多的通常都不是憑證費用,而是 renew 時請款流程的人力成本與忘記 renew 時的出包成本... XD

Symantec 系列的 SSL Certificate 陸續開始失效...

先前就有提到 ChromeFirefox 因為 Symantec 的信任問題太大,都有打算終止信任 Symantec 的憑證了,而其他瀏覽器也都有陸陸續續公佈了類似的計畫,大家的時間表都抓差得不多...

最近接近當時各家瀏覽器規劃的終止信任日,而在使用開發版本的 Chrome 與 Firefox 開始連不上一些網站了。我自己是走 beta channel 所以還沒中,不過好像也快了...

我拿了「Umbrella Popularity List」這邊提供的前一百萬網站測,以 .tw 結尾的網站看起來就只剩下兩個還沒換了:

在蘋果的網站上有清單可以翻:「Information for website operators about distrusting Symantec certificate authorities」。

RFC 8446:TLS 1.3

看到 RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3) 正式推出了,也就是 TLS 1.3 正式成為 IETF 的標準 (Standards Track)。

Cloudflare 寫了一篇文章「A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)」描述了 TLS 1.3 的特點,有興趣的人可以看一看,尤其是 1-RTT 的部份對效能幫助很大 (0-RTT 因為 replay attack 問題,我應該暫時都不會考慮,要等到有一個合理的防禦模型出來)。

另外一個是 OpenSSL 目前最新版是 1.1.0h,當初就決定要等 TLS 1.3 正式成為標準才會出 1.1.1 (參考「OpenSSL 1.1.1 將支援 TLS 1.3」,這也熬了一年啊... 支援後會就有很多軟體可以直接套用了,可以來期待了。