安裝 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...

網路愈來愈不安全,能自救的方式並不多...

這兩件事情加起來會不會太巧合...

首先是有攻擊者成功利用 Comodo CA 產生 www.google.comlogin.yahoo.comlogin.skype.comaddons.mozilla.orglogin.live.com 的 SSL certificate:「Report of incident on 15-MAR-2011」,雖然被 revoke (撤銷),但是我們知道 revoke 機制極度脆弱:「Revocation doesn't work」。

過沒幾天,有人發現 AT&TFacebook 的流量會流經中國 ISP 的網路設備:「Facebook traffic mysteriously passes through Chinese ISP」。

關於這幾件事情,我們能做的並不多,只能僅可能的做:

接下來就是祈禱了...

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

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

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

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

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

單一 IP/Port 多個 SSL Certificate:SNI

SNI 是「Server Name Indication」的縮寫,是 SSL Virtual Hosting 中很重要的一塊。

到目前為止,最主要是卡在 Windows XP 平台的 SSL/TLS 沒有支援,導致使用系統 SSL/TLS Library 的 IE6/7/8 都不支援 SNI。以 gs.statcounter.com 的數據「Top 5 Operating System from Jan 10 to Jan 11」來看,Windows XP 還有 48% 的市占率...

要等到 Windows XP 的市占率夠低後才有機會看到 SNI CDN...