SPDY 對行動裝置還是很重要，尤其是 Android 裝置在 5.0 之後才有支援 HTTP/2，但在 3.0 之後就有支援 SPDY，也就是超過一半的 Android 用戶只有 SPDY 但沒有 HTTP/2 能力：
查資料的時候發現當初 CloudFlare 提供的 SPDY + HTTP/2 patch 本來只能對 nginx 1.9.7 更新 (參考之前寫的「CloudFlare 放出可以同時支援 HTTP/2 與 SPDY 的 nginx patch」)，後來有人再更新到 1.9.15，而在留言的地方也可以看到有人回報在 1.11.0 上面可以跑：「Update NGINX SPDY patch for 1.9.15」：
Works fine against nginx 1.11.0 and OpenSSL 1.0.2h (with ChaCha20 patch). I am building nginx as an Ubuntu 16.04 package.
而最新版 1.11.1 只有一個安全性更新，應該也可以跑... 來找看看會不會有人包 ppa 出來。
Let's Encrypt 的公告出來了：「Full Support for IPv6」。
之前在看 http-01 challenge 時都是走 IPv4 認證，現在宣佈可以走 IPv6 了：
Let’s Encrypt is happy to announce full support for IPv6.
在「Google’s QUIC protocol: moving the web from TCP to UDP」這篇前半部在介紹 QUIC (走 UDP 的 TLS)，後半部則提到了幾個重點。
首先是 Google Chrome 從 52 開始 (也就是現在的 stable 版) 預設會開啟 QUIC (以前是只有 Google 自家的 domain)，這讓採用的價值變高：
Since no one has QUIC support enabled by default in the client, you're probably still safe to run it and enable QUIC in your own browser(s). (Update: since Chrome 52, everyone has QUIC enabled by default, even to non-whitelisted domains)
再來是 QUIC 走 UDP/443：
Well, if we want to allow the QUIC protocol, we will need to allow 443/UDP too.
同時因為走的 Protocol 跟以前不同，所以我可以跑另外一隻 Server 服務使用者，目前只有 Caddy 有支援，雖然是實驗性質：
Right now, the only webserver that can get you QUIC is Caddy since version 0.9.
Both client-side and server-side support is considered experimental, so it's up to you to run it.
至少可以先把 firewall 打開了...
YouTube 公佈了 Google 產品使用 HTTPS 的情況，這次包括了 YouTube 在內：「YouTube's road to HTTPS」。
Netflix 與 YouTube 在北美是兩個最大的 internet 流量 (Netflix, YouTube video streaming dominate internet traffic in North America)，要注意的是 Netflix 也是全上 HTTPS (It wasn’t easy, but Netflix will soon use HTTPS to secure video streams)：
Netflix makes up a huge part of internet downloads, the company said, with the streaming service accounting for 37.1 per cent of all downstream traffic in North America during September and October.
YouTube accounted for the second-largest share of download traffic, at 17.9 per cent, followed by regular internet browsing at 6.1 per cent.
海外的部份 YouTube 就更高了，所以 YouTube 的 HTTPS rate 其實對整個 internet 很重要。而 YouTube 宣佈目前已經有 97% 的量上 HTTPS 了，應該是 Google 資料中心最大的流量：
We're proud to announce that in the last two years, we steadily rolled out encryption using HTTPS to 97 percent of YouTube's traffic.
Google 宣佈 www.google.com 要上 HSTS 了：「Bringing HSTS to www.google.com」。
雖然都已經使用 EFF 的 HTTPS Everywhere 在跑確保 HTTPS，但這個進展還是很重要，可以讓一般使用者受到保護...
Google 的切換計畫是會逐步增加 HSTS 的 max-age，確保中間出問題時造成的衝擊。一開始只會設一天，然後會逐步增加，最後增加到一年：
In the immediate term, we’re focused on increasing the duration that the header is active (‘max-age’). We've initially set the header’s max-age to one day; the short duration helps mitigate the risk of any potential problems with this roll-out. By increasing the max-age, however, we reduce the likelihood that an initial request to www.google.com happens over HTTP. Over the next few months, we will ramp up the max-age of the header to at least one year.
Netflix 對於寫了一篇關於隱私保護的技術細節：「Protecting Netflix Viewing Privacy at Scale」。
其中講到 2012 年的 Netflix Open Connect 中的 Open Connect Appliance (OCA，放伺服器到 ISP 機房的計畫) 只有單台伺服器 8Gbps，到現在 2016 可以達到 90Gbps：
As we mentioned in a recent company blog post, since the beginning of the Open Connect program we have significantly increased the efficiency of our OCAs - from delivering 8 Gbps of throughput from a single server in 2012 to over 90 Gbps from a single server in 2016.
早期的 Netflix 走 sendfile() 將影片丟出去，這在 kernel space 處理，所以很有效率：
其中一個遇到的效能問題是，當影片本身也改走 HTTPS (TLS) 時，會導致 sendfile() 無法使用，而必須在 userland space 改走回傳統的 write() 架構，這對於效能影響很大：
所以他們就讓 kernel 支援 AES 系列加密 (包括 AES-GCM 與 AES-CBC)，效能的提昇大約是 30%：
Our changes in both the BoringSSL and ISA-L test situations significantly increased both CPU utilization and bandwidth over baseline - increasing performance by up to 30%, depending on the OCA hardware version.
文章開頭也有提到選 AES-GCM 與 AES-CBC 的一些來龍去脈，主要是 AES-GCM 的安全強度比較好，另外考慮到舊的 client 不支援 AES-GCM 時會使用 AES-CBC：
We evaluated available and applicable ciphers and decided to primarily use the Advanced Encryption Standard (AES) cipher in Galois/Counter Mode (GCM), available starting in TLS 1.2. We chose AES-CGM over the Cipher Block Chaining (CBC) method, which comes at a higher computational cost. The AES-GCM cipher algorithm encrypts and authenticates the message simultaneously - as opposed to AES-CBC, which requires an additional pass over the data to generate keyed-hash message authentication code (HMAC). CBC can still be used as a fallback for clients that cannot support the preferred method.
另外 OCA 機器本身也都夠新，支援 AES-NI 指令集，效能上不是太大的問題：
All revisions of Open Connect Appliances also have Intel CPUs that support AES-NI, the extension to the x86 instruction set designed to improve encryption and decryption performance. We needed to determine the best implementation of AES-GCM with the AES-NI instruction set, so we investigated alternatives to OpenSSL, including BoringSSL and the Intel Intelligent Storage Acceleration Library (ISA-L).
不過在「Netflix Open Connect Appliance Deployment Guide」(26 July 2016 版) 這份文件裡看起來還是用多條 10Gbps 透過 LACP 接上去：
You must be able to provision 2-4 x 10 Gbps ethernet ports in a LACP LAG per OCA. The exact quantity depends on the OCA type.
可能是下一版準備要上 40Gbps 或 100Gbps 的準備...？
又是一個對 HTTPS 的攻擊：「HEIST attack on SSL/TLS can grab personal info, Black Hat」、「New attack steals SSNs, e-mail addresses, and more from HTTPS pages」。
一樣是 Compression 產生的 side-channel attack，只是這次是結合 TCP window size 的攻擊。投影片可以在「HTTP Encrypted Information can be Stolen through TCP-windows (PDF)」這邊看到。
這次的攻擊只需要在瀏覽器上插入 HTTP 產生 HTTPS 的流量，然後從旁邊看 HTTPS 連線的 TCP packet 就可以了，而且對 HTTP/2 也很有效：
而且很不幸的，目前沒有太好的解法，因為所有的攻擊手法都是照著使用者無法發現的路徑進行的 @_@
對於使用者，大量使用 HTTPS (像是 HTTPS Everywhere 這樣的套件)，能夠降低政府單位與 ISP 將 javascript 插入 HTTP 連線，產生 HTTPS 的行為。
而對於網站端來說，全站都隨機產生不同長度的 HTTP header 可能是個增加破解難度的方式 (而且不會太難做，可以透過 apache module 或是 nginx module 做到)，但還是可以被統計方法再推算出來。
不知道有沒有辦法只對 HTTPS 開 javascript，雖然攻擊者還是可以用 <img> 攻擊...
也許以後 HTTP/3 之類的協定會有一區是不壓縮只加密的，避開這類 compression-based attack @_@
最新的攻擊算是實戰類的攻擊，理論基礎以前都已經知道了，只是沒有人實際「完成」。算是近期少數直接對演算法的攻擊，而這些演算法剛好還是被用在 TLS 與 OpenVPN 上，所以嚴重性比較高：「SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN」。
攻擊的條件是 block cipher 的 block size，而非 key length，所以就算是 256 bits 的 Blowfish 也一樣也受到影響。
這次順利打下 Blowfish 與 3DES。這兩個 cipher 的 block size 都是 64 bits，所以對於 birthday attack 來說只要 232 就可以搞定：
This problem is well-known by cryptographers, who always require keys to be changed well before 2n/2 blocks. However it is often minimized by practitioners because the attacks require known plaintext, and reveal only little information. Indeed, standard bodies only recommend to change the key just before 2n/2 blocks, and many implementations don't enforce any limit on the use of a key.
在 OpenVPN 打 Blowfish 的部份 (Blowfish 是 OpenVPN 預設的 cipher)：
In our demo, it took 18.6 hours and 705 GB, and we successfully recovered the 16-byte authentication token.
以及 HTTPS 打 3DES 的部份 (為了相容性問題)：
Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.
都是有可能的等級。也該來拔掉對 IE8 的支援了... orz
看到「OpenSSL 1.1.0 released」這篇得知大家期待已久的 OpenSSL 1.1.0 出了，在 1.1.0 的重要新功能中，對 ChaCha20 + Poly1305 的支援算是大家等很久的：
- Support for ChaCha20 and Poly1305 added to libcrypto and libssl
由於 RC4 已經被證明不安全，OpenSSL 內變成沒有堪用的 stream cipher，這邊總算要補上來了...
另外兩個也頗有趣的：
- Support for scrypt algorithm
- Support for X25519
多了些東西...
雖然平常早就把 WoSign 移除信任，但在「Mozilla考虑对沃通CA采取行动」這邊看到有趣的消息，翻了一下 Gervase Markham 發表的原文還蠻精彩的：「Incidents involving the CA WoSign」。
第一次事件 (Incident 0) 是在 2015/04/23，攻擊者只要能夠證明他能控制某個 TCP port，就會發出 certificate：
On or around April 23rd, 2015, WoSign's certificate issuance system for their free certificates allowed the applicant to choose any port for validation. Once validation had been completed, WoSign would issue certificates for that domain. A researcher was able to obtain a certificate for a university by opening a high-numbered port (>50,000) and getting WoSign to use that port for validation of control.
設計不良造成的資安事件總是會發生。重點在於 Google 知道，但 Mozilla 完全不知道：(我講得很保守是因為這個句子在 thread 後面被澄清解釋的更慘，參考後文)
This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.
更嚴重的是，這次的事件在 WoSign 的稽核上沒有出現：
* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].
第二次事件 (Incident 1) 是在 2015 年六月，也是資安設計的問題，當你可以拿到 WoSign 所指定的 subdomain 控制權後，你就可以拿到 parent domain 的 certificate，而這次甚至被拿到 GitHub 全系列的 certificate：
The reporter proved the problem in two ways. They accidentally discovered it when trying to get a certificate for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then confirmed the problem by using their control of theiraccount.github.com/theiraccount.github.io to get a cert for github.com, github.io, and www.github.io.
嗯，也沒通報：
* This misissuance incident was not reported to Mozilla by WoSign as it should have been (see above).
嗯，稽核也沒出來：
* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].
嗯，被拿到的 domain (ucf.edu) 也沒 revoke：(可以從「crt.sh | 29647048」這邊看到)
They reported this to WoSign, giving only the Github certificate as an example. That cert was revoked and the vulnerability was fixed. However recently, they got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later.
第三次事件 (Incident 2) 則是在 2016 年七月，由於現在大多數的瀏覽器都會對 2016 後簽出的 SHA-1 憑證直接標示為不安全，而 WoSign 的 API 提供造假，讓簽名日期 (notBefore) 簽在 2015/12/20：
Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm.
嗯，然後否認造假：
* WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "this date is the day we stop to use this code"[4]. If that is true, it is not clear to us how StartCom came to deploy WoSign code that WoSign itself had abandoned.
嗯，然後還是沒有回報給 Mozilla：
* This misissuance incident was not reported to Mozilla by WoSign as it should have been.
稽核報告應該是因為這太新，還沒開始做？
另外在 thread 討論時，Google 的 Ryan Sleevi 澄清的更慘：
Clarification: In none of these incidents was Google notified proactively by WoSign. Instead, Google received communication from internal or external researchers regarding these issues, either prior to resolution or much later after the fact, and subsequently contacted WoSign regarding them.
It was only when Google found out recently that other programs were NOT notified, proactively, as had been expected, that Google shared the details it was aware of regarding various CA incidents, including those of WoSign, mentioned in this thread.
也就是說，是 Google 主動發現這些問題，並且通報 WoSign。後來過了許久發現 WoSign 沒有照規定通報其他 CA Root 管理單位 (以這邊來說是 Mozilla)，於是 Google 決定主動通報其他單位，然後大～爆～炸～
在密碼學理論裡，CA 架構是靠著稽核建立信任的，這次的事情又再次證實這個問題 (但目前沒有其他好的機制可以做)。來猜測下場的話，我的預期是會像拔掉 CNNIC 的作法拔掉信任，但針對之前發出的 certificate 設為白名單 (直到過期)：
Google Chrome 宣佈從 56 版開始，將會對 HTTP 網站標示「Not secure」：「Moving towards a more secure web」，這是 Google 給的解釋圖片：
另外還更進一步規劃之後的圖示，標成紅色警示：
藉由這樣的表現來更大力推動 HTTPS 化。
關於 HPKP，可以參考「HTTP Public Key Pinning 介绍」這篇介紹，寫得很清楚。
HPKP 是解決 CA 架構錯發憑證的方案 (無論是無意或是故意)，像是最近吵的比較熱的 WoSign 發出 GitHub 的憑證的問題就可以用 HPKP 解。
原理上來說，就是在 HTTP header 裡面指出這個站台所允許的 Root CA 有哪些。所以跟 HSTS 一樣是走 Trust On First Use 架構，當 client 第一次連上的時候會記下資訊，之後就可以使用這個資訊來驗證。
但 HPKP 與 HSTS 不同的地方在於，HSTS 只是個 Yes/No 問題 (i.e. 是否強迫使用 HTTPS)，而且通常 migrate 上去後就不會拔掉。
但 HPKP 則是要指定 Root CA，這代表不能隨便換一家簽。當你用的那家 Root CA 出包時就苦了... (就像 WoSign 免費憑證的問題)
這使得 HPKP 的實作成本過高，而且得到效益太低，另外也因為替代的方案有不少 (像是 Certificate Transparency)，導致 HPKP 根本沒什麼人用：「Is HTTP Public Key Pinning Dead?」。
在 comment 有人直接拉出來統計，使用的比率反而在下降：
From my stats looking to the Alexa 1K top websites from 2015-07-26 to 2016-07-31 the number of websites NOT using HPKP increase from 99.47% to 99.58% which means almost nothing.
不過我覺得算是平行發展吧，這些驗證的技術都不怎麼衝突... HPKP 解決問題的方法非常的技術面，而 Certificate Transparency 還是走稽核路線讓 Root CA 回報每一個發出的 Certificate...
這個產品就如同標題所說的方式而已，做起來不難，只是一直沒人做就是了：「How we brought HTTPS Everywhere to the cloud (part 1)」。
傳統的作法是直接硬幹下去換掉，或是用 header 讓瀏覽器主動轉過去：
A naive way to do this would be to just rewrite
http://links tohttps://or let browsers do that withUpgrade-Insecure-Requestsdirective.
但這有必須有兩個假設成立才可以：
而 HTTPS Everywhere 則是用人力確認了哪些網站可以這樣玩。CloudFlare 利用這份清單改寫程式碼裡面的 HTTP 連結，僅可能將 HTTP 資源換成 HTTPS。算是還不錯的方式...
之後有可能再推出對 HTTP images 與 HTTP assets 的 proxy cache？
一直以為 Google Chrome 的 [*.] 只能用在開頭，剛剛測了才發現可以用在中間，所以就用這樣的方式擋下 HTTP 網站的 JavaScript：
http://[*.]
這樣就可以減少 HTTP request 被 hijack 插入 javascript 的問題...
之前在「谈谈 Nginx 的 HTTP/2 POST Bug」這邊提到了 nginx 的一個 bug：「當 HTTP/2 的第一個 request 是 POST 時連線會失敗」的問題，這個問題在 mainline 版本的 1.11.0 解決了，但 stable 版一直沒有出新版 back-porting 回來。
而剛剛看到 1.10.2 將 http2_body_preread_size 從 mainline 版本弄回來解決了：「[nginx-announce] nginx-1.10.2」。
*) Change: HTTP/2 clients can now start sending request body immediately; the "http2_body_preread_size" directive controls size of the buffer used before nginx will start reading client request body.
然後剛剛發現 Ondřej Surý 老大分別弄出了 nginx (stable 版本) 與 nginx-mainline (mainline 版本) 的 PPA，所以也可以考慮可以直接換到 mainline 上？這樣也是個方法...
在「New Work in Seoul」這邊看到 QUIC 的消息：
The QUIC working group has just been chartered, and will meet for the first time in Seoul. This working group is taking Google’s pre-standardization QUIC protocol that has been deployed in production for several years, and will use it as a starting point to develop a UDP-based, stream-multiplexing, encrypted transport protocol with standardized congestion control, TLS 1.3 by default, a mapping for HTTP/2 semantics over QUIC, and multipath extensions. This is the IETF’s first standardized always-encrypted transport protocol, so careful consideration of applicability and operational capabilities will be key for success.
在 IETF 的 Datatracker 上也可以看到記錄了：「QUIC (quic)」，最下面的 Milestones 可以看到第一階段的目標是在明年二月把基本的協定都定下來，之後再加東西上去。
由於架構的隔離政策，有些服務需要透過 VM 裡面的 Windows 存取，所以又花了點時間看看 PuTTY 到底有沒有改善下載問題，也就是 2014 年「Downloading Software Safely Is Nearly Impossible」這邊作者提到的問題 (之前在「如何安全下載軟體...」這篇有提過)。
而即時再過了兩年半，還是沒辦法確認你抓到的 PuTTY 是正確的，Let's Encrypt 還是沒上...
找了一些替代方案，看到 mRemoteNG 這個可以連多種不同 Protocol 的專案，應該會是解法，裝起來用了一陣子感覺還算 okay，之後應該會拿這個用：「mRemoteNG is the next generation of mRemote, open source, tabbed, multi-protocol, remote connections manager.」。
話說回來，找資料的時候發現「simon-git: putty-website (master): Owen Dunn」這篇，在三月提到了：
Switch to https for release binary downloads from the.earth.li
The main PuTTY website is still http until chiark sorts out
LetsEncrypt or other SSL arrangements, but I think we can sensibly
switch to https for the release binaries from the, which already
provides https.
後續好像就沒有進度了...
在明年一月的 Google Chrome 56 將會停止支援 SHA-1 SSL Certificate：「SHA-1 Certificates in Chrome」，唯一的例外是自己建立的 CA，主要是給企業內部用的：
Starting with Chrome 54 we provide the
EnableSha1ForLocalAnchorspolicy that allows certificates which chain to a locally installed trust anchor to be used after support has otherwise been removed from Chrome.
但安全性的標示不會是綠色的鎖頭：
Features which require a secure origin, such as geolocation, will continue to work, however pages will be displayed as “neutral, lacking security”.
使用 SHA-1 程式碼的完全移除預定在 2019 年 (大約兩年多)：
Since this policy is intended only to allow additional time to complete the migration away from SHA-1, it will eventually be removed in the first Chrome release after January 1st 2019.
但如果對 SHA-1 攻擊有重大突破的話也會考慮提前：
We may also remove support before 2019 if there is a serious cryptographic break of SHA-1.
由於 Firefox 要支援 Certificate Transparency 的緣故，在「Mozilla CT Policy」這邊 Mozilla 在討論要建立自己的 CT policy 以及自己的架構：
CT is coming to Firefox. As part of that, Mozilla needs to have a set of CT policies surrounding how that will work. Like our root inclusion program, we intend to run our CT log inclusion program in an open and transparent fashion, such that the Internet community can see how it works and how decisions are made.
這樣就有個開頭了...
七月的時候提到「Google Chrome 引入 CECPQ1，開始測試 Post-Quantum Cryptography」，剛剛看到 Adam Langley 寫了一些數據出來：「CECPQ1 results」。
目前看起來對於網路速度不快的使用者會影響比較大，最慢的 5% 使用者大約慢了 20ms，最慢的 1% 使用者會慢 150ms：
Although the median connection latency only increased by a millisecond, the latency for the slowest 5% increased by 20ms and, for the slowest 1%, by 150ms. Since NewHope is computationally inexpensive, we're assuming that this is caused entirely by the increased message sizes. Since connection latencies compound on the web (because subresource discovery is delayed), the data requirement of NewHope is moderately expensive for people on slower connections.
由於實驗算是完成了，加上 TLS 已經有規劃了，所以 Google Chrome 打算拔掉這個功能等標準出來：
At this point the experiment is concluded. We do not want to promote CECPQ1 as a de-facto standard and so a future Chrome update will disable CECPQ1 support. It's likely that TLS will want a post-quantum key-agreement in the future but a more multilateral approach is preferable for something intended to be more than an experiment.
![[Billion Meta Lab] 反转·血色百合 Omagoto...](http://pic.microseventh.eu.org/i/2026/01/09/69611dafa7f9f.png)
