安裝 Certificate Patrol 增加對最近 SSL Certificate 問題的抵抗性...

這只能掙扎,但還是要掙扎啊!

Certificate Patrol 是一個 Firefox 延伸套件,你可以設定在新看到 SSL Certificate 的時候跳出一個視窗來告訴你這個 SSL Certificate 的資訊:

如果你平常有在用 https://mail.google.com,結果突然發現有天跳出視窗,你就應該要有所警覺了...

這下可包大了,居然有一堆 "localhost" 這類的 SSL Certificate 被發出來...

這些 CA 是怎麼管理下面的單位的啊...

Slashdot 報導了 EFF 的 Chris Palmer 發現有大量 Unqualified Name 被 sign 過:「Thousands of SSL Certs Issued To Unqualified Names」、「Unqualified Names in the SSL Observatory」。

依照原文中「You can also use the Observatory in an Amazon EC2 instance we created.」這句話,應該是直接掃整個 IPv4 network 了吧,反正以現在的各種技術來說,IPv4 address space 不大?

結果相當豐碩,包括了 2201 個 "localhost"、806 個 "exchange"、2383 個 /^\w*exchange\d+$/、5657 個 /^\w*exch\d*$/。光是可以在 Internet 上被觀察到的 Unqualified Name 就有 37244 個。

甚至連 EV Certificate 都有 Unqualified Name 被 sign:「www.prism.gatech.edu/~gmacon3/ssl-observatory/unqualified_local_rfc1918_ev.txt」。(那個 VeriSign 你太誇張了,"CN=Bownedev" & "CN=qa-sescib-web1" & "CN=tc-teweb01-s" 你也能過?EV 的文件檢查根本沒再看的喔?)

在「www.prism.gatech.edu/~gmacon3/ssl-observatory/unqualified_local_rfc1918_all.txt」這邊有張表列出出包單位的數量可以看...

雖然一月就做完這份資料,但不得不說 EFF 補刀的時間真棒... 趁這陣子 CA 架構問題正熱的時候寫一篇來補一刀 XD

在 Perl 裡用 LWP::UserAgent (以及繼承它的模組) 時使用 HTTPS 連線處理 CA 認證...

libwww-perl 裡的 LWP::UserAgent 可以處理 HTTPS,並利用 CA 驗證 public key 是否簽過。在 FreeBSD 下安裝 ca_root_nss 後可以在 /usr/local/share/certs/ 下看到檔案,於是可以這樣用:

#!/usr/bin/env perl
use strict;
use warnings;
use LWP::UserAgent;

INIT {
    my $ua = LWP::UserAgent->new;
    $ua->ssl_opts(SSL_ca_file =>
        '/usr/local/share/certs/ca-root-nss.crt');

    my $res = $ua->get('https://mail.google.com/mail/');
    print $res->content;
}

Debian 或是 Ubuntu 下則是透過 ca-certificates 裝到 /etc/ssl/certs/ 下,並且分成很多檔案,這時候本來的 ssl_opts 就要改成 SSL_ca_path => '/etc/ssl/certs/';

PS:FreeBSD 上因為是單檔,依照 SSL_CTX_load_verify_locations(3) 這邊的說明,沒辦法用 CApath...

HTTPS 的 Persistent Cache...

Twitter 上又看到有人在講 HTTPS 的資料無法 persistent cache (寫入硬碟保存),所以當瀏覽器重開後就消失,如果能避免使用就應該避免...

但實際上並不是這樣,HTTPS 的資料是「可以」被 persistent cache 的,只是預設不會這樣作。

只要在 response header 裡告訴瀏覽器 Cache-Control: public,瀏覽器就會 persistent cache。因為你已經跟瀏覽器說這個檔案是公開資料,就算是透過 HTTPS 傳輸也可以寫到硬碟裡保存。在「HTTPS Performance Tuning」這篇文章裡有提到 IE 與 Firefox 都沒有問題...

有用 HTTPS 的可以檢查看看是不是能夠加速...

Twitter 提供使用者「強制使用 HTTPS」的選項

Twitter 剛剛公告,使用者現在可以選擇強制使用 HTTPS:「Making Twitter more secure: HTTPS」。

之前是透過 Force-TLS 強制設定 twitter.comapi.twitter.com 強制使用 HTTPS。現在官方提供這個功能等於多了一層保護...

目前還不包括 3rd-party 應用程式,只有網站版本與 iPhoneiPad 的官方 client。

所有的手機應用程式都應該要上 SSL (另一個說法,HTTPS)

這是實際用過一堆手機程式後的感想 XD

不覺得直接在捷運台北車站放一個 SSID 與某些公開讓大家免費使用的 Wifi,就可以收集到很多東西嗎...?

另外要注意的是很多便宜的 SSL Certificate 是沒有辦法過 AndroidiPhone 內建瀏覽器的認證的,要買之前先試著找 Demo Site 測試看看會比較保險。據說大多數的 wildcard ssl 都可以過認證,不過這也只是路邊聽來的,測過才是王道...

奇怪,我記得之前有看到有一張表格是列出手機上瀏覽器支援的情況,一時間要找卻找不到了...

Protocol Preserve URI 的過濾

雖然知道 //host.domain/path 這種 Relative Protocol 用法 (而且也用很久了),不過最近在 irc.perl.org 上的 #plack 剛好有人提到,再加上最近剛好有人在探討安全性問題:「Bypassing "RequestPolicy" Using Protocol Relative URLs」,剛好可以拿出來再說一次。

簡單來說就是「以 / 開頭的 URI 並非一定是 same origin,不可以以此當作 same origin 的判斷」。因為「//ajax.googleapis.com/ajax/libs/jquery/1.5.0/jquery.min.js」這種用法是正確的用法,表示保留 Protocol。

另外講些題外話,這個用法也還是有缺點,用在 IE 的 css 時會造成重複抓取 (到 IE9 都還是):「CSS files downloaded twice in Internet Explorer with protocol relative URLs」,script 或是 relative path 都不會,只有 css 會...

反過來說,因為 js 的部份大家都沒問題,所以當使用 Google 提供的 jQuery 時,「永遠」都應該使用「//ajax.googleapis.com/...」,因為 Google Libraries API 是同時支援 HTTP 與 HTTPS 的。

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