幹壞事是進步最大的原動力
在 Hacker News 首頁上看到 Mitmproxy 7 的消息：「Mitmproxy 7」。
比較重要的功能應該就是可以針對任意的 TLS 連線攔截分析了：
不過像是 STARTTLS 這類先在 plaintext 溝通，然後送出指令進入 TLS 的方式，目前就還沒支援：
Opportunistic TLS (STARTTLS) is not supported yet, but regular TCP-over-TLS just works!
另外是可以分析 WebSocket 內的傳輸資料：
應該是跑個 pip install -U mitmproxy 就可以升級了... (如果先前是用 pip 安裝的話)
在「The password reset MitM attack」這邊看到 PRMitM (Password Reset Man-in-the-Middle) 這樣的攻擊，原始論文在「The Password Reset MitM Attack」這邊可以取得。
用圖說明基本版的攻擊方式：
另外列出了各大站台的狀態：
以及各家簡訊的文字，可以發現不是每一家都有把產品的名稱寫上去：
這方法好有趣啊... XD
在「Don’t count on STARTTLS to automatically encrypt your sensitive e-mails」這邊提到了 STARTTLS 的問題，引用「Neither Snow Nor Rain Nor MITM ... An Empirical Analysis of Email Delivery Security」這篇論文的說明。
SMTP 裡 STARTTLS 的設計雖然可以加密，但仲所皆知，可以阻擋 EHLO 回應結果避免建立 STARTTLS 連線，而讓發送端改用傳統未加密的 SMTP 傳輸。而研究發現其實目前就有大規模的這種監控行為：
可以看到突尼西亞的監控情況遠超過想像...
目前的想法是發展一套類似 HSTS 的 Trust on first use 設計，也許在這份報告出來後可以加速催生...
熱騰騰的「OpenSSL Security Advisory [05 Jun 2014]」：
這太熱鬧了，第一個 security issue 可以在 MITM 的情況下，強迫選用比較差的 cipher：
An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers.
第三個則有可能直接爆破執行程式碼：
A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server.
接下來幾天對 SA 來說又是無止盡的升級地獄...
Google 在 Google Chrome 裡面有放一段 SSL 白名單 (transport_security_state_static.json)，針對某些特定 domain 只允許特定的 CA 所發出來的 SSL 憑證，另外當發現異常時也會回報。
這個機制可以保證在白名單內的網域比較不容易被 CA 搞到。
前幾天 Google 偵測到法國政府 ANSSI 的一個中介憑證發行單位 (Intermediate certificate authorities) 發出 Google 所擁有網域的 SSL 憑證：「Further improving digital certificate security」。
這也是繼一年前 TURKTRUST 發出的 *.google.com 以來再次被這個機制抓到的案例：「這次 TURKTRUST 誤發 *.google.com SSL 憑證...」。
同時，這也是首次政府機關相關的 CA 搞 MITMA (Man-in-the-middle attack)。
ANSSI 官方的說法是「誤發」：「Revocation of an IGC/A branch」，不過可信度... XD
Google 後來在 12/12 再次更新公告文章，決定把 ANSSI 的 CA 信任範圍限縮到法國相關的網域，共 13 個。(*.fr、*.gp、*.gf、...)
另外可以參考 Mozilla 在收到 Google 通知後的公告：「Revoking Trust in one ANSSI Certificate」。
Nokia 被抓到 Xpress Browser 會監控使用者連線，不論是 HTTP 或是 HTTPS：「Nokia Running A Man In The Middle Attack To Decrypt All Your Encrypted Traffic, But Promises Not To Peek」。
兩篇原始發現人的文章，第一篇「Nokia phone forcing traffic through proxy」是講 HTTP 的部份，第二篇「Nokia’s MITM on HTTPS traffic from their phone」是 HTTPS 的部份。
實際運作是類似於 HTTPS proxy 的作法。在「Nokia: Yes, we decrypt your HTTPS data, but don’t worry about it」有詢問 Nokia 後的官方回覆：
"Importantly, the proxy servers do not store the content of web pages visited by our users or any information they enter into them," the company said. "When temporary decryption of HTTPS connections is required on our proxy servers, to transform and deliver users’ content, it is done in a secure manner.
"Nokia has implemented appropriate organizational and technical measures to prevent access to private information. Claims that we would access complete unencrypted information are inaccurate."
GIGAOM 的翻譯簡單多了：
we decrypt your data, but trust us, we don’t peek. (對，我們的確這樣作，不過相信我們，我們沒有監聽。)
你真的相信這鬼話嗎 XDDDDDDDDD
以這張圖結尾：
