幹壞事是進步最大的原動力
Let's Encrypt 的人試著從多個資料來源分析 Let's Encrypt 對整個網路上安全性的影響力：「Early Impacts of Let's Encrypt」。
資料來源包括 Certificate Transparency (CT) 記錄與 censys (這個網站用 StartSSL，被我屏蔽掉了 XD)。
But I do have access to Certificate Transparency logs, as well as other data sources like Censys.io.
前者 CT 的部份會有嚴重的偏差，因為 CA/Browser Forum 只規定 EV certificate 要送 CT log，一般的 SSL certificate 可以不送 (幾乎都沒送)，而 Let's Encrypt 發的是一般的 SSL certificate，還是有送 CT log。
把資料送上 CT 是好事，但這使得 CT log 內的資料會有嚴重偏差，拿這個判斷影響力是很有問題的。
所以這份資料就是看看就好...
在 Go 的官方公告「Go 1.6 is released」提到了把 net/http 的 HTTP/2 預設啟用了：
In Go 1.6, support for HTTP/2 is enabled by default for both servers and clients when using HTTPS, bringing the benefits of the new protocol to a wide range of Go projects, such as the popular Caddy web server.
另外值得一提的是 sort 演算法的效能改善：
The algorithm inside sort.Sort was improved to run about 10% faster, but the change may break programs that expect a specific ordering of equal but distinguishable elements.
這應該算還蠻基本常用到的東西，會改善很多程式效能...
Gmail 界面將會提示不支援 STARTTLS 的信箱：「Making email safer for you」。
先確認 msa.hinet.net 的 MX record：
;; ANSWER SECTION: msa.hinet.net. 86174 IN MX 0 msa-smtp-mx1.hinet.net. msa.hinet.net. 86174 IN MX 0 msa-smtp-mx2.hinet.net.
以及不支援 STARTTLS (在 EHLO 後不會出現 STARTTLS 選項)：
$ t msa-smtp-mx1.hinet.net 25 Trying 168.95.6.53... Connected to msa-smtp-mx1.hinet.net. Escape character is '^]'. 220 msa.hinet.net ESMTP Sendmail 8.14.2/8.14.2; Thu, 11 Feb 2016 04:52:16 +0800 (CST) EHLO localhost 250-msa.hinet.net Hello 114-32-152-63.HINET-IP.hinet.net [114.32.152.63], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-DELIVERBY 250 HELP QUIT 221 2.0.0 msa.hinet.net closing connection Connection closed by foreign host.
打開 Gmail 在收件人的地方輸入 test@msa.hinet.net 後，就會跳出紅色鎖頭表示不支援 STARTTLS。
AWS 推出免費的 SSL Certificate 服務 AWS Certificate Manager：「New – AWS Certificate Manager – Deploy SSL/TLS-Based Apps on AWS」。
目前宣佈只有在 us-east-1 可以用，不過實際測試會發現包括 CloudFront。
AWS Certificate Manager (ACM) is available now in the US East (Northern Virginia) region, with additional regions in the works. You can provision, deploy, and renew certificates at no charge.
可以看到是 Amazon 是找 Starfield 搞定的：
$ openssl s_client -servername i.kfs.io -connect d2c884gdd5bajy.cloudfront.net:443 CONNECTED(00000003) depth=4 C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority verify return:1 depth=3 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2 verify return:1 depth=2 C = US, O = Amazon, CN = Amazon Root CA 1 verify return:1 depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon verify return:1 depth=0 CN = *.kfs.io verify return:1
使用的是傳統的 e-mail 認證：
連買憑證的成本都可以省下來了，而且比起以前要自己用 aws-cli 在 command line 裡上傳 key & certificate 來的簡單多了。
在找 Let's Encrypt 安裝方法時找到的專案：「letsencrypt/acme client implemented as a shell-script」。
整個專案用 bash 寫，用到的 dependency 都非常基本，「比較特別的」只有 curl 與 openssl，這兩個套件應該不是什麼問題... XD
沒有安裝問題 (因為只有一個 shell script 檔案)，用起來也很簡單，執行速度也比官方快多了 (畢竟官方的考慮比較多)，之後應該就會用這個吧... 另外自動化的部份也應該會用這個解決 :o
CloudFront 宣佈支援對 Origin 使用 TLS v1.1 與 v1.2 了：「CloudFront Update – HTTPS & TLS v1.1/v1.2 to the Origin, Add/Modify Headers」。
另外一個重要的功能是，強制使用 HTTPS 往 Origin 存取，即使使用者對 CloudFront 使用 HTTP，往後也還是會用 HTTPS，確保資料不會被中間的 ISP 改掉。
再來比較期待的功能是有沒有類似 Akamai 的 TD (Tiered Distribution) 或是 EdgeCast 的 Super PoP，也就是全球的 Edge 都透過這組 Server 再跟 Origin 要資料。這樣可以大幅度提高 hitrate，並且降低對 Origin 的負載。
Jerry Qu 寫的「关于启用 HTTPS 的一些经验分享」這篇文章講了要怎麼將 HTTP 站台逐步換成 HTTPS 站台的方式 (以及工具)。
一開始會遇到 Mixed Content，瀏覽器預設值不會直接全部擋掉，而是會放行圖片類資源 (但是出現對應的警告)。然後可以用 upgrade-insecure-requests 來幫助邊換，讓 url 裡指定 http 的自動連到 https。
當全站把 url 都修完後，接著就可以考慮用 HSTS 強制全上 HTTPS。
做到這邊的安全性已經到一定程度了，接下來要不要進 HSTS Preload List 就看大家自己的想法了。
Let's Encrypt 進入 Public Beta，這代表不再需要提出申請才能用了：「Entering Public Beta」。
We’re happy to announce that Let’s Encrypt has entered Public Beta. Invitations are no longer needed in order to get free certificates from Let’s Encrypt.
話說翻資料的時候翻到 Namecheap 對 Let's Encrypt 作出反擊，只能說吃樣很難看：「SSL from Namecheap - What's the difference: Encryption, Validation & Trust」。
人們選擇 Namecheap 的 SSL certificate 不是因為他好，而是因為他便宜，加上這家公司不像 GoDaddy 那樣邪惡。
現在有免費的 SSL certificate 出來競爭 (於是根本打不贏) 就放 FUD 攻擊，吃相極為難看。有人針對 Namecheap 的文章駁斥了裡面大量錯誤的論點：「Comment on Namecheap's SSL」。
接下來應該可以弄不少來玩，來整理文章把申請與自動 renew 的步驟做出來...
CloudFlare 推出了 HTTP/2 服務，與其他 CDN 業者不一樣的地方在於，他可以同時接受 HTTP/2 與 SPDY：「HTTP/2 is here! Goodbye SPDY? Not quite yet」。
CloudFlare 拿自家的 www.cloudflare.com 官網測試，顯示 HTTP/2 的效能比 SPDY 又好了不少：
| Access via HTTP Protocol Version | Average Page Load time |
|---|---|
| HTTP 1.x | 9.07 sec. |
| SPDY/3.1 | 7.06 sec. |
| HTTP/2 | 4.27 sec. |
在正式上 HTTP/2 前，有 80.38% 對 www.cloudflare.com 的 SSL/TLS 連線是 SPDY：
During the week before our HTTP/2 launch, 80.38% of all SSL/TLS connections to our own website at www.cloudflare.com were made over SPDY/3.1.
上線後其實沒有想像中的高：
| Protocol Version | Percentage of Hits |
|---|---|
| HTTP 1.x | 19.36% |
| SPDY/3.1 | 57.02% |
| HTTP/2 | 23.62% |
這也說明了為什麼 CloudFlare 要推出 SPDY + HTTP/2 的服務：
Why choose, if you can have both? Today CloudFlare is introducing HTTP/2 support for all customers using SSL/TLS connections, while still supporting SPDY. There is no need to make a decision between SPDY or HTTP/2. Both are automatically there for you and your customers.
剛剛連到後台確認，由於本來已經打開 SPDY 的使用者會自動開啟 HTTP/2，這表示全球 HTTP/2 的使用率會馬上拉高很多，有太多資源掛在 CloudFlare 上：(像是 cdnjs.com，剛剛確認也已經是 HTTP/2 了)
If you are a customer on the Free or Pro plan, there is no need to do anything at all. Both SPDY and HTTP/2 are already enabled for you.
Customers on Business and Enterprise plans can enable HTTP/2 within the "Network" application of the CloudFlare Dashboard.
在「Hostnames and usernames to reserve」這邊提到公開服務時的保留名稱問題。
首先是提到 hostname 的部分，被各協定使用到的都散落在各標準裡，另外就是利用前幾天提到的「Mozilla 維護的 Public Suffix List」加減擋 cookie...
比較感興趣的是 email 的部分的標準，這邊主要在討論 SSL certificate 的註冊。在「Baseline_Requirements_V1_3_1」的 3.2.2.4. Authorization by Domain Name Registrant 的第四項提到：
Communicating with the Domain’s administrator using an email address created by pre‐pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at‐sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
也就是指出只能用上面提到的這幾個 mail address 來認證。不過為了安全起見，RFC 2412 定義的也應該擋下來。這兩組標準列出來的 username 都算是合理，沒什麼問題。
最後則是討論 path part，這點倒是有不少地雷可以看看，尤其是最新的 ACME 產生的問題 XDDD