最近很紅的 Firesheep...

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 解決效能的問題...

This entry was posted in Browser, Computer, Firefox, Murmuring, Network, Security, Software, WWW and tagged , , , , , . Bookmark the permalink.

3 Responses to 最近很紅的 Firesheep...

  1. GD says:

    補充一下關於第二段:
    RFC2109要求瀏覽器不得將標示為 secure的 cookie以明文傳輸,登入系統也應該實做 secure這個 flag,
    像是 Google Gaia的SSID、Gmail的 GX等cookie,都不會在任何情況下以HTTP明文送出。

  2. Latte Wu says:

    很希望 有一天,我也能像前輩這樣打出這麼一篇文章...
    但是好像都沒有辦法確定方向...
    難過~

    謝謝前輩分享 :)

  3. Fun says:

    hi
    謝謝你的分享
    想請教為什麼用了SSL,就能防止這件事.
    我們送出去時,是用什麼加密的.server怎麼知道?
    如果server知道而且能解.為什麼攔的人,不能解.

Leave a Reply

Your email address will not be published. Required fields are marked *