↧
推廣 SSL 的海報
↧
如果新的 TLD 都強制要求使用 HTTPS (HSTS)？
Google 的 Adam 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 看起來會是可能會參與的單位？
Related Posts:
↧
↧
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 秒。
Related Posts:
↧
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。
Related Posts:
↧
介紹 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 裡面查詢與自己有關的資訊)
到這邊應該有個獨立的環境可以玩了…
Related Posts:
↧
↧
自動將流量轉到 Tor 上面的硬體
在 Zite 上看到「Tiny Anonabox to offer online anonymity through Tor」這篇文章。
在 Kickstarter 上可以看到更完整的資料：「anonabox : a Tor hardware router」。
可以想像出來大概是什麼技術組合起來。分別處理 DNS query 以及實際連線的部份應該就可以搞定很多應用了。
不知道隱私的部份可以做到什麼程度，畢竟在 Tor 上面仍然有監聽的風險，如果讓 HTTP traffic 在上面跑的話等於是裸奔…
Related Posts:
↧
把 blog.gslin.org 上 HTTPS
到 Namecheap 上買了 SSL certificate 後裝一裝設一設，再加上 301 Redirect 與 HSTS，總算是搞定了：
不過 IE6 就確定陣亡了：
Related Posts:
↧
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 踢出清單也是比較安全啦...
↧
聯想在筆電上安裝 Adware
Update：後續參考「聯想對 Superfish 的新聞稿、反安裝說明，以及影響的機器列表」。
今天的大條新聞，不少傳統媒體也都有報導：
- Lenovo taken to task over 'malicious' adware
- How Lenovo's Superfish 'Malware' Works And What You Can Do To Kill It
- Lenovo caught installing adware on new computers
另外「Lenovo installs adware on customer laptops and compromises ALL SSL.」這篇講得還蠻完整的。
這次的 adware 還被更歸類到 malware 就是因為他會在本機上安裝自己的 CA root，解開所有的 HTTPS traffic 並且插入廣告。而這包括了銀行網站、醫療網站、各種極度隱私的加密服務。
Is Superfish malware?
Lenovo won’t want anyone to call it that, but Superfish has been described as a piece of malware, or an adware pusher, that the Chinese firm pre-installs on consumer laptops.
在「Extracting the SuperFish certificate」這邊有告訴你方法，教你取得 SuperFish 的 protected private key & key password。不過不確定每一台機器是不是都一樣，作者把取出來的 pem 檔放在「test.pem」這邊。
↧
↧
CloudFlare 宣佈停用 RC4，並且支援 ChaCha20+Poly1305
CloudFlare 同時宣佈了停用 RC4 與支援 ChaCha20+Poly1305 的計畫：「End of the road for RC4」、「Do the ChaCha: better mobile performance with cryptography」。
2014 年年初的時候，CloudFlare 先把 RC4 從 TLS 1.1+ 的連線拿掉，而 2014 年五月時，再把 RC4 搬到 cipherlist 裡優先權最低的，成功的讓 99.9991% 的 request 改用 AES 與 3DES (大約五個 9 )：
而九個月後的現在，CloudFlare 上 RC4 使用的比率則是降到了 0.000002%，反過來說也就是 99.999998% 的等級 (七個 9)，也讓 CloudFlare 決定直接停用掉 RC4。
另外一個重大的新進展則是 ChaCha20+Poly1305，兩個都是 Daniel J. Bernstein 的作品。其中 ChaCha20 是 stream cipher，Poly1305 是 MAC。
由於 RC4 已經不夠安全，在行動平台上要夠安全必須使用 AES，但 AES 在 ARM 上面還沒有普及：在 Nexus 6 用的 ARMv7 不支援，是透過 Qualcomm Snapdragon 805 的加掛模組做的，而在低階手機支援度就更不用說了。
Google 大力推動 ChaCha20+Poly1305 的目的，是為了在行動平台上找到一個與 RC4 可以匹敵的速度，而且有著可以超越 AES-GCM 安全性的 cipher+MAC。
在 CloudFlare 採用 ChaCha20+Poly1305 前，Google 是唯一一個在 HTTPS 上大幅採用的單位，而瀏覽器的部份也只有 Google Chrome 有支援。雖然 Firefox 一直有喊著要支援，但這是個雞生蛋蛋生雞的問題，可以看到進度不怎麼快 (Bug 917571 - Support ChaCha20+Poly1305 cipher suites)。
CloudFlare 支援之後，使用 ChaCha20+Poly1305 的 pool 瞬間大了不少。可以看到一上線的使用率不算低，瞬間就有 10% 了：
希望可以推動 Firefox 快一點支援... (這是養大 pool 的下一步)
↧
Comodo 的 PrivDog 更厲害：直接關掉 CA Certificate 檢查
感覺接下來的整個月會拿有無窮無盡的 Superfish-like 新聞，下次如果出現 NSA 或是 GCHQ 已經在用這些漏洞的話也不太意外就是了：「Adware Privdog worse than Superfish」。
PrivDog 是 Comodo 發行的 adware，比起 Superfish 更厲害，直接把 CA Certificate 的檢查關掉：
It will turn your Browser into one that just accepts every HTTPS certificate out there, whether it's been signed by a certificate authority or not.
而 Comodo 是發行 SSL certificate 的公司，很多便宜的 SSL certificate 都是由他們家發出來的... (包括我的 blog)
↧
Firefox 成為第一個預設啟用 HTTP/2 的主流瀏覽器
在 Firefox 36 的 Release Notes 內宣佈預設啟用 HTTP/2：
Support for the full HTTP/2 protocol. HTTP/2 enables a faster, more scalable, and more responsive web.
另外 Firefox 36 也拔除 RC4：
No longer accept insecure RC4 ciphers whenever possible
接下來應該是 Google Chrome 預設啟用，以及 nginx 的 server implementation...
↧
CloudFlare 的 HTTPS 支援 HSTS 設定
CloudFlare 的 HTTPS 支援 HSTS：「Enforce Web Policy with HTTP Strict Transport Security (HSTS)」。
目前可以設 max-age 與 includeSubDomains。至於 preload 還在規劃。不算複雜的功能 (加上 HTTP header)，不過對於安全性的幫助很大。
不過 origin 好像也可以送，不知道 CloudFlare 會不會濾掉...
↧
↧
CVE-2015-0204：OpenSSL 的弱點攻擊 (Android 與 iOS)
CVE-2015-0204 的說明：
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k allows remote SSL servers to conduct RSA-to-EXPORT_RSA downgrade attacks and facilitate brute-force decryption by offering a weak ephemeral RSA key in a noncompliant role.
本來是被 OpenSSL 標成低危險性 (出自 secadv_20150108.txt)：
RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
Severity: Low
不過新的攻擊利用這個弱點放大，叫做「FREAK Attack」，可以強制使用 RSA_EXPORT suite 所列的 cipher，而這些 cipher 通常長度都不夠，於是就可以解：
A connection is vulnerable if the server accepts RSA_EXPORT cipher suites and the client either offers an RSA_EXPORT suite or is using a version of OpenSSL that is vulnerable to CVE-2015-0204. Vulnerable clients include many Google and Apple devices (which use unpatched OpenSSL), a large number of embedded systems, and many other software products that use TLS behind the scenes without disabling the vulnerable cryptographic suites.
影響的範圍主要是支援 RSA_EXPORT suite 的 server：
Websites that support RSA export cipher suites (e.g., TLS_RSA_EXPORT_WITH_DES40_CBC_SHA) are at risk to having HTTPS connections intercepted.
應該是把 !EXPORT 設上去就可以解掉，不過還是花點時間 review，把可以關掉的舊技術都拔掉會比較好。
↧
Mozilla 對非 HTTPS 站台的抵制
Mozilla Security Blog 上 Richard Barnes (Firefox Security Lead) 宣佈對非 HTTPS 站台的抵制政策。規劃在之後的 Firefox 新功能限定在 HTTPS 網站上：「Deprecating Non-Secure HTTP」。
詳細的日期還沒有確定，但預定分成兩個階段：
- Setting a date after which all new features will be available only to secure websites
- Gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.
在「Deprecating Non-Secure HTTP (PDF)」這邊有 FAQ 可以參考。
↧
CloudFlare 對 Go 上面加解密系統的改善
CloudFlare 發佈了自己版本的 Go，修改了其中的 crypto subsystem：「Go crypto: bridging the performance gap」。
文章花了不少篇幅介紹 AEAD (Authenticated Encryption with Associated Data)，而目前 CloudFlare 支援的是 AES-GCM 與 ChaCha20-Poly1305，也是兩大主流，分別佔了 60% 與 10% 的 HTTPS 流量：
As such today more than 60% of our client facing traffic is encrypted with AES-GCM, and about 10% is encrypted with ChaCha20-Poly1305.
CloudFlare 提供的改進使得速度快很多，並且有考慮到 side-channel attack 的問題：
Both implementations are constant-time and side-channel protected.
CloudFlare Go 1.4.2 Speedup AES-128-GCM 2,138.4 MB/sec 91.4 MB/sec 23.4X P256 operations: Base Multiply 26,249 ns/op 737,363 ns/op 28.1X Multiply/ECDH comp 110,003 ns/op 1,995,365 ns/op 18.1X Generate Key/ECDH gen 31,824 ns/op 753,174 ns/op 23.7X ECDSA Sign 48,741 ns/op 1,015,006 ns/op 20.8X ECDSA Verify 146,991 ns/op 3,086,282 ns/op 21.0X RSA2048: Sign 3,733,747 ns/op 7,979,705 ns/op 2.1X Sign 3-prime 1,973,009 ns/op 5,035,561 ns/op 2.6X
AES-GCM 與 EC 的改善主要是利用 CPU 指令集加速：
[T]herefore we created assembly implementations of Elliptic Curves and AES-GCM for Go on the amd64 architecture, supporting the AES and CLMUL NI to bring performance up to par with the OpenSSL implementation we use for Universal SSL.
不過 RSA 的部份雖然幅度也不小 (比起 AES 與 EC 的部份是不大，不過純就數字來看，快了一倍多也不少)，不過沒提到怎麼改善，只稍微帶過：
In addition the fork includes small improvements to Go's RSA implementation.
↧
GitHub 成立日本辦公室
GitHub 宣佈成立日本辦公室：「Announcing GitHub Japan」，日本的官網在「GitHub Japan」這邊。比較意外的是日本官網是不支援 HTTPS 的。
辦公室在東京都港區 (PMO 芝大門 7F、東京都港区芝大門 1-10-18)，也許下次去的時候去樓下看看...
↧
↧
Let's Encrypt 建立 Root Certificate 與 Intermediate Certificate
Let's Encrypt 的 Root Certificate 與 Intermediate Certificate 建出來了：「Let's Encrypt Root and Intermediate Certificates」。
Intermediate Certificate 除了會讓自己的 Root Certificate 簽名外，也會讓 IdenTrust 的 DST Root CA X3 簽 (目前各大瀏覽器與 SSL library 都有支援)。
All ISRG keys are currently RSA keys. We are planning to generate ECDSA keys later this year.
↧
Wikimedia (包括維基百科) 推出 HSTS (強制使用 HTTPS)
Wikimeda 宣佈所有旗下的網站都會啟用 HTTPS 與 HSTS：「Securing access to Wikimedia sites with HTTPS」。
在這之前，使用者可以用 EFF 的 HTTPS Everywhere 強制使用 HTTPS (在 Firefox 與 Google Chrome 都有上架)，而這次則是全面強制使用了。
愈來愈多人使用 HTTPS 來保護隱私後 (而不僅僅是保護機密資料)，接下來的問題就是要想辦法在 DNS 上保護了。也就是可以利用 DNS query pattern 知道你在看哪種 (或是哪一個) 頁面。
↧
微軟讓 Windows 7 與 Windows 8.1 上的 IE11 支援 HSTS
本來只有 Windows 10 的 IE11 有支援 HSTS，而前幾天的更新則是讓 Windows 7 與 Windows 8.1 的 IE11 也支援了：「HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7」。
With today’s monthly security updates (KB 3058515), we’re bringing the protections offered by HSTS to Internet Explorer 11 on Windows 8.1 and Windows 7. HSTS is also available in both Internet Explorer 11 and Microsoft Edge on Windows 10.
這次的更新讓所有主流瀏覽器都支援 HSTS 了，再加上前一篇「Wikimedia (包括維基百科) 推出 HSTS (強制使用 HTTPS)」提到的，愈來愈多人用啦...
然後據 zonble 說，iOS 9 有些東西會 HTTPS only (預設值)，該回頭去催自己人支援了 :o
↧
![[SweetSub&LoliHouse] 小书痴的下克上 领主的养女 / Honzuki no Gekokujou S04 - 05 [WebRip...](http://files.seeusercontent.com/2026/04/08/dRa8/Honzuki.jpg)
