Home » Posts tagged "certificate" (Page 15)

AWS CloudFront 可以用自己的 SSL Certificate 了...

以往 CloudFront 只能用 *.cloudfront.net 當作 SSL domain,但在今天公告的「Custom SSL Domain Names and Root Domain Hosting for Amazon CloudFront」這篇說明內,宣佈可以上傳自己的 SSL certificate 使用了。

目前的價錢是 USD$600/month,不過是以小時計算。即使拋開錢的問題,在 CloudFront 已經支援 SSL 的前提下 (而且因為是 *.cloudfront.net,理論上是 cookie-free domain),技術面上暫時想不到什麼好處... 在 DNS 端自己混合多家 CDN 是個可能的方向?

OCSP 是如何影響 HTTPS 的效率...

Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability,然後發現各家 OCSP 的穩定性都不太好:「Certificate revocation and the performance of OCSP」。

OCSP 是 Online Certificate Status Protocol 的縮寫,當 HTTPS 連線建立中,client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制,因為已經發出去的簽名是無法被收回的,只好靠連線時再查詢。

另外一個機制比較舊,叫 CRL (Certificate Revocation List),則是屬於清單類的機制,更新速度比 OCSP 慢。

目前是以 OCSP 為主,而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。

可以看到 OCSP 檢查打開後對於速度的影響,有的影響很明顯,有的還好。而原文下面很多張 uptime 圖表也可以看出來各家 OCSP 的穩定性其實不怎樣,有些是直接上 Akamai 解決,有些是上 CloudFlare 解決 (然後遇到幾次 CloudFlare 爆炸就跟著炸 XD)

目前瀏覽器大多都是 soft-fail,也就是查不到就當作 pass。照目前的穩定性要推動 hard-fail (查不到就 break) 應該是頗有難度...

對於 HTTPS 速度很在意的人可以看一下內文的說明,可以挑 OCSP 速度比較快的幾家簽,對速度會有幫助...

這次 TURKTRUST 誤發 *.google.com SSL 憑證...

這次 TURKTRUST 誤發 *.google.com 憑證被 Google 當初佈下的網子抓到:「Enhancing digital certificate security」。

首先是每次 CA 出問題後都會對目前的 PKI 提出質疑的文章 (像是「TURKTRUST Incident Raises Renewed Questions About CA System」),在沒有有效的方法可以取代目前的 PKI 前,都是吵一吵之後就沒有結論,所以先不管這個題目。

想要提出來的是 Google 這次抓到的機制:「Public Key Pinning Extension for HTTP」,目前狀態仍是 draft。不過 Google 在 Google Chrome 13 就已經實作一部分了,並且把一堆 domain 寫死進去:「View of /trunk/src/net/base/transport_security_state_static.json」,可以看到 Google 的 domain 只允許這些 CA 簽:

      "name": "google",
      "static_spki_hashes": [
        "VeriSignClass3",
        "VeriSignClass3_G3",
        "Google1024",
        "Google2048",
        "EquifaxSecureCA",
        "GeoTrustGlobal"
      ],

任何想要在太歲爺上動土的都會被抓包 XD

另外 Google Chrome 還是沒有 Certificate 相關的 API,目前只有 API Proposal 掛著:「webRequest SSL Hooks」,相較於 Firefox 有不少 extension 可以用,這方面 Google Chrome 就差了不少...

GitHub 換 SSL certificate

離 expire 時間還很久,但是從 wildcard SSL certificate 換成普通的 SSL certificate:

不過 gist 沒換,用的仍然是 wildcard 這組:

這下可包大了,居然有一堆 "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...

Archives