Google Chrome 67 將可以在 DevTools 裡看到 SCT 的內容

April 18, 2018, 8:04 pm

≪ Previous: HTTPS Everywhere 改變更新 Ruleset 機制，變成定時更新...

在 Twitter 上看到 Google Chrome 67 (下一個版本) 的 DevTools 將會顯示憑證上的 Certificate Transparency 資訊：

In Chrome 67 the Security panel now provides certificate transparency info.https://t.co/JfV4IOrsmW pic.twitter.com/EbArEUv4MI

— Chrome DevTools (@ChromeDevTools) April 18, 2018

現在要看這個資訊比較麻煩，之後可以在瀏覽器裡直接讀就會簡單一些了...

話說回來，Let's Encrypt 上個月也支援 SCT 了：「Engineering deep dive: Encoding of SCTs in certificates」，不過目前只能先用 command line 工具看... 我拉了 Let's Encrypt 官方網站的 certificate 可以看到 (Let's Encrypt 那篇文章裡的範例)，但我自己 blog 的 certificate (序號 04ef0022ed7d5417f1ccbc011acf7fea9830) 看起來是在 Let's Encrypt 支援 SCT 之前申請的，沒看到 SCT 資訊... 要等下一次的 renew 了。

↧

廣告的 SDK 因為走 HTTP 傳輸而洩漏大量資料...

April 19, 2018, 1:52 am

≫ Next: GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

≪ Previous: Google Chrome 67 將可以在 DevTools 裡看到 SCT 的內容

廣告走 HTTP 而且還帶了一堆敏感資訊，算是最近討論蠻熱烈的問題：「Leaking ads」。

而且還分析找出有哪些是超大的廣告 unencrypted domain，像是這樣：

不過裡面一堆都不熟悉的廣告業者，反倒是聯想的網域被抓出來了：

不過行動裝置上能控制的東西太少了... 裝廣告阻擋程式比較實際，iOS 上不 JB 應該是只有 VPN 的方案，而 Android 上的方案應該就比較多了，除了 VPN 以外有 /etc/hosts 甚至是 firewall solution。

↧

GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

May 1, 2018, 11:28 pm

≫ Next: 用 GitHub + Netlify + Cloudflare 管理靜態網站...

≪ Previous: 廣告的 SDK 因為走 HTTP 傳輸而洩漏大量資料...

以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域，現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了：「Custom domains on GitHub Pages gain support for HTTPS」：

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準，也稱為 ANAME，有些 DNS provider 有支援，主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。

如果是使用 A record，則是需要更新 IP 位置：

If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.

另外也提供 HTTP 轉 HTTPS 的選項：

以前 HTTPS 還得自己弄伺服器處理，現在可以直接往 GitHub 上丟了...

另外用查出來的 IP 看了一下架構，IP 是 Fastly 的，所以應該是跟 Fastly 合作，但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證，或是 Fastly 提供 Port 80/443 的 TCP Proxy？

↧

用 GitHub + Netlify + Cloudflare 管理靜態網站...

May 6, 2018, 2:10 pm

≫ Next: 把本來 dehydrated 的 PPA 改成 dehydrated-lite

≪ Previous: GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

最近 GitHub Pages 支援 HTTPS (透過 Let's Encrypt，參考「GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務」這篇)，但測了一下不是我想要的效果，就找了一下網路上的資源，結果有找到還算可以的方案...

先把網站放在 GitHub 上。(不需要設定 GitHub Pages)
然後用 Netlify 變成網站並且開啟 HTTPS。(可以選擇使用系統內提供的 Let's Encrypt，會透過 http-01 認證。如果因為 DNS 還沒生效的話也沒關係，可以之後再開。)
然後用 Cloudflare 管理 DNS 的部份 (主要是因為他的 root domain 可以設 CNAME，一般會提到的 ALIAS 就是指這個)。

這樣整個靜態服務都不用自己管理，而且有蠻多 header 可以設定，其中與 GitHub Pages 最主要的差異是 Netlify 支援 301/302 redirect。而關於 Netlify 的設定範例 (簡單的)，可以參考我在 GitHub 上的 git.tw repository。

然後 Netlify 上可以自己設定 header，當設定 HSTS 之後，SSL Labs 的跑分也可以到 A+。

整包目前看起來唯一的限制是 Netlify 的 125k requests/month (平均下來大約 4k requests/day)，不過只拿來做 redirect 應該還好...

PS：如果有人要推薦其他的組合也歡迎...

↧

把本來 dehydrated 的 PPA 改成 dehydrated-lite

May 9, 2018, 12:38 pm

≫ Next: nginx 推出了 1.14.0 的 PPA

≪ Previous: 用 GitHub + Netlify + Cloudflare 管理靜態網站...

本來有做 dehydrated 的 PPA (在「PPA for dehydrated : Gea-Suan Lin」這邊)，後來在 17.10+ 就有更專業的人包進去了 (參考「Ubuntu – Package Search Results -- dehydrated」)，為了避免名稱相同但是內容物差很多，我把 PPA 的名字換成 dehydrated-lite 了 (參考「PPA for dehydrated (lite) : Gea-Suan Lin」)。

然後 0.6.2 的 dehydrated 針對 ACMEv2 有修正，這在 0.6.1 時會產生 certificate 裡有多餘資訊 (而 PPA 版的 gslin/dehydrated 只會停留在 0.6.1)，這點需要注意一下：

Don't walk certificate chain for ACMEv2 (certificate contains chain by default)

之後再找機會拔掉 gslin/dehydrated，也許會照著現在 APT 內的架構來做...

↧

nginx 推出了 1.14.0 的 PPA

May 12, 2018, 4:01 pm

≫ Next: Cloudflare 提供的 DNS Resolver 服務拓展到 Tor 上

≪ Previous: 把本來 dehydrated 的 PPA 改成 dehydrated-lite

nginx 的 PPA (「NGINX Stable : “Nginx” team」這個) 推出了 1.14.0 的版本。

這個版本使用了 OpenSSL 1.1.0，對 cipher 這塊最大的差異主要是包括了 CHACHA20 與 AESCCM 演算法。後者的 CCM 指的是 CCM mode，這是當時 OCB mode 因為專利問題而發展出來的演算法，就目前的效能測試沒有 GCM 好，而且普及率也沒有 GCM 高，放進來應該是當備案 (當 GCM 有狀況時標準裡至少有方案可以選)：

The catalyst for the development of CCM mode was the submission of OCB mode for inclusion in the IEEE 802.11i standard. Opposition was voiced to the inclusion of OCB mode because of a pending patent application on the algorithm. Inclusion of a patented algorithm meant significant licensing complications for implementors of the standard.

真正的重點在於 CHACHA20 的引入，讓 OpenSSL 重新有主流 stream cipher 可以使用了... 上一個主流 stream cipher RC4 被打趴好久了。

不過 TLSv1.3 要等 OpenSSL 1.1.1 才有 (參考「Using TLS1.3 With OpenSSL」這邊的說明)，目前可以在設定檔裡面設 TLSv1.3 而不會出現錯誤訊息，但暫時還不會有效果...

↧

Cloudflare 提供的 DNS Resolver 服務拓展到 Tor 上

June 5, 2018, 5:06 pm

≫ Next: 用 Stubby 在 Ubuntu 上跑 DNS over TLS

≪ Previous: nginx 推出了 1.14.0 的 PPA

Cloudflare 宣佈 DNS Resolver 提供 Tor 的版本，讓使用者可以在不暴露自己的 IP address 的情況下，使用 Cloudflare 提供的 DNS Resolver 服務：「Introducing DNS Resolver for Tor」。

不過沒看懂，如果使用者想要透過 Tor 保護自己的話，本來就可以透過 Tor 存取 1.1.1.1 與 1.0.0.1 甚至是其他家有提供 DNS-over-TLS 或是 DNS-over-HTTPS 的服務了？(像是 Google 的 8.8.8.8)

好像找不到什麼使用的理由...

↧

用 Stubby 在 Ubuntu 上跑 DNS over TLS

June 24, 2018, 6:21 pm

≫ Next: 提供 Cheatsheet 的服務：cheat.sh

≪ Previous: Cloudflare 提供的 DNS Resolver 服務拓展到 Tor 上

透過 DNS over TLS 會損失一些效能 (我用 VDSL 的光世代測試，大約是從 10ms 變成 40ms)，但可以讓 ISP 看不到你查詢什麼，對於隱私有很大的幫助... 而先前是一直在看 Ubuntu 上的 Unbound 什麼時候會有 1.8.0+ 的版本可以用 (支援 DNS-over-TLS)，但一直沒看到，結果在「How to Protect Your DNS Privacy on Ubuntu 18.04 with DNS over TLS」這邊看到 Stubby 這個軟體。

Stubby 在 Ubuntu 18.04 上可以直接裝，但在 Ubuntu 16.04 上需要透過 PPA 裝，我是透過「DNS Utils : James Newell」這個安裝的，裝好後 /etc/stubby/stubby.yml 檔裡 upstream_recursive_servers 的設定改成：

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

就可以走 port 853 的 DNS over TLS 了，而 Stubby 預設會聽 127.0.0.1 與 ::1 的 port 53，所以把 /etc/resolv.conf 或是 NetworkManager 的設定改成 127.0.0.1 就可以了。

目前這樣設看起來沒辦法擋 MITM attack (偽造 SSL certificate)，Stubby 看起來只能用 tls_pubkey_pinset 鎖住，但實在不愛這個方法 (因為 Cloudflare 有可能會換成其他的 SSL certificate)，之後看看有沒有可以吃 Root CA 架構的認證再來調整...

↧

提供 Cheatsheet 的服務：cheat.sh

July 12, 2018, 1:29 pm

≫ Next: Google Chrome 68，第一個將所有 HTTP 站台都標成 Insecure 的版本

≪ Previous: 用 Stubby 在 Ubuntu 上跑 DNS over TLS

看到「chubin/cheat.sh」這個服務：

the only cheat sheet you need

他提供了 HTTP(S) 介面讓你存取 (透過 curl 或是其他的軟體)，像是這樣的操作：

而且提供了 shell script 讓你可以更方便在 command line 下使用：

curl https://cht.sh/:cht.sh > ~/bin/cht.sh
chmod +x ~/bin/cht.sh

你可以把 cht.sh 換成其他你喜歡的名字，或是用 alias 方便操作...

↧

Google Chrome 68，第一個將所有 HTTP 站台都標成 Insecure 的版本

July 24, 2018, 7:01 pm

≫ Next: Let's Encrypt 被所有主流瀏覽器直接支援了...

≪ Previous: 提供 Cheatsheet 的服務：cheat.sh

Google 在 stable channel 發布了 Google Chrome 68，這是 Chrome 第一個將所有 HTTP 站台都標成 insecure 的版本：「Stable Channel Update for Desktop」。取自二月時的圖：

文章內也說明了這個改變：

In Chrome 68, Chrome will show the “Not secure” warning on all HTTP pages. We announced this in a blog post published on February 8th on Google’s Chromium and Online Security blogs.

雖然之前 Google 一直在推動，但應該還是很多單位沒在管...

↧

Let's Encrypt 被所有主流瀏覽器直接支援了...

August 7, 2018, 1:20 am

≫ Next: RFC 8446：TLS 1.3

≪ Previous: Google Chrome 68，第一個將所有 HTTP 站台都標成 Insecure 的版本

Let's Encrypt 宣佈他們的憑證被所有主流瀏覽器直接支援了，也就是都在各平台的 trusted store 內了：「Let's Encrypt Root Trusted By All Major Root Programs」，看起來這次加入的是 Microsoft 的產品：

As of the end of July 2018, the Let’s Encrypt root, ISRG Root X1, is directly trusted by Microsoft products. Our root is now trusted by all major root programs, including Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry.

先前是靠 IdenTrust 的 cross signing 讓各瀏覽器信任，在「Chain of Trust」這邊有圖說明：

另外查了一下 cross signing 的資訊，以 Let's Encrypt Authority X3 這張的 cross signing 可以看到 cross sign 簽了五年，到 2021 年：(憑證可以從 letsencryptauthorityx3.pem.txt 這邊取得，用 openssl x509 -in letsencryptauthorityx3.pem.txt -text 看到)

    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Validity
            Not Before: Oct  6 15:43:55 2016 GMT
            Not After : Oct  6 15:43:55 2021 GMT
        Subject: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

這樣約滿不知道會不會續簽...

↧

RFC 8446：TLS 1.3

August 12, 2018, 10:38 am

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

≪ Previous: Let's Encrypt 被所有主流瀏覽器直接支援了...

看到 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」，這也熬了一年啊... 支援後會就有很多軟體可以直接套用了，可以來期待了。

↧

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

August 13, 2018, 11:08 pm

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

≪ Previous: RFC 8446：TLS 1.3

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

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

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

PChome，像是 24h.pchome.com.tw，憑證會在 2018/09/22 到期。
麥當勞，像是 www.mcdonalds.com.tw，憑證會在 2018/09/09 到期。

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

↧

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

August 14, 2018, 10:07 am

≫ Next: Google Chrome 70 在測試移除 EV SSL 的名稱標籤...

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

因為前一篇「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

↧

Google Chrome 70 在測試移除 EV SSL 的名稱標籤...

August 29, 2018, 3:32 pm

≫ Next: curl 將支援 DNS over HTTPS

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

Twitter 上看到的：

I see Chrome Canary v70 is trialing the removal of EV-SSL company names, wonder if that will make it into the final release? @troyhunt pic.twitter.com/u8KkDZHPGm

— Si (@west_mill) August 29, 2018

不知道是什麼背景決定做這個實驗... 盯一下這個消息的後續發展 @_@

↧

curl 將支援 DNS over HTTPS

September 7, 2018, 6:42 am

≫ Next: OpenSSL 1.1.1 出版，TLSv1.3！

≪ Previous: Google Chrome 70 在測試移除 EV SSL 的名稱標籤...

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);

↧