Jerry Qu 寫的「关于启用 HTTPS 的一些经验分享」這篇文章講了要怎麼將 HTTP 站台逐步換成 HTTPS 站台的方式 (以及工具)。
一開始會遇到 Mixed Content，瀏覽器預設值不會直接全部擋掉，而是會放行圖片類資源 (但是出現對應的警告)。然後可以用 upgrade-insecure-requests 來幫助邊換，讓 url 裡指定 http 的自動連到 https。
當全站把 url 都修完後，接著就可以考慮用 HSTS 強制全上 HTTPS。
做到這邊的安全性已經到一定程度了，接下來要不要進 HSTS Preload List 就看大家自己的想法了。
Google 在「Indexing HTTPS pages by default」這邊宣佈了對 HTTPS 更進一步的支援。
只要是 HTTPS 與 HTTP 內容相同，而且沒有被阻擋 (透過 /robots.txt 之類的)，就會優先索引 HTTPS 版本的頁面。
另外也發現 blogspot.com 支援 HTTPS 了...
在 Akamai 網誌上的 PR 文章「The move to an Encrypted Web」提到使用 HTTPS 的好處，其中的「Improve data integrity」這點不僅僅是對使用者有好處，另外站在這兩年把 KKBOX 轉向 HTTPS 化時，使得被 ISP 干擾的問題消失。
早期 KKBOX 的服務都是走 HTTP (包括網站與 API)，三不五十就會遇到使用者抱怨登入會失敗，或是某些功能有問題。實際透過 TeamViewer 追蹤會發現 HTTP traffic 被 ISP 改掉了。
取自「Comcast Wi-Fi serving self-promotional ads via JavaScript injection」
從 2013 年買 CDN 服務時要求包含 HTTPS (圖片與 assets)，然後升級 load balancer 並且先設定 HTTP 與 HTTPS 都可以用，然後到 2015 年一路改寫 (包括 server 的支援與 client 的改寫)，到 2016 總算把大部份的服務 (API 與網站) 都搞定了。
這其實也歸功於目前其他大多數服務都已經上 HTTPS (包含了網站與 IM)，所以 port 80 + port 443 已經變成現代防火牆一定要打開的部份，不然很多服務會沒辦法使用。比起十年前有些單位會擋 port 443 已經好很多。
對 RD 來說，是個換過去就不會想要換回來的情況...
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 的負載。
nginx 在 1.9.5 後移除了對 SPDY 的支援，只支援 HTTP/2，剛剛找其他資料的時候在「HTTP/2 is here! Goodbye SPDY? Not quite yet」這邊發現 CloudFlare 的人有打算放 patch，讓 nginx 可以同時支援 HTTP/2 與 SPDY：
同時也可以看到有人抱怨 caniuse 上面的資料與實際使用的情況有蠻大的差距，拿 caniuse 來說服人不太準確。
另外也發現我自己的 blog 有時候 HTTP/2 不會啟用 (透過「HTTP/2 and SPDY indicator」觀察)，不知道是什麼原因，也許 nginx 的時候還是有 bug？
在找 Let's Encrypt 安裝方法時找到的專案：「letsencrypt/acme client implemented as a shell-script」。
整個專案用 bash 寫，用到的 dependency 都非常基本，「比較特別的」只有 curl 與 openssl，這兩個套件應該不是什麼問題... XD
沒有安裝問題 (因為只有一個 shell script 檔案)，用起來也很簡單，執行速度也比官方快多了 (畢竟官方的考慮比較多)，之後應該就會用這個吧... 另外自動化的部份也應該會用這個解決 :o
在 Twitter 上看到如標題所說的，從 Google Chrome 50 開始 (現在正式版本是 48)，HTTP 網頁將禁用 Geolocation API：
Starting in Chrome 50, geolocation will not be available in insecure contexts (i.e. only HTTPS embedded in HTTPS): https://t.co/2L6hlzkXnw
— Joel Weinberger (@metromoxie) January 21, 2016
對隱私保護的加強。
Firefox 46 的開發版本將會對非 HTTPS 頁面加上警示：「Login Forms over HTTPS, Please」。
技術上來說，是當偵測到頁面上有 input type="password" 的元素時會加上不安全的 icon：
When a page with a password field is not delivered securely, Firefox displays a lock with a red strikethrough in the address bar[.]
不過看起來是在試水溫，沒有打算在正式版本開起來：
There are no current plans to show these warnings to users of Beta and general release Firefox.
這樣就有點可惜了...
在 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.
這應該算還蠻基本常用到的東西，會改善很多程式效能...
在 Nuzzel 上看到老文章在討論 HTTPS 環境下因為安全性考量，而不能帶出 Referrer 的問題：「Where did all the HTTP referrers go?」。
原文中「Fixing Referrers in HTTPS: The Meta Referrer」這邊就有提到 HTML5 meta referrer，也就是 W3C 的「Referrer Policy」，問題是到現在還是 Draft 啊...
也因為過了三年，其實 draft 裡面多了不少參數可以用：
neverno-referrer 表示不傳。origin 表示只傳 protocol + host 的部份，後面 path 的部份不要傳。 defaultno-referrer-when-downgrade 表示當 downgrade 時 (HTTP request 的部份) 不要傳。origin-when-cross-origin 表示當跨站時用 origin 的邏輯，但本站還是用完整的路徑。alwaysunsafe-url 則是永遠都傳。其中刪節號表示 W3C 不建議再使用，應該用後者比較新的。
不過因為在 Can I use 上面可以看到 Microsoft Edge 只支援舊的關鍵字 (也就是刪節號的那些)，所以還是可以考慮先用舊的關鍵字，讓 Microsoft Edge 也可以被保護到：「Referrer Policy」。
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.
這功能早該出現啦，等好久了...
Google 在「Securing the web, together」這邊展現了對 HTTPS 化的努力。這是 Google 所有服務的 HTTPS 比率：
我以為 YouTube 上 HTTPS 後會有壓倒性的比率... 所以這應該不是 bytes 比率？
Netcraft 因為有一套系統在觀察整個 internet 的架構，有時後會整理出一些有趣的東西，像是這次整理出來的 HPKP，就找出很多設定上的錯誤：「HTTP Public Key Pinning: You’re doing it wrong!」。
抓了一下列出來哪些：
pin-sha256，包括寫成 pin-sha512 (RFC 不支援)、pin-sha1 (RFC 也是不支援)、pin-sha (RFC 還是不支援)、pin-sha245 (按歪了 XDDD)、ping-sha256 (XDDD)。"」)。Public-Key-Pins: TODO」也頗不賴 XDDDPublic-Key-Pins: This is like the most useless header I have ever seen. Preventing MITM, c'mon, whoever can't trust his own network shouldn't enter sensitive data anywhere.WordPress.com 宣佈將全面提供 HTTPS 服務：「HTTPS Everywhere: Encryption for All WordPress.com Sites」。
其中 wordpress.com 應該是買 wildcard SSL certificate 來做，而 custom domain 的部份將會透過 Let's Encrypt 來做：
The Let’s Encrypt project gave us an efficient and automated way to provide SSL certificates for a large number of domains. We launched the first batch of certificates in January 2016 and immediately started working with Let’s Encrypt to make the process smoother for our massive and growing list of domains.
這包括了對 SPDY + HTTP/2 的支援，使得 HTTPS 的速度不比 HTTP 差 (甚至更快)。
最近 CDN 產業裡有不少蕭期，其中一個新聞是 Google CDN 進入 beta，Google 藉由在全球佈署的機房來服務。
不過雖然進入了 Beta，但仍然有很嚴重的技術限制，只能透過 GCE 當 origin server，這使得實用性低很多：
Origins
Delivers HTTP/HTTPS content originating from Compute Engine VM instances. External origin servers are not supported.
有些特點是跟一般 CDN 不同的，一個是 Google 對 HTTPS 的口號，所以 HTTP 與 HTTPS 的價錢相同。其實你就當做他把 HTTP 的費用收的跟 HTTPS 一樣就好：
SSL Shouldn't Cost Extra
The web is moving to HTTPS, and your cacheable content should, too. With Cloud CDN, you can secure your content using SSL/TLS for no additional charge.
另外一個特點是從技術上就宣稱完全使用 Anycast，而不是見到的 DNS + Anycast：
Anycast
Serve all your content from a single IP address with low latency worldwide.
另外，計價的方式與其他的 CDN 有不少地方不一樣，另外也有針對中國地區另外處理。
首先是他把 Cache Egress (從 CDN 給使用者) 與 Cache Fill (從 CDN 到 Origin 取得資源) 分開收，一的般 CDN 都只收 Cache Egress 這塊。
再來是中國大陸地區的價錢另外標示，有特地標明不是從中國大陸地區直接提供服務：
Traffic destined for mainland China is served from Google locations outside of mainland China. Performance and reliability may be lower than for traffic served from in-country locations.
言下之意就是另外買 optimized 的頻寬來服務，但還是不會像在中國大陸地區有機房的效果這麼好，不過好處是不需要 ICP 之類的證照。
不過不得不說價錢其實還蠻便宜的，無論是歐美還是亞洲區。
Google 主動啟用了 HTTPS 版本：「Bringing HTTPS to all blogspot domain blogs」，預設會將 HTTPS 開起來：
As part of this launch, we're removing the HTTPS Availability setting. Even if you did not previously turn on this setting, your blogs will have an HTTPS version enabled.
另外提供 HTTPS Redirect 的選項，可以將訪客自動轉到 HTTPS 上：
custom domain 的部份不知道會怎麼提供...
CloudFlare 放出可以同時支援 HTTP/2 與 SPDY 的 nginx patch：「Open sourcing our NGINX HTTP/2 + SPDY code」。
不過 patch 的版本有點舊：
We've extracted our changes and they are available as a patch here. This patch should build cleanly against NGINX 1.9.7.
如同原文下面 comment 提到的問題，nginx 1.9.7 太舊了 (2015/11/17 放出的版本)，到現在有出了不少安全性更新，以及對 HTTP/2 的 bugfix。應該會需要再等官方把新版的 patch 拿出來改之後才能用。
Dropbox 將本來的 SPDY 切換到 HTTP/2 後整理了不少資料：「Enabling HTTP/2 for Dropbox web services: experiences and observations」。
大多數都是效能的改善，但「Increased latency for POST requests.」這段頗有趣的，找出了 nginx 的 bug：
POST 的 latency 大約增加了 50%，而實際追蹤問題發現是 nginx 中 SETTINGS_INITIAL_WINDOW_SIZE 預設值的問題，然後提出 patch 改善：「[nginx] HTTP/2: rewritten handling of request body.」：
There is a small issue with setting `SETTINGS_INITIAL_WINDOW_SIZE` to 0: now when client tries to POST data it needs to wait for an additional RTT(between `send HEADERS` and `recv WINDOW_UPDATE`) to start sending data.
GitHub 正式宣佈支援 HTTPS：「HTTPS for GitHub Pages」。
其實對使用者來說，前面的 CDN 伺服器已經支援 HTTPS 很久了，但因為之前從 CDN 到 GitHub 這端沒加密，所以一直都不算是正式支援：
You have been able to request Pages sites over HTTPS for some time, but we refrained from officially supporting it because the traffic from our CDN to our servers wasn't encrypted until now.
另外，新建立的 GitHub Pages 都強制上 HTTPS：
Starting next Wednesday (June 15, 2016, 12pm PDT), HTTPS enforcement will be required for all new GitHub Pages sites.
在「Migrate to Ubuntu 16.04」這邊看到換 16.04 的理由：
支援 http2 是升級到 Ubuntu 16.04 很大的動機。原因是前一版 14.04 裡 openssl 太舊，不支援 ALPN 協定，Chrome 瀏覽器又放棄了 NPN 的舊協定，詳細。你要嘛自己編譯 nginx ，要嘛就是升級到 16.04 才能解決。選哪個方法就看各公司的政策，升了 OS 問題就直接解決了。
不過 Ondřej Surý 包了一個有新版 openssl 的套件出來，所以在 12.04 或是 14.04 都可以使用 ALPN 版本的 nginx：「PPA for NGINX with HTTP/2 on Ubuntu 12.04 LTS and higher」。
目前 16.04 上的 Puppet 爛了不少東西，還是得靠 14.04 吃飯... orz
![[SweetSub&LoliHouse] 小书痴的下克上 领主的养女 / Honzuki no Gekokujou S04 - 05 [WebRip...](http://files.seeusercontent.com/2026/04/08/dRa8/Honzuki.jpg)
