Home » Posts tagged "https" (Page 16)

GitHub 預定再兩個星期後廢止 HTTPS 連線的 RC4

GitHub 在「Improving GitHub's SSL setup」這邊開頭就提到要拔掉 RC4

To keep GitHub as secure as possible for every user, we will remove RC4 support in our SSL configuration on github.com and in the GitHub API on January 5th 2015.

看了一下日曆,算一算其實意思就是「放完假的星期一我們就來拔 RC4」XDDD

雖然 GitHub 的人說了 Windows XP + IE8 會沒辦法用,不過翻了「Qualys SSL Labs - Projects / User Agent Capabilities: IE 8 / XP」這頁,手動打開 TLS 1.0 後應該還有 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) 這兩個用 3DES 的 cipher 可以掙扎才對?

不過看 GitHub 目前的 HTTPS 設定,看起來沒打算支援這兩個:「Qualys SSL Labs - Projects / SSL Server Test / github.com」以及「Qualys SSL Labs - Projects / SSL Server Test / github.com」。

不過順便把 3DES 踢出清單也是比較安全啦...

自動將流量轉到 Tor 上面的硬體

Zite 上看到「Tiny Anonabox to offer online anonymity through Tor」這篇文章。

Kickstarter 上可以看到更完整的資料:「anonabox : a Tor hardware router」。

可以想像出來大概是什麼技術組合起來。分別處理 DNS query 以及實際連線的部份應該就可以搞定很多應用了。

不知道隱私的部份可以做到什麼程度,畢竟在 Tor 上面仍然有監聽的風險,如果讓 HTTP traffic 在上面跑的話等於是裸奔...

介紹 Tails:Privacy for anyone anywhere

來介紹 Tails 這個以隱私為重點而設計出來的環境。

Tails 是一個獨立的作業環境,以 Debian 打造,並且使用 Tor 保護隱私,另外透過調整過的 Firefox (在 Debian 裡叫做 Iceweasel) 確保連線的安全。

設計上,整個系統利用 iptables 保護,只允許 Tor 的流量連出去,而其他的程式都是透過環境變數與 proxy 設定連外,所以用 curl (透過環境變數設定 proxy) 可以通,但用 nc 直接連卻不會通:

要注意的是,由於這是使用 Tor 作為隱私保護,所以非 HTTPS 的連線都應該被視為會被竊聽或是加料的環境,請避免使用 Tails 連上 HTTP 網站。

Tails 可以在網站上可以下載 ISO image 安裝,下載完後請務必確認 SHA256 是否正確 (網站上有 SHA256 的值,加上 HTTPS 的網址,直接看網站上的這個 SHA256 值應該還算安全)。

拿到 ISO image 後可以選擇燒成光碟後開機執行,這是官方比較推薦的方法。如果是使用虛擬機執行時,需要確認母虛擬機的主體 (Host) 是安全的。

這邊以 VirtualBox 為例子,選擇 Debian 32bits 然後直接把 ISO image 掛上去:

使用虛擬機時,記憶體開個 1GB 應該是夠用 (我是開 2GB,因為沒有掛硬碟當 crypto swap,記憶體大理論上會順一點),看個人環境而自己選擇。開機後會出現:

放著開進去或是選 Live 進去都可以,接下來會出現登入畫面:

第一次玩可以直接用預設值選 Login 就好。登入進去後可以看到這個畫面:

然後過一陣子後右上角會出現黃色的洋蔥 icon,表示已經連上 Tor:

再等一陣子後右上角的洋蔥就會變成綠色,表示已經順利連上:

瀏覽器開起來預設會連到 Tails 的官方網站:

接下來就可以開始做事了:(這是不良示範,你不應該在匿名 channel 裡面查詢與自己有關的資訊)

到這邊應該有個獨立的環境可以玩了...

Firefox 也要支援 Public Key Pinning Extension for HTTP

在「Mozilla to Support Key Pinning in Firefox 32」看到的新聞,目前的標準還是 draft:「Public Key Pinning Extension for HTTP」。

被簡稱 PKP 與 HPKP:(一般比較常用前者)

We call this "public key pinning" (PKP); in particular, this document describes HTTP-based public key pinning (HPKP).

可以看到 Google Chrome 程式碼裡面是怎麼使用 PKP 技術預載的:「/trunk/src/net/http/transport_security_state_static.json」。

目前 Google Chrome 使用的方式是限制 Google 的網域只能由某些特定的 CA 才能簽,這樣可以降低其他 CA 簽出高經濟價值的 SSL certificate 的效益。

Mozilla 的 wiki 上面可以看到對應的條目:「SecurityEngineering/Public Key Pinning」,目前 Firefox 的版本是 31,也就是從下一個版本就支援了。

第一波的 32 版會支援 Mozilla 自己的某些站台,以及一些 Twitter 的網域。

第二波的 33 版會把 Twitter 的部份擴充到 *.twitter.com,另外還會支援 Google 所擁有的網域。

第三波的 34 版會支援 Firefox account (*.accounts.firefox.com)、Tor 以及 Dropbox

AWS 的 ELB 可以自訂 HTTP/HTTPS Timeout 時間了

Elastic Load Balancing 之前的 timeout 時間是預設值 60 秒,現在可以自訂時間了:「Elastic Load Balancing Connection Timeout Management」。

文章裡有提到好處:

Some applications can benefit from a longer timeout because they create a connection and leave it open for polling or extended sessions. Other applications tend to have short, non- recurring requests to AWS and the open connection will hardly ever end up being reused.

目前可以設定 1 秒到 3600 秒,預設值是 60 秒。

如果新的 TLD 都強制要求使用 HTTPS (HSTS)?

GoogleAdam Langley 在他的 blog 上提出了一個很特別的想法,是不是把現在這些新增加的 TLD 都預先在瀏覽器裡納入 HSTS:「HSTS for new TLDs」。

Here's an idea: why not ask me to set HSTS for the entire TLD? That way, every single site runs over HTTPS, always. It strikes me that could be useful if you're trying to build trust with users unfamiliar with the zoo of new domains.

只要任何一個比較大的 browser 這樣做,其實就相當於強制要求?看文章內的語氣,Firefox + Google Chrome 看起來會是可能會參與的單位?

如何安全下載軟體...

由於從網路上下載軟體回自己電腦跑是種「引狼入室」的行為,如何用合理的方式驗證下載回來的軟體,會是對資安敏感的人的重要課題。

然後就看到一篇純粹抱怨文,以 PuTTY 為例,要肯定確定抓到的軟體是沒被「加料」過的卻是困難重重:「Downloading Software Safely Is Nearly Impossible」。

PuTTY 算是資訊安全類的軟體,但卻發現難以找到合理的方式確認 XDDD

首先是要先判斷「哪個站台是正確的官方站台」時,卻發現 putty.org 這個網域不是原作者 Simon Tatham 擁有,而即使是公認的官方網站 www.chiark.greenend.org.uk 的 greenend.org.uk 這個網域,也不是原作者擁有。

然後 www.chiark.greenend.org.uk 沒有提供 HTTPS,所以下載下來後還要想辦法確認沒被動手繳過。而作者的 RSA public key 放在 earth.li 網域上,同樣的這也不是作者擁有的網域,而且也遇到同樣問題:public key 的下載也不支援 HTTPS。

然後去 MIT 上的 PGP key server 翻也沒翻到,然後文章作者就崩潰自暴自棄直接執行下去了 XDDD

PuTTY 的這一串過程好像從以前就沒改善... XD

HTTPS 頁面上的隱私問題

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 擅長的業務?

Archives