幹壞事是進步最大的原動力
CloudFlare 有兩篇公告出來：「Announcing Keyless SSL™: All the Benefits of CloudFlare Without Having to Turn Over Your Private SSL Keys」、「Keyless SSL: The Nitty Gritty Technical Details」。前面的一篇偏向公告文 (以及公關稿)，而後面的一篇提到了實際運作的方式。
用兩張 Keyless SSL 的 flow 就可以知道差異了，一張是 RSA-based，一張是 DH-based：
把與 private key 相關的運算拆出來，由後方計算完成後再計算出 session key 與 client 溝通。如此一來，雖然速度比較慢，但 private key 管理在客戶自己手上...
也是一個禮拜前的消息，在 Slashdot 上看到對 HTTPS 的新攻擊，目前沒有好解法，NSA 應該開心到爆炸：「BREACH Compression Attack Steals SSL Secrets」。
說明可以參考「Vulnerability Note VU#987798 BREACH vulnerability in compressed HTTPS」這篇。
假設你的 ISP 想要抓出你的 Facebook (HTTPS) session id 或是 CSRF token (只要是有能力在中間攔截封包並修改資料的團體都可以，這邊以 ISP 為例)，作法是針對 HTTP 頁面值入 script，讓你的瀏覽器對 https://www.facebook.com/ 發出大量 request，藉由觀察這些 HTTPS 的長度就有機會取得 session id (或 CSRF token)...
CERT 的 security advisory 上是寫：
With a token of length 32 and a character space of size 16 (e.g. hex), the attacker needs an average of approximately 1,000 request if no recovery mechanisms are needed. In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests. A browser like Google Chrome or Internet Explorer is able to issue this number of requests in under 30 seconds, including callbacks to the attacker command & control center.
四千次就搞定了... 太！歡！樂！了！
Firesheep，一個 Firefox extension，利用截聽封包的方式取得 session 資訊，進而使用該 session 做壞事。原理其實很簡單，只是這次被包成 Firefox extension 後讓一般人都很容易可以「確認」這不是什麼困難的事情... 而在 Wifi 環境下封包的截聽就更容易了。
除此之外，這次公開 Firesheep 時有說明「登入已經是 HTTPS 所以就很安全了」這個錯誤的觀念。因為在 HTTPS 模式下登入所拿到的 session (通常是 cookie) 在 HTTP 模式下預設還是會以明文傳輸，所以截聽 HTTP 封包取得 session 後就可以處理很多事情了。
目前 client 端的解法都是建議全程 HTTPS 加密並加裝套件確保不會有 HTTP request。在 Firefox 目前看到的套件中有兩個，一個是 Force-TLS，這個套件可以設定某些 site 一定要使用 HTTPS。安裝這個套件而不做設定不會有效果。另外一個套件是 EFF 出的 HTTPS Everywhere，預設就會設定一堆常見的站台加密，對於一般人來說比較方便。
回過頭來提到 HTTPS 協定。SSL 的 AES encryption/decryption 其實很快 (以目前 Web 的傳輸量來看)，但啟始的 overhead 太大。再加上 HTTP 又是 stateless 協定，常常會需要重新連線。以目前 HTML5 WebSocket 支援加密的架構來看，以後有可能會用 WebSocket 加上 Javascript 解決效能的問題...