廣告走 HTTP 而且還帶了一堆敏感資訊，算是最近討論蠻熱烈的問題：「Leaking ads」。
而且還分析找出有哪些是超大的廣告 unencrypted domain，像是這樣：
不過裡面一堆都不熟悉的廣告業者，反倒是聯想的網域被抓出來了：
不過行動裝置上能控制的東西太少了... 裝廣告阻擋程式比較實際，iOS 上不 JB 應該是只有 VPN 的方案，而 Android 上的方案應該就比較多了，除了 VPN 以外有 /etc/hosts 甚至是 firewall solution。
Category: Security
Google Chrome 67 將可以在 DevTools 裡看到 SCT 的內容
在 Twitter 上看到 Google Chrome 67 (下一個版本) 的 DevTools 將會顯示憑證上的 Certificate Transparency 資訊：
In Chrome 67 the Security panel now provides certificate transparency info.https://t.co/JfV4IOrsmW pic.twitter.com/EbArEUv4MI
— Chrome DevTools (@ChromeDevTools) April 18, 2018
現在要看這個資訊比較麻煩，之後可以在瀏覽器裡直接讀就會簡單一些了...
話說回來，Let's Encrypt 上個月也支援 SCT 了：「Engineering deep dive: Encoding of SCTs in certificates」，不過目前只能先用 command line 工具看... 我拉了 Let's Encrypt 官方網站的 certificate 可以看到 (Let's Encrypt 那篇文章裡的範例)，但我自己 blog 的 certificate (序號 04ef0022ed7d5417f1ccbc011acf7fea9830) 看起來是在 Let's Encrypt 支援 SCT 之前申請的，沒看到 SCT 資訊... 要等下一次的 renew 了。
nginx 透過 libnginx-mod-http-auth-pam + libpam-ldap 串起 LDAP
如果 nginx 想接 LDAP 認證，網路上找到的資料主要都是透過 nginx 的模組直接支援，但這需要自己 compile 一個出來 (因為內建的好像都沒支援)，對於後續維護不太方便，就懶了... 後來研究出來的方法是 nginx 接 PAM，再用 PAM 接上 LDAP，這些都有現成套件可以一路串起來。
首先是 nginx 要裝 PPA 版 (像是「NGINX Stable : “Nginx” team」這個版本)，裡面的 nginx-full 會包括 libnginx-mod-http-auth-pam，接下來是安裝 libpam-ldap，這樣套件就裝好啦...
設定的部份，nginx 內這樣設：
location ~ /test {
auth_pam "Secure Zone";
auth_pam_service_name "nginx-ldap";
}然後 /etc/pam.d/nginx-ldap 裡面掛上 LDAP 就可以了：
auth required pam_ldap.so account required pam_ldap.so
重點在於 /etc/ldap.conf 內的設定，我是只 base dc=example,dc=com (base 是什麼) 與 uri ldap:/// (LDAP 伺服器在哪)，其他都註解掉。
這樣是比較麻煩沒錯，不過軟體其他人都包好了，這樣反而省了維護軟體的功夫...
Cloudflare 推出 Spectrum：65535 個 TCP Port 都可以轉的 Proxy...
Cloudflare 推出了 Spectrum，文章標題提到的 65533 應該是指 80 & 443 以外其他的 port：「Introducing Spectrum: Extending Cloudflare To 65,533 More Ports」。
然後因為 TCP proxy 不像 HTTP proxy 與 WebSocket proxy 可以靠 Host header 資訊判斷，在 TCP proxy 需要獨占 IP address 使用 (i.e. 一個 IP address 只能給一個客戶用)，而因為 IPv4 address 不夠的關係，這個功能只開放給 Enterprise 客戶用：
Today we are introducing Spectrum, which brings Cloudflare’s security and acceleration to the whole spectrum of TCP ports and protocols for our Enterprise customers.
雖然現在限定在 Enterprise 客戶，但 Cloudflare 還是希望看看有沒有其他想法，目前提出來的選項包括了開放 IPv6 address 給所有人用，或是變成獨立付費項目：
Why just Enterprise? While HTTP can use the Host header to identify services, TCP relies on each service having a unique IP address in order to identify it. Since IPv4 addresses are endangered, it’s quite expensive for us to delegate an IP per application and we needed to limit use. We’re actively thinking about ways to bring Spectrum to everyone. One idea is to offer IPv6-only Spectrum to non-Enterprise customers. Another idea is let anyone use Spectrum but pay for the IPv4 address. We’re not sure yet, but if you prefer one to the other, feel free to comment and let us know.
類似的產品應該是 clean pipe 類的服務，但一般 clean pipe 是透過 routing 重導清洗流量，而非像 Cloudflare 這樣設計... 不知道後續會有什麼樣的變化。
HTTPS Everywhere 改變更新 Ruleset 機制，變成定時更新...
HTTPS Everywhere 是我很喜歡的一個套件，裡面有 Ruleset，會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS，這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況，以及網站本身有支援 HTTPS 但沒有設定 HSTS 時，在網址列上誤打 HTTP 版本的情況。
先前版本的 Ruleset 是隨著軟體更新時，包在軟體內一起更新。這樣的缺點是更新速度比較慢，但好處是不需要伺服器端，而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本，以加速 Ruleset 更新的速度：「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。
We've modified the extension to periodically check in with EFF to see if a new list is available.
而頻寬的部份由 Fastly 贊助：
If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!
如果對這點有疑慮的，也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。
TWCA 不在 Java Trust Store 裡...
在 SSL Labs 上翻資料的時候發現看到台灣有些網站的 SSL 憑證在 Java Trust Store 內是不會取得信任授權的，但其他的都支援，像是這樣：
翻了幾個後發現都是 TWCA 的，在其他家都是這樣授權出來的 (Mozilla/Apple/Android/Windows)：(TWCA Root Certification Authority -> ) TWCA Global Root CA -> TWCA Secure SSL Certification Authority -> Final，也就是 TWCA 的兩個 Root CA 都在 trust store 內，走任何一條授權都可以拉出來。
印象中之前應該都是支援的... 先前是 cross sign 嗎？@_@
Cloudflare 推出 Argo Tunnel
Cloudflare 推出了 Argo Tunnel，可以將內部網路與 Cloudflare 之間打通：「Argo Tunnel: A Private Link to the Public Internet」。
Cloudflare 在去年推出了 Wrap (可以參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」這篇)，這次其實只是改名：
During the beta period, Argo Tunnel went under a different name: Warp. While we liked Warp as a name, as soon as we realized that it made sense to bundle Warp with Argo, we wanted it to be under the Argo product name. Plus, a tunnel is what the product is so it's more descriptive.
看起來沒有什麼新的玩意... 純粹改名字 :o
AWS 推出 AWS Secrets Manager
AWS 推出 AWS Secrets Manager，你可以把各種帳號密碼丟進去讓系統管理，另外內建 rotate 的功能，針對 AWS 支援的服務可以無縫更換密碼 (目前看起來是 RDS)，或是透過 Lambda 換：「AWS Secrets Manager: Store, Distribute, and Rotate Credentials Securely」。
是個整合性的服務，之前就可以做 (用 Lambda 定時跑)，現在則是包裝起來針對 AWS 自家的服務弄的更簡單。
AWS Certificate Manager 提供 Private CA
AWS Certificate Manager 推出了 Private CA，讓使用者可以在不接觸到 CA 的 Private Key 就可以操作 CA 行為：「AWS Certificate Manager Launches Private Certificate Authority」。
支援的演算法除了標準的 RSA 外，還包括了 ECC 的 (雖然是 NIST 的 P-256 與 P-384)：
然後直接內建了 CRL 服務，透過 Amazon S3 做：
要注意的是價錢有點奇怪：
Private CAs cost $400 per month (prorated) for each private CA. You are not charged for certificates created and maintained in ACM but you are charged for certificates where you have access to the private key (exported or created outside of ACM). The pricing per certificate is tiered starting at $0.75 per certificate for the first 1000 certificates and going down to $0.001 per certificate after 10,000 certificates.
中間省掉 1k 到 10k 是 USD$0.35/cert (可以在 pricing 頁面看到)。
不管如何，這計價模式有點怪怪的... 收了固定的費用，每個 certificate 的費用要到 USD$0.75，這看不太懂。另外是 10k 後的單價明顯與前面比例不太合。
看起來像是跟某個 partner 合作談出來奇怪的 pricing model，但也不知道是哪家... :o
Cloudflare 推出在 HTTPS 下的壓縮機制
在 TLS (HTTPS) 環境下基本上都不能開壓縮，主要是為了避免 secret token 會因為 dictionary 的可預測性而被取出，像是 CRIME、BREACH、TIME、HEIST (沒完結過...)，而因為全面關閉壓縮，對於效能的影響很大。
而 Cloudflare 就試著去找方法，是否可以維持壓縮，但又不會洩漏 secret token 的方式，於是就有了這篇：「A Solution to Compression Oracles on the Web」。
重點在於 Our Solution 這段的開頭：
We decided to use selective compression, compressing only non-secret parts of a page, in order to stop the extraction of secret information from a page.
透過 regex 判斷那些東西屬於 secret token，然後對這些資料例外處理不要壓縮，而其他的部份就可以維持壓縮。這樣傳輸量仍然可以大幅下降，但不透漏 secret token。然後因為這個想法其實很特別，沒有被實證過，所以成立了 Challenge Site 讓大家打：
We have set up the challenge website compression.website with protection, and a clone of the site compression.website/unsafe without it. The page is a simple form with a per-client CSRF designed to emulate common CSRF protection. Using the example attack presented with the library we have shown that we are able to extract the CSRF from the size of request responses in the unprotected variant but we have not been able to extract it on the protected site. We welcome attempts to extract the CSRF without access to the unencrypted response.
這個方向如果可行的話，應該會有人發展一些標準讓 compression algorithm 不用猜哪些是 secret token，這樣一來就更能確保因為漏判而造成的 leaking...