Comodo 取消對 WoSign CA 的 Cross-signed

剛剛看到 ComodoRob Stradling 在群組上說明了 Comodo 透過 CRLOCSP 取消對 WoSign CA 的 cross-signed:「Incidents involving the CA WoSign」。

Today we have revoked (via CRL and OCSP) all 3 of the cross-certificates that we'd issued to WoSign:

https://crt.sh/?id=3223853
https://crt.sh/?id=12716343
https://crt.sh/?id=12716433

See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2

然後另外也看到在倫敦與 Qihoo 360StartCom 以及 WoSign 的會面也已經結束了,接下來 Mozilla 會討論新的計畫後更新上來:「WoSign and StartCom: next steps」。

iOS 阻擋 WoSign 憑證

mozilla.dev.security.policy 上看到有人行動了:「Apple's response to the WoSign incidents」。這使得 Apple 成為 WoSign 事件中第一個行動的單位。

Apple 這次先把 WoSign 放入 iOS 憑證清單的黑名單公告在這邊:「Blocking Trust for WoSign CA Free SSL Certificate G2」。

WoSign 在 iOS 產品線中是靠 StartComComodo 的交叉簽章,所以如果 Apple 只想擋 WoSign 憑證的話,必須以阻擋 Intermediate CA 的方式避開:

Although no WoSign root is in the list of Apple trusted roots, this intermediate CA used cross-signed certificate relationships with StartCom and Comodo to establish trust on Apple products.

不過為了降低對 user 的影響,這次的阻擋會有例外。當 CT log server 在 2016-09-19 前收到的 SSL certificate 還是會信任 (要注意的重點是,這邊的日期不是簽發,是送到 CT log server 上):

To avoid disruption to existing WoSign certificate holders and to allow their transition to trusted roots, Apple products will trust individual existing certificates issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19.

接下來會開始更深入的調查 WoSign 與 StartCom:

As the investigation progresses, we will take further action on WoSign/StartCom trust anchors in Apple products as needed to protect users.

另外本來的棚子裡,Qihoo 360 與 StartCom 正式提出要求在 2016/10/04 與 Mozilla 的人面對面討論 (在英國):「WoSign and StartCom: next steps」:

Following the publication of the recent investigative report, representatives of Qihoo 360 and StartCom have requested a face-to-face meeting with Mozilla. We have accepted, and that meeting will take place next Tuesday in London.

繼續來看進度... 下個禮拜應該會有更多的資料出來。

另外一套用 shell script 寫的 ACME client (或者說 Let's Encrypt client)

acme.sh 是另外一套用 shell script 寫的 ACME client,由西安的 Neilpang 寫的。我也包成 Ubuntu PPA 了:「PPA for acme.sh」。

我建議的用法是先建立 /etc/acme.sh,把各種設定都放到這個目錄裡面,然後用這樣的指令執行:

$ sudo acme.sh --issue -d www.example.com -w /srv/www.example.com/webroot/ --home /etc/acme.sh/

不過 acme.sh 有個問題,沒有將檔案與目錄權限處理好... 我申請完後發現目錄是 drwxr-xr-x,而 key 是 -rwxr-xr-x,這樣會有安全性的問題,需要自己再修改。

letsencrypt.sh 改名為 dehydrated

Twitter 上被提醒 letsencrypt.sh 改名為 dehydrated 了:

在「renamed project to dehydrated and main script to dehydrated.sh」這邊可以看到對應的 commit。

原有的 letsencrypt.sh PPA 仍然會保留,但不會再更新 (維持 letsencrypt.sh 所發行的最後一個版本,0.3.0),要使用的人請使用 dehydrated PPA,目前是 0.3.1。

原先的設定要搬過去的話有不少要改:

  • /usr/sbin/letsencrypt.sh -> /usr/sbin/dehydrated (執行檔)
  • /etc/letsencrypt.sh/ -> /etc/dehydrated/ (設定檔與 cert & key 的目錄)
  • /var/www/letsencrypt/ -> /var/www/dehydrated/ (challenge 的目錄)

既然 cert & key 的目錄也換了,apachenginx 的設定也要記得換,我這邊還要多換 Postfix 的設定...

接下來要改對應的教學文件...

HPKP 遇到的阻礙

關於 HPKP,可以參考「HTTP Public Key Pinning 介绍」這篇介紹,寫得很清楚。

HPKP 是解決 CA 架構錯發憑證的方案 (無論是無意或是故意),像是最近吵的比較熱的 WoSign 發出 GitHub 的憑證的問題就可以用 HPKP 解。

原理上來說,就是在 HTTP header 裡面指出這個站台所允許的 Root CA 有哪些。所以跟 HSTS 一樣是走 Trust On First Use 架構,當 client 第一次連上的時候會記下資訊,之後就可以使用這個資訊來驗證。

但 HPKP 與 HSTS 不同的地方在於,HSTS 只是個 Yes/No 問題 (i.e. 是否強迫使用 HTTPS),而且通常 migrate 上去後就不會拔掉。

但 HPKP 則是要指定 Root CA,這代表不能隨便換一家簽。當你用的那家 Root CA 出包時就苦了... (就像 WoSign 免費憑證的問題)

這使得 HPKP 的實作成本過高,而且得到效益太低,另外也因為替代的方案有不少 (像是 Certificate Transparency),導致 HPKP 根本沒什麼人用:「Is HTTP Public Key Pinning Dead?」。

在 comment 有人直接拉出來統計,使用的比率反而在下降:

From my stats looking to the Alexa 1K top websites from 2015-07-26 to 2016-07-31 the number of websites NOT using HPKP increase from 99.47% to 99.58% which means almost nothing.

不過我覺得算是平行發展吧,這些驗證的技術都不怎麼衝突... HPKP 解決問題的方法非常的技術面,而 Certificate Transparency 還是走稽核路線讓 Root CA 回報每一個發出的 Certificate...

OpenBSD 將 ACME Client (Let's Encrypt Client) 納入系統

看到 OpenBSD 直接把 ACME 協定的 client 放進系統內,而 ACME 也就是 Let's Encrypt 所使用的協定:「Let's Encrypt client imported into -current」:

CVSROOT:	/cvs
Module name:	src
Changes by:	florian@cvs.openbsd.org	2016/08/31 16:01:42

Added files:
	usr.sbin/acme-client: ChangeLog Makefile acctproc.c base64.c 
	                      certproc.c chngproc.c dbg.c dnsproc.c 
	                      extern.h fileproc.c http.c http.h jsmn.c 
	                      jsmn.h json.c keyproc.c letskencrypt.1 
	                      main.c netproc.c revokeproc.c rsa.c rsa.h 
	                      sandbox-pledge.c util-pledge.c util.c 

Log message:
Import Kristaps' letskencrypt and call it acme-client in tree.
OK to get it in deraadt@ (and probably beck@)

At least deraadt@, beck@ and otto@ are fine with the name and the
disagreements stopped.

用的是 acme-client,先前叫做 letskencrypt,以 C 開發的 ACME client。

Firefox 49 將可以吃系統的 Certificate Trust Store

在「Upcoming Changes to Root Certificates in Firefox on Windows」這邊看到 Firefox 49 將會有選項可以讓 Firefox 多吃系統的 Certificate Trust Store:

This feature is available in Firefox 49 and up (currently in beta). To give it a try, set the preference security.enterprise_roots.enabled to true. After that, Firefox should connect successfully to sites using certificates issued by 3rd party root certificates that have been added to the Windows trust database.

這對企業來說會比較方便管理。

These features are still in the early stages, so if you encounter any unexpected behavior, please feel free to file a bug.

然後正在測試階段,有問題的可以去戳...

Mozilla 在考慮移除 WoSign 的 CA Root

雖然平常早就把 WoSign 移除信任,但在「Mozilla考虑对沃通CA采取行动」這邊看到有趣的消息,翻了一下 Gervase Markham 發表的原文還蠻精彩的:「Incidents involving the CA WoSign」。

第一次事件 (Incident 0) 是在 2015/04/23,攻擊者只要能夠證明他能控制某個 TCP port,就會發出 certificate:

On or around April 23rd, 2015, WoSign's certificate issuance system for their free certificates allowed the applicant to choose any port for validation. Once validation had been completed, WoSign would issue certificates for that domain. A researcher was able to obtain a certificate for a university by opening a high-numbered port (>50,000) and getting WoSign to use that port for validation of control.

設計不良造成的資安事件總是會發生。重點在於 Google 知道,但 Mozilla 完全不知道:(我講得很保守是因為這個句子在 thread 後面被澄清解釋的更慘,參考後文)

This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.

更嚴重的是,這次的事件在 WoSign 的稽核上沒有出現:

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

第二次事件 (Incident 1) 是在 2015 年六月,也是資安設計的問題,當你可以拿到 WoSign 所指定的 subdomain 控制權後,你就可以拿到 parent domain 的 certificate,而這次甚至被拿到 GitHub 全系列的 certificate:

The reporter proved the problem in two ways. They accidentally discovered it when trying to get a certificate for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then confirmed the problem by using their control of theiraccount.github.com/theiraccount.github.io to get a cert for github.com, github.io, and www.github.io.

嗯,也沒通報:

* This misissuance incident was not reported to Mozilla by WoSign as it should have been (see above).

嗯,稽核也沒出來:

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

嗯,被拿到的 domain (ucf.edu) 也沒 revoke:(可以從「crt.sh | 29647048」這邊看到)

They reported this to WoSign, giving only the Github certificate as an example. That cert was revoked and the vulnerability was fixed. However recently, they got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later.

第三次事件 (Incident 2) 則是在 2016 年七月,由於現在大多數的瀏覽器都會對 2016 後簽出的 SHA-1 憑證直接標示為不安全,而 WoSign 的 API 提供造假,讓簽名日期 (notBefore) 簽在 2015/12/20:

Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm.

嗯,然後否認造假:

* WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "this date is the day we stop to use this code"[4]. If that is true, it is not clear to us how StartCom came to deploy WoSign code that WoSign itself had abandoned.

嗯,然後還是沒有回報給 Mozilla:

* This misissuance incident was not reported to Mozilla by WoSign as it should have been.

稽核報告應該是因為這太新,還沒開始做?

另外在 thread 討論時,Google 的 Ryan Sleevi 澄清的更慘:

Clarification: In none of these incidents was Google notified proactively by WoSign. Instead, Google received communication from internal or external researchers regarding these issues, either prior to resolution or much later after the fact, and subsequently contacted WoSign regarding them.

It was only when Google found out recently that other programs were NOT notified, proactively, as had been expected, that Google shared the details it was aware of regarding various CA incidents, including those of WoSign, mentioned in this thread.

也就是說,是 Google 主動發現這些問題,並且通報 WoSign。後來過了許久發現 WoSign 沒有照規定通報其他 CA Root 管理單位 (以這邊來說是 Mozilla),於是 Google 決定主動通報其他單位,然後大~爆~炸~

在密碼學理論裡,CA 架構是靠著稽核建立信任的,這次的事情又再次證實這個問題 (但目前沒有其他好的機制可以做)。來猜測下場的話,我的預期是會像拔掉 CNNIC 的作法拔掉信任,但針對之前發出的 certificate 設為白名單 (直到過期):

Let's Encrypt 的 Root CA 進入 Mozilla 的信任清單了

Let's Encrypt 的 Root CA 進 Mozilla 的 CA 清單了:「Let's Encrypt Root to be Trusted by Mozilla」,Mozilla 增加的 ticket 則可以在「Add ISRG Root X1 root certificate to NSS」這邊看到。

目前的信任路徑是透過 IdenTrust 簽出來的,也就是下面那條。而現在 Mozilla 的產品線多了一條信任的路徑 (綠色粗線):

其他的單位 (以及瀏覽器) 也有提出申請,還在稽核驗證:

We have also applied to the Microsoft, Apple, Google, Oracle and Blackberry root programs. We look forward to acceptance into these programs as well.

除了 Oracle 應該是指 Java 用到的那包,其他的應該都是包含自家的系統。

CloudFlare 的 Origin CA:保護 CloudFlare 到 Origin 這段的傳輸過程

CloudFlare 推出的 Origin CA 用來保護從 CloudFlare 到 Origin Server 這段的過程:「Introducing CloudFlare Origin CA」,也就是右半部這段:

CloudFlare 把這個新功能包裝得很神,但實際上只是弄個 CA 出來跑而已,僅此而已。

當然,由於他不需要處理 Public CA 的問題,所以有很多在一般 TLS 連線需要做的檢查步驟可以被簡化,藉此達到效能改善,包括了省掉 intermediate certificates、OCSP 以及 SCTs:

With Origin CA certificates, we’ve stripped everything that’s extraneous to communication between our servers and yours to produce the smallest possible certificate and handshake. For example, we have no need to bundle intermediate certificates to assist browsers in building paths to trusted roots; no need to include signed certificate timestamps (SCTs) for purposes of certificate transparency and EV treatment; no need to include links to Certification Practice Statements or other URLs; and no need to listen to Online Certificate Status Protocol (OCSP) responses from third-parties.

進而省下大量的連線成本:

Eliminating these unnecessary components typically found in certificates from public CAs has allowed us to reduce the size of the handshake by up to 70%, from over 4500 bytes in some cases to under 1300.