在「Listening to satellites for 30 dollars」這篇文章介紹了如何接受氣象衛星的訊號，並且轉成圖片...
關鍵的兩個軟體，一個是作者是先用 GQRX 收下來，然後用 WXtoImg 轉成圖片，這是作者抓下來的成果：(NOAA-15 的資訊)
如果在刻一些程式儘量全自動化，用 Raspberry Pi 丟到陽台收訊號轉換，好像是個不錯的方法？不知道衛星每天丟出來的量有多少...
Month: November 2015
nginx 的 TCP Fast Open
在「Enabling TCP Fast Open for NGINX on CentOS 7」這邊看到 nginx 對 TCP Fast Open (TFO，RFC 7413) 的支援早在 1.5.8 就有了，而 Linux Kernel 也是 3.7 之後就全面支援了。
TCP Fast Open 利用第一次連線後產生的 TCP cookie，在第二次連線時可以在 3-way handshake 的過程就開始傳輸，藉此大幅降低 latency。
設定方法不難，先在 kernel 設定 net.ipv4.tcp_fastopen=3，再加上 fastopen=number 就可以了，像是這樣：
listen 80 fastopen=256
不過目前 NGINX Mainline 上的版本好像沒有編進去，暫時沒辦法測...
Hostname 與 Username 的保留名稱問題
在「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
Raspberry Pi Zero
Raspberry Pi 出了新的系列，只要 USD$5 的 Raspberry Pi Zero：「Raspberry Pi Zero: the $5 computer - Raspberry Pi」。
機器更小了，不過要注意的是沒有網路介面。看起來比較像是接機器人之類的？先用 USB 裝一裝，裝好後就都不需要了...
- A Broadcom BCM2835 application processor
- 1GHz ARM11 core (40% faster than Raspberry Pi 1)
- 512MB of LPDDR2 SDRAM
- A micro-SD card slot
- A mini-HDMI socket for 1080p60 video output
- Micro-USB sockets for data and power
- An unpopulated 40-pin GPIO header
- Identical pinout to Model A+/B+/2B
- An unpopulated composite video header
- Our smallest ever form factor, at 65mm x 30mm x 5mm
Mozilla 維護的 Public Suffix List
在「域名小知识：Public Suffix List」這邊看到由 Mozilla 維護的 Public Suffix List，記錄了哪些 suffix 屬於 top-level：
- Avoid privacy-damaging "supercookies" being set for high-level domain name suffixes
- Highlight the most important part of a domain name in the user interface
- Accurately sort history entries by site
所以 supercookie 阻擋機制是從這邊來的...
讓 nginx 看到 5xx 回應時，去另外一台有開 debug-mode 的 server 上再跑一次
Debug 模式會比一般的模式來的慢，但可以看到更多資訊。以往的問題是 5xx 難以重製，而 NGINX 的「Capturing 5xx Errors with a Debug Server」這篇文章介紹了如何用 nginx 實作標題的功能。
如果是隨機造成的問題就沒辦法重製，但如果是 client 的狀態造成的問題，就很有可能可以抓出來... 不是解決所有問題，但可以幫助解掉以前不太好解的狀況。
Google Chrome 上有大量 Extension 在追蹤個人行為
在「Chrome Extensions – AKA Total Absence of Privacy」這邊討論了 Google Chrome 官方的 Web Store 上有很多應用程式為了賺錢在追蹤個人行為：
We’ve seen some indications on Chrome Extension-forums that it’s around $0.04 per user/month.
而且因為是 extension，可以直接穿越 Ghostery 之類的防護網，於是就變得無法 opt-out。你可以利用「In order to continuously improve and maintain this software we work with」這樣的字串去找，會以發現有不少 extension 用了 Fairshare 的方案來賺錢。
文章作者呼籲 Google 要提出方案來制止這類行為，不過我覺得 Google 應該是不會做...
V8 的 Math.random() 亂度不足的問題
在「TIFU by using Math.random()」這篇看到作者踩到地雷，於是在討論 V8 Engine 的 Math.random() 的亂度不足。
其實這個問提早在 2012 年就有人在 StackOverflow 上詢問：「Why is Google Chrome's Math.random number generator not *that* random?」，而且也回答得很清楚。
而 Mozilla 這邊在 2006 年也被提出了類似的問題：「Bug 322529 - Upgrade Math.random() to a better algorithm, such as Mersenne Twister」。
文章中間花了許多篇幅講 PRNG 的介紹，以及 cycle length 的說明，重點其實在結論的部份。
主要是因為 V8 Engine 的 Math.random() 實作的是 MWC1616 演算法 (Fast random number generation using 128 bit multimedia extension registers on Pentium class machines)，而這個演算法用起來也綁手綁腳：
If you’re only using the most significant 16 bits it has a very short effective cycle length (less than 2³⁰).
有兩個方向可以改善 (不衝突的方向)，一個是使用 CSPRNG (保證有極長的 cycle length)，另外一個請求 V8 Engine 把 Math.random() 的演算法換掉，像是 MT19937 這類 cycle length 超級長的演算法。
不知道後續有沒有機會改善...
Firefox 支援 OCSP Must-Staple
Firefox 宣佈支援 OCSP Must-Staple：「Improving Revocation: OCSP Must-Staple and Short-lived Certificates」。
先前的 SSL certificate 的 revoke 技術目前是透過 CRL 與 OCSP 兩個技術在支撐，前者是列出所有被 revoke 的清單，後者則是瀏覽器主動去指定的 server 確認這個 SSL certificate 是否有效。但這兩個方法都有嚴重的問題。
CRL 的問題是 revoke 清單會愈來愈多。這完全沒辦法 scale。
OCSP 的問題有幾個，一個是熱門網站的 SSL certificate 會讓 OCSP server 的負擔非常重 (不過還是有些辦法打散)。第二個問題是 OCSP server 會知道哪些 IP 造訪了哪些網站，使得隱私權受到嚴重侵害。第三個問題則是 client 需要再連線確認花掉很多時間，而且失敗機率超高：
However, these checks can be slow and unreliable. They time out about 15% of the time, and take about 350ms even when they succeed.
也因為極度不穩定，對於一般的 SSL certificate 在連不到 OCSP server 時，沒有瀏覽器敢直接 hard-fail (EV SSL certificate 是強制要求 OCSP 要過)，於是反而給了攻擊者一個很簡單的方法：取得 private key 攻擊時順便擋掉對 OCSP server 的連線。
後來 OCSP 技術改善而推出 OCSP stapling，由 server 定時去 OCSP server 取得「這個 SSL certificate 未被 revoke」的簽名認證後，一起在 TLS connection 裡傳輸給 client 端，這樣有許多好處：
- 隱私問題直接解決了，因為 server 是固定時間去抓，OCSP server 完全不知道使用者端的資訊 (甚至連「有沒有來連線」都不知道)。
- 穩定性提昇了，因為 OCSP server 的負荷量變低，可以預期 OCSP server 會變得比較容易 scale。
- 用戶端的速度增加了，因為 client 不需要額外的連線確認。
而這次 Firefox 更進一步支援讓 SSL certificate 上標注 OCSP Must-Staple，表示這個 certificate 必須有 OCSP stapling 才行，這使得這類 SSL certificate 在 revoke 後無法被利用，真正的完全失效。
不知道其他家會不會跟進...
Amazon 之前放出的 s2n 的安全性問題
Amazon 之前放 s2n 出來當作 TLS protocol 的方案，於是就有人摸出東西來：「Lucky Microseconds: A Timing Attack on Amazon's s2n Implementation of TLS」。
即使是經過外部資安檢證，仍然還是有找到問題。這次找到的問題是 timing attack 類在 CBC-mode 下的 plaintext recovery：
At the time of its release, Amazon announced that s2n had undergone three external security evaluations and penetration tests. We show that, despite this, s2n - as initially released - was vulnerable to a timing attack in the case of CBC-mode ciphersuites, which could be extended to complete plaintext recovery in some settings.
攻擊分成兩個階段：
Our attack has two components. The first part is a novel variant of the Lucky 13 attack that works even though protections against Lucky 13 were implemented in s2n. The second part deals with the randomised delays that were put in place in s2n as an additional countermeasure to Lucky 13. Our work highlights the challenges of protecting implementations against sophisticated timing attacks.
最後還是酸了一下 Amazon：
It also illustrates that standard code audits are insufficient to uncover all cryptographic attack vectors.
Amazon 的官方說明則在「s2n and Lucky 13」這邊可以看到。