↧
nginx 1.13 將支援 TLSv1.3
↧
nginx 記錄 TLS 連線資訊
想要在 nginx 的 access log 裡面記錄使用者在 HTTPS 連線使用的 TLS protocol 與 cipher。
在「How can I let nginx log the used SSL/TLS protocol and ciphersuite?」這邊有提到方向是 $ssl_protocol 與 $ssl_cipher (出自「Module ngx_http_ssl_module」內的 Embedded Variables 章節)。
他的方式是在前面就插入 protocol，但我希望前面的欄位保持不變，把 protocol & cipher 放到後面，所以我就加了一個 /etc/nginx/conf.d/combined_ssl.conf (這邊我用 ondrej 的 PPA，在設定檔裡會撈 /etc/nginx/conf.d/ 下的設定，不確定其他的情況如何)：
# log_format combined_ssl '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_protocol/$ssl_cipher';
然後本來用 combined 的 HTTPS 設定就改成 combined_ssl。
來放一陣子再來分析，然後想看看要怎麼調整 cipher...
↧
↧
Let's Encrypt 發出第一億個 SSL Certificate
Let's Encrypt 發文慶祝發出了一億個 SSL Certificate：「Milestone: 100 Million Certificates Issued」。
雖然是 Firefox 的資料，但還是很明顯可以看出來全世界都在往 HTTPS 走：
不知道會用多少時間衝到十億...
↧
Alexa Top 1M 網站使用 HTTPS 的改善
Mozilla 觀測 Alexa Top 1M 網站，對 HTTPS 使用情況的分析：「Analysis of the Alexa Top 1M sites」。
可以看到比較明顯的是 HTTPS 以及 HTTP → HTTPS Redirection 這兩塊：
不過用 Alexa 的資料有種怪怪的感覺啊... 在討論 HTTPS (有點在推廣的感覺)，但 Alexa 的網站現在是做反過來的 HTTPS → HTTP Redirection XDDD
↧
Let's Encrypt 決定要規劃 Wildcard SSL Certificate 了
Let's Encrypt 把時間表喊出來了，預定在 2018 年年初開放使用：「Wildcard Certificates Coming January 2018」。
Wildcard SSL Certificate 會需要走新的 ACME v2 協定認證：
Wildcard certificates will be offered free of charge via our upcoming ACME v2 API endpoint. We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time.
跟前陣子提到的「ACME v2 API Endpoint Coming January 2018」是相同的時間。
這好讚...
↧
↧
Google Chrome 對 WoSign 與 StartCom 的白名單要完全移除了
在 Twitter 上看到的：
Chrome will fully distrust WoSign and StartCom in Chrome 61; beta in July, stable in September. https://t.co/5fnda6aUQw
— Ivan Ristic (@ivanristic) July 7, 2017
對 WoSign 與 StartCom 的移除會發生在 61 版，而依照「Final removal of trust in WoSign and StartCom Certificates」這邊的說明，stable 應該會在九月出 61 版而生效：
Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.
↧
Amazon Route 53 將會加緊支援 DNS CAA
看到 Amazon Route 53 要支援 DNS CAA 的消息：「Announcement: Announcement: CAA Record Support Coming Soon」。
裡面有提到 CA/Browser Forum 的決議，要求各瀏覽器支援 DNS CAA：
On March 8, 2017, the Certification Authority and Browser Forum (CA/Browser Forum) mandated that by September 8, 2017, CA’s are expected to check for the presence of a CAA DNS record and, if present, refuse issuance of certificates unless they find themselves on the whitelist <https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/>.
DNS CAA 可以設定哪些 SSL certificate 可以發出你的證書，除了自己以外，也可以讓第三者比較容易確認是否有誤發的行為：
We have seen a lot of interest in Amazon Route 53 support for Certification Authority Authorization (CAA) records, which let you control which certificate authorities (CA) can issue certificates for your domain name.
↧
Stripe 宣佈 TLS 1.0/1.1 的退場時間表
Stripe 宣佈了今年的 2/19 會停用測試環境的 TLS 1.0/1.1，並且在 6/13 全面停用：「Completing an upgrade to TLS 1.2」。
- Monday, February 19: All servers using older versions of TLS will be blocked from the Stripe API in test mode.
- Wednesday, June 13: All servers using older versions of TLS will be blocked from the Stripe API in live mode.
這喊好久了，總算是開槍了...
隔壁棚 PayPal 反而早就把 Sandbox 環境上 TLS 1.2-only 了，而六月底也會強制所有連線都必須是 TLS 1.2：「TLS 1.2 and HTTP/1.1 Upgrade - PayPal」。
↧
GitHub 停用過時加密演算法的計畫
先前有提到 GitHub 廢除 SSH 中的弱演算法 (參考「GitHub 明年關閉 SSH 上 SHA1 相關的 Kx (Key Exchange) 演算法」)，現在宣佈詳細作法了：「Weak cryptographic standards removal notice」。
包括 HTTPS 的 TLSv1/TLSv1.1 以及 SSH 的 diffie-hellman-group1-sha1/diffie-hellman-group14-sha1 都會被廢止。而作法跟其他家不太一樣：
- February 8, 2018 19:00 UTC (11:00 am PST): Disable deprecated algorithms for one hour
- February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms
先關閉一個小時讓沒看公告但是有注意到的人可以發現，然後過兩個禮拜後才完全關閉。跟其他家不太一樣的作法...
↧
↧
SSL Certificate 的認證方式限縮
在「Ballot 218 - Remove validation methods 1 and 5 - CAB Forum」看到「Ballot 218: Remove validation methods #1 and #5」這則議案以 78% 的同意票通過，限縮 SSL Certificate 的認證方式。眼睛瞄到中華電信投下反對票：
14 Yes votes: CFCA, Cisco, Comodo CA, D-TRUST, DigiCert, GDCA, GlobalSign, GoDaddy, Izenpe, Let’s Encrypt, Logius PKIoverheid, SSL.com, TrustCor, Trustwave
4 No votes: Buypass, Chunghwa Telecom, Entrust Datacard, SwissSign
4 Abstain: Actalis, Disig, HARICA, OATI
78% of voting CAs voted in favor
找了一下在 BR (Baseline Requirements) 的 3.2.2.4.1 與 3.2.2.4.5，其中前者是透過註冊商認證：
3.2.2.4.1 Validating the Applicant as a Domain Contact
Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.
後者是透過文件認證：
3.2.2.4.5 Domain Authorization Document
Confirming the Applicant's control over the FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document.
在想投下反對的原因，會不會是因為中華自己的 domain 應該都是透過後者方式發的？透過內部公文系統...
↧
GitHub 移除 HTTPS 中的 TLSv1/TLSv1.1，以及 SSH 中 SHA1 相關的協定
GitHub 完全移除掉 TLSv1/TLSv1.1 以及 SSH 中 SHA1 相關的協定了：「Weak cryptographic standards removed」。其中 TLSv1 與 TLSv1.1 的部份也可以從 SSL Report: github.com 這邊看到：
這是之前就預告的關閉，可以參考先前提到的文章：「GitHub 停用過時加密演算法的計畫」。
↧
Mozilla 對 Alexa Top 1M Sites 的分析
Mozilla 對 Alexa Top 1M Sites 偏安全面向的分析：「Analysis of the Alexa Top 1M Sites」。
對一般情況比較有用的應該是看絕對數字，也就是哪些功能是大家都優先採用了... 然後可以看出 HPKP 跟 SRI 果然是大家都懶得上的功能 (事倍功半 XDDD)。
另外也可以當作是安全性確認的 list，把 HTTP header 類的安全性設定都放上去了。
↧
今年十月 Firefox 將完全不信任 Symantec 簽出的 SSL Certificate
Mozilla 旗下的產品 (包括 Firefox) 將在今年十月對 Symantec 簽出的 SSL Certificate 終止信任：「Distrust of Symantec TLS Certificates」。
Mozilla 有把發生的事情都整理出來：「CA:Symantec Issues」，另外 Firefox 的動作分成三個階段，目前 stable 是 58，但 nightly 是 60 了：
- January 2018 (Firefox 58): Notices in the Browser Console warn about Symantec certificates issued before 2016-06-01, to encourage site owners to replace their TLS certificates.
- May 2018 (Firefox 60): Websites will show an untrusted connection error if they use a TLS certificate issued before 2016-06-01 that chains up to a Symantec root certificate.
- October 2018 (Firefox 63): Distrust of Symantec root certificates for website server TLS authentication.
去年 Google Chrome 就有先丟出對 Symantec CA 的計畫 (參考「Google Chrome 對 Symantec 全系列憑證的不信任計畫」這篇)，看起來 Mozilla 的計畫也差不多，但時間有些差異...
↧
↧
本來 Google Chrome 要繞過 HSTS 的 badidea 被換掉了...
先前在「在 Google Chrome 連上因 HSTS 而無法連線的網站」中提到的關鍵字 badidea 在 Google Chrome 65 發現沒用了，找了一下發現是被換掉了：「Chrome 65 replaces the "badidea" bypass keyword with "thisisunsafe"」，這 Reddit 的標題就說明了換成什麼了 XDDD
而且從 source code 裡面可以看到，本來是明碼的 badidea，改用 window.atob 來存了：「Diff - d8fc089b62cd4f8d907acff6fb3f5ff58f168697^! - chromium/src - Git at Google」。
anyway，要記其他的字串了 XDDD
↧
WebKit 對 HSTS Super Cookie 提出的改法
Twitter 上看到 WebKit 對 HSTS 所產生的 Super Cookie 提出的改善方案：
How WebKit crumbles the "Super Cookie". https://t.co/iwOpjM8p9f
— WebKit (@webkit) March 16, 2018
拿原文的例子來說明，先指定一個隨機數給 user，像是 8396804 (二進位是 100000000010000000000100)，所以就存取下面的網址：
https://bit02.example.com https://bit13.example.com https://bit23.example.com
在存取這些 HTTPS 網址時都會指定 HSTS，所以之後連到這三個網址的 HTTP request 就不會觸發到 HTTP 版本，會因為 HSTS 被轉到 HTTPS 版本。於是就可以用 32 個 HTTP request 測試 32bits 而判斷出身份。(當然你可以用更多)
WebKit 提出的改善方案大概有幾種，主要是就觀察到的現象來限制。
第一種解法「Mitigation 1: Limit HSTS State to the Hostname, or the Top Level Domain + 1」是因為會看到這樣的設計：
https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.example.com …etc...
https://bit00.example.com https://bit01.example.com https://bit02.example.com ...etc... https://bit64.example.com
所以提出的方案是只有目前網站的 domain 以及 top domain + 1 (像是 example.com) 可以被設定 HSTS：
Telemetry showed that attackers would set HSTS across a wide range of sub-domains at once. Because using HSTS in this way does not benefit legitimate use cases, but does facilitate tracking, we revised our network stack to only permit HSTS state to be set for the loaded hostname (e.g., “https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com”), or the Top Level Domain + 1 (TLD+1) (e.g., “https://example.com”).
但其實廣告主只需要註冊 32 domains (或是 64) 就可以避開這個問題。
第二種是「Mitigation 2: Ignore HSTS State for Subresource Requests to Blocked Domains」，如果在 HTTPS 頁面上，某個 domain 的 cookie 已經因為某些原因被阻擋 (像是手動設定)，那麼就忽略掉 HSTS 的設計：
We modified WebKit so that when an insecure third-party subresource load from a domain for which we block cookies (such as an invisible tracking pixel) had been upgraded to an authenticated connection because of dynamic HSTS, we ignore the HSTS upgrade request and just use the original URL. This causes HSTS super cookies to become a bit string consisting only of zeroes.
後面這點在現在因為 SEO 設計而使得各大網站都往 HTTPS 方向走，應該會有些幫助吧...
↧
Facebook 的 Certificate Transparency Monitoring 工具
前幾天找資料才發現原來 Facebook 很早就有提供 Certificate Transparency 相關的服務，可以用網域名稱搜尋查詢，甚至是訂閱：「Introducing our Certificate Transparency Monitoring tool」。
服務在「Certificate Transparency Monitoring - Facebook for Developers」這邊，搜尋與訂閱都可以在這邊處理。
打 tp.edu.tw 與 ntpc.edu.tw 可以看到不少學校都用 Let's Encrypt 的服務，像是「臺北市內湖區碧湖國小全球資訊網」這個 (雖然一進去就看到 flash...)。
↧
TLS 1.3 進入 Proposed Standard
最近蠻熱的一個新聞，TLS 1.3 的 draft-ietf-tls-tls13-28.txt 進入 Proposed Standard 了 (在「draft-ietf-tls-tls13-28 - The Transport Layer Security (TLS) Protocol Version 1.3」這邊可以看到歷史記錄)：「Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)」。
沒意外的話這就會是最終版本了。如果要看 TLS 1.2 與 TLS 1.3 的差異，看維基百科上的 Transport Layer Security - TLS 1.3 會比較清楚。
大家等很久了... 像是 OpenSSL 1.1.1 其實一部分也是在等 TLS 1.3 正式推出：(出自「Using TLS1.3 With OpenSSL」)
OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. In the meantime the OpenSSL git master branch contains our development TLSv1.3 code which can be used for testing purposes (i.e. it is not for production use).
主要還是期待非 NSA 派系的 cipher (其實幾乎都是 djb 的戰果) 與 1-RTT handshake，後續等 TLS 1.3 變成 Standard Track 應該就會被各家瀏覽器開預設值了...
↧
↧
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...
↧
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 嗎？@_@
↧
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。
↧
![[SweetSub&LoliHouse] 小书痴的下克上 领主的养女 / Honzuki no Gekokujou S04 - 05 [WebRip...](http://files.seeusercontent.com/2026/04/08/dRa8/Honzuki.jpg)
