Protocol Preserve URI 的過濾

February 22, 2011, 6:38 am

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

雖然知道 //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 的。

↧

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

March 10, 2011, 3:23 am

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

≪ Previous: Protocol Preserve URI 的過濾

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

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

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

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

↧

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

March 15, 2011, 3:27 pm

≫ Next: HTTPS 的 Persistent Cache…

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

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

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

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

↧

HTTPS 的 Persistent Cache…

March 20, 2011, 8:36 pm

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

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

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

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

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

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

↧

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

March 30, 2011, 9:10 am

≫ Next: 這下可包大了，居然有一堆 “localhost”這類的 SSL Certificate 被發出來…

≪ Previous: HTTPS 的 Persistent Cache…

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…

↧

這下可包大了，居然有一堆 “localhost”這類的 SSL Certificate 被發出來…

April 6, 2011, 7:31 am

≫ Next: 安裝 Certificate Patrol 增加對最近 SSL Certificate 問題的抵抗性…

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

這些 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

↧

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

April 6, 2011, 5:14 pm

≫ Next: 很久沒看到 Twitter 噴出 Apache 錯誤訊息…

≪ Previous: 這下可包大了，居然有一堆 “localhost”這類的 SSL Certificate 被發出來…

這只能掙扎，但還是要掙扎啊！

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

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

↧

很久沒看到 Twitter 噴出 Apache 錯誤訊息…

May 19, 2011, 10:19 am

≫ Next: 維基百科全面支援 HTTPS (SSL)

≪ Previous: 安裝 Certificate Patrol 增加對最近 SSL Certificate 問題的抵抗性…

之前都是一般的自訂頁面，這次居然噴出 Apache 的…

看起來是 HTTPS only，我用其他瀏覽器看 HTTP 版本是正常的… (至少在沒登入的情況下)

↧

維基百科全面支援 HTTPS (SSL)

October 3, 2011, 9:55 am

≫ Next: 加快 SSL 加解密速度…

≪ Previous: 很久沒看到 Twitter 噴出 Apache 錯誤訊息…

維基百科在官方的 Blog 上宣佈，所有的服務都支援 HTTPS (SSL)：「Native HTTPS support enabled for all Wikimedia Foundation wikis」，也就是說，像是「https://zh.wikipedia.org/wiki/Wikipedia:首页」這樣的網址都支援了。

除了 *.wikipedia.org 以外，*.wikimedia.org 也支援了，於是包括像是 upload.wikimedia.org 也都可以使用 HTTPS：(圖片取自 File:Minori-Chihara-Animelo-Summer-Live-2011-08-27-21-41.jpg)

當然，還是有一些 script 寫死用 http，接下來應該都會被修正…

↧

加快 SSL 加解密速度…

January 27, 2013, 9:34 pm

≫ Next: OCSP 是如何影響 HTTPS 的效率…

≪ Previous: 維基百科全面支援 HTTPS (SSL)

看到 Ash Wu 貼的「5 easy tips to accelerate SSL」：

unhandledexpression.com/2013/01/25/5-e…

— Ash Wu (@hSATAC) January 28, 2013

先列出原作者在文章裡給的結論：

ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:RC4+RSA:+HIGH:+MEDIUM

不過，現在考慮 SSL 效能以行動平台為主 (因為桌機用軟體計算也超快)，而行動平台中 iOS 可以對 AES 與 SHA1 硬體加速 (iOS 4.3+)，Android 一般的情況下看起來沒得用，所以就自己取捨啦…

↧

OCSP 是如何影響 HTTPS 的效率…

April 16, 2013, 5:49 pm

≫ Next: 新的 HTTPS 攻擊：BREACH Compression Attack

≪ Previous: 加快 SSL 加解密速度…

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 速度比較快的幾家簽，對速度會有幫助…

↧

新的 HTTPS 攻擊：BREACH Compression Attack

August 15, 2013, 9:27 am

≫ Next: Imgur 支援 HTTPS…

≪ Previous: OCSP 是如何影響 HTTPS 的效率…

也是一個禮拜前的消息，在 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.

四千次就搞定了… 太！歡！樂！了！

↧

Imgur 支援 HTTPS…

September 26, 2013, 4:29 pm

≫ Next: 用 StartSSL 申請免費 SSL 憑證的說明…

≪ Previous: 新的 HTTPS 攻擊：BREACH Compression Attack

Imgur 宣佈支援 HTTPS：「100 million uniques, higher upload limits, and HTTPS support」。

以這張 http://i.imgur.com/X3L4U.jpg 範例：

同樣的 https://i.imgur.com/X3L4U.jpg 也會動，所以之後就可以使用 //i.imgur.com/X3L4U.jpg。

看了 DNS 記錄，目前 i.imgur.com 是透過 CloudFlare 的 CDN 加速。

↧

用 StartSSL 申請免費 SSL 憑證的說明…

September 28, 2013, 9:09 am

≫ Next: 提供 Docker 服務的 Stackdock… (不要用！)

≪ Previous: Imgur 支援 HTTPS…

鑑於 NSA 監聽的關係 (國內最近也很流行這套？)，最近國外介紹 StartSSL 的文章又熱門起來了：「Switch to HTTPS Now, For Free」。

不過因為 StartSSL 多了憑證驗證的問題，使得一般人申請變得相當麻煩，所以就有很多文章介紹 :o

這邊的 Generate Private Key 並不是你打算申請的 HTTPS 要用的，而是個人憑證…

這次這篇介紹文用了大量的圖片截圖，並且把產生 private key 以及 csr 的指令都列出來，後面還教你怎麼設定 nginx，相較於其他文件，應該是很清楚了…

↧

提供 Docker 服務的 Stackdock… (不要用！)

November 12, 2013, 12:02 pm

≫ Next: Twitter 也要上 PFS 了…

≪ Previous: 用 StartSSL 申請免費 SSL 憑證的說明…

先講結論，不要用，甚至連 copper 這家公司的產品都應該避開。

看到「Stackdock: Blazing Fast Docker-as-a-Service with SSDs – for $5」這篇文章，提到用 Docker 建立的服務。

首先是註冊流程就很有問題，註冊完後他要你收信登入 (這邊沒什麼問題)，結果收信後發現他的連結是：

https://stackdock.com/login?email=my_account@gmail.com

意思就是根本不用認證… (暈倒)

當你想看使用條款，回到官網 https://stackdock.com/ 上發現沒有使用條款？另外在母站 http://copper.io/ 也沒有？

再來收費方式也不清楚，只說了 USD$5/month，但如果以 Docker 的性質，開一次就收 USD$5，那麼就太鳥蛋了。但也沒有講是按照「小時」收費，還是按照「日」收費…

登入後 UI 動線上卡卡的 (速度也不太快，不過應該跟放在德國有關)，如果你建立 Deck 時 (像是樣板) 沒有開 Instance，你是沒辦法用儲存好的 Deck 開 Instance 的… (會 failed，然後只有一個「read timeout reached」的錯誤訊息…)

你只有在建立時選擇「Save & Distill Drop」才有機會建立起來 (不過還是有可能會失敗)。

如果想要改密碼而點選上方的 Profile 時，發現被導到 sso.copper.io，而 sso.copper.io 是沒有 HTTPS 的，而且修改密碼時不需要輸入原密碼？(那你本站用 HTTPS 幹嘛啊？更該保護的不保護是怎樣？)

然後在 sso.copper.io 按下 logout 要二十秒… 然後出現白頁… -_-

最後，在測完後，我找不到地方 cancel 信用卡…

這家公司有滿滿的問題…

↧

Twitter 也要上 PFS 了…

November 23, 2013, 11:20 am

≫ Next: GitHub 的 SSL (HTTPS) 也支援 PFS 與 AE 了…

≪ Previous: 提供 Docker 服務的 Stackdock… (不要用！)

Twitter 宣佈他們的 HTTPS 連線要上 PFS (Perfect Forward Secrecy) 了：「Forward Secrecy at Twitter」。

回頭查了 F5 要到哪個版本才支援 PFS，看起來要 11.2.1 之後的版本有支援… (出自「BIG-IP LTM and TMOS 11.3.0」這份文)

目前有一組已經是 11.2.1 之後的版本，這樣看起來好像也可以開看看？

↧

GitHub 的 SSL (HTTPS) 也支援 PFS 與 AE 了…

January 1, 2014, 6:29 am

≫ Next: AWS ELB 加強安全性…

≪ Previous: Twitter 也要上 PFS 了…

GitHub 在 2013 年底的公告：「Introducing Forward Secrecy and Authenticated Encryption Ciphers」。

愈來愈多服務升級 & 調整 SSL (HTTPS) 的設定，支援 PFS (Perfect Forward Secrecy) 與 AE (Authenticated Encryption)。

PFS 要預防的事情我可以理解，但對 AE 的必要性不熟啊… 再去看看整個理論基礎與目的好了…

↧

AWS ELB 加強安全性…

February 20, 2014, 10:28 am

≫ Next: HTTPS 頁面上的隱私問題

≪ Previous: GitHub 的 SSL (HTTPS) 也支援 PFS 與 AE 了…

AWS ELB 加強對 SSL 安全性的功能：「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy)，愈大多數的實做相同，是使用 ECDH。

第二個是 Server Order Preference，由 server 這邊決定最終的 cipher。

最重要的是第三個，也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01，把上面兩個都設進去了。

這次的升級是對安全性的提昇…

↧

HTTPS 頁面上的隱私問題

March 8, 2014, 1:26 am

≫ Next: 如何安全下載軟體…

≪ Previous: AWS ELB 加強安全性…

The Register 的「Even HTTPS can leak your PRIVATE browsing」這篇引用了「I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis」這篇論文。

這篇論文說明，當 ISP 有能力分析所有流量，即使你全部都使用 HTTPS 時，論文裡的方式可以對某些極為敏感的資訊達到 89% 的辨識率：

Our attack identifies individual pages in the same website with 89% accuracy, exposing personal details including medical conditions, financial and legal affairs and sexual orientation.

這是因為 HTTPS 設計上是保護密碼、session key 這類技術上的「機密資訊」。而這個特點只能增加對隱私的保護，無法 100% 保護。

就算不看論文用了哪些資訊與方法，這個領域有很多可以分析的：很直覺就可以想到 ISP 可以看到 Destination IP 資訊，藉以「猜測」是哪個 domain，而 DNS query 資訊也是有幫助的。再來是 HTTP request 的 pattern (像是順序、大小) 再加上對網站結構的了解，也可以分析出不少東西。

如果可以再分析主流瀏覽器、作業系統以及 NAT box 的實做，還可以透過 TCP 的封包再推敲的更細緻。

整套系統利用統計模型架構好後，在 ISP 端大量分析，看起來就是 NSA 擅長的業務？