Home » Posts tagged "https" (Page 16)

AWS ELB 加強安全性...

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,把上面兩個都設進去了。

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

提供 Docker 服務的 Stackdock... (不要用!)

先講結論,不要用,甚至連 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 信用卡...

這家公司有滿滿的問題...

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

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

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


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

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

新的 HTTPS 攻擊:BREACH Compression Attack

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

四千次就搞定了... 太!歡!樂!了!

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

加快 SSL 加解密速度...

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

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

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

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

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

維基百科在官方的 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,接下來應該都會被修正...

Archives