Let's Encrypt 的 Limited Beta

Let's Encrypt 在拿到 IdenTrust 提供的 cross sign (參考「Let's Encrypt 正式出發」) 後所啟動的計畫:「Beta Program Announcements」。

要先透過 Google Forms 填單等待,等通過後要指定 production server 才會發出來。

要注意的是,Let's Encrypt 發出來的 SSL certificate 會比較短,只有 90 天有效,設計上是依靠自動機制在更新,所以理論上不會有問題:

Certificates from Let's Encrypt are valid for 90 days. We recommend renewing them every 60 days to provide a nice margin of error. As a beta participant, you should be prepared to manually renew your certificates at that time. As we get closer to General Availability, we hope to have automatic renewal tested and working on more platforms, but for now, please play it safe and keep track.

再來是有註冊限制,分成 Registrations/IP address 與 Certificates/Domain 兩個限制:

There are two rate limits in play: Registrations/IP address, and Certificates/Domain.

前者的限制是每天 10 次:

Registrations/IP address limits the number of registrations you can make in a given day; currently 10. This means you should avoid deleting the /etc/letsencrypt/accounts folder, or you may not be able to re-register.

後者的限制是每個 domain 只給 4 個 certificate:

Certificates/Domain you could run into through repeated re-issuance. This limit measures certificates issued for a given combination of Top Level Domain + Domain. This means if you issue certificates for the following domains, at the end you would have what we consider 4 certificates for the domain example.com.

拿來測試應該是夠用。

RFC7686:保留 .onion 給 Tor 的 Hidden Services 使用

看到 Tor Project 很高興的宣佈 .onion 這個 TLD 在 RFC 7686 成為 Standards Track:「Landmark for Hidden Services: .onion names reserved by the IETF」。

而且也因為成為 IETF 的標準,在 CA/Browser Forum 上更有依據討論在上面的 CA 架構:

With this registration, it is should also be possible to buy Extended Validation (EV) SSL/TLS certificates for .onion services thanks to a recent decision by the Certification Authority Browser Forum.

Let's Encrypt 正式出發

Let's Encrypt 是個新的 CA (Certificate Authority),由許多單位提供資源希望藉由免費的 SSL/TLS certificate 讓 Internet 更安全。

九月的進度是已經成功建立 CA 機制 (包括第三方稽核),並且向各瀏覽器申請加入,同時也找 IdenTrust 申請 cross sign:「Let's Encrypt 的新進展」。

所以兩條路都可行,就是看哪邊比較快。如果瀏覽器先放行了,那麼就是透過 Root CA 直接可以認證。如果是 IdenTrust 先 cross sign,那麼就是透過 IdenTrust 的 Root CA 認證下來。

沒什麼意外的,IdenTrust 的先簽下來了:「Let's Encrypt is Trusted」。

利用 Qualys SSL LabsSSL Server Test 可以看到在「https://helloworld.letsencrypt.org/」這邊的 Demo Site 是從 DST Root CA X3 簽給 Let's Encrypt Authority X1 再簽給 helloworld.letsencrypt.org 的記錄:

接下來就是等最後開放給一般人申請了...

還有超過 20% 的網站使用 SHA-1 憑證

依照 Netcraft 的說明,還有超過 20% 的網站使用 SHA-1 certificate:「One million SSL certificates still using “insecure” SHA-1 algorithm」。

雖然轉換速度算是很快了,不過本來依照進度,2015 年底瀏覽器就應該要把 SHA-1 certificate 認為不安全 (於是失效):

照目前速度,今年年底應該只能掉到 10% 左右吧...

測試 HTTPS 設定的 shell script

在「Using testssl.sh」這邊看到「testssl.sh」這個工具。

需要新版的 OpenSSL 會掃的比較完整,不過看起來 Ubuntu 14.04 內建的就可以掃不少東西了 (當然還是少了 ChaCha20+Poly1305)。

Qualys 的「SSL Server Test」只能掃有開放給公開使用的站台,而這個工具就可以拿來掃內部網站了。

拿官方給的 screenshot 來看結果:

Symantec 的 Thawte 發出 Google 的 SSL certificate 的後續

照目前公開的報導說,幹這件事情的人被幹掉了:「Symantec employees fired over fake security certificates」,也進一步透漏,發現有三個 certificate 被發出來:

Symantec's senior director of engineering Quentin Liu said it discovered three unauthorised certificates last week during product testing.

He explained that 'a few' employees who, it said, had passed the company's on-boarding and security training, failed to follow its policies and were therefore fired after a "thoughful review process."

還是沒看到第三方單位介入稽核的消息。

把 SMTP 的 SSL certfiticate 弄起來...

網站的 SSL certificate 弄過很多次了,想說來測看看 MX host 的部份。弄好後就會像這樣,這是 Varnish 的 mailing list:

Received: from project.varnish-software.com (project.varnish-software.com [194.31.39.164])
        (using TLSv1 with cipher AES256-SHA (256/256 bits))
        (No client certificate requested)
        by home.gslin.org (Postfix) with ESMTPS id 9C2F568009A
        for ; Mon, 21 Sep 2015 08:46:30 +0800 (CST)

這是 nginx 的 mailing list 寄過來的信:

Received: from mail.nginx.com (mail.nginx.com [206.251.255.65])
        (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by home.gslin.org (Postfix) with ESMTPS id 4A4F26801E0
        for ; Mon, 21 Sep 2015 08:25:37 +0800 (CST)

還有些 cipher 的細節晚點再看看有沒有辦法再調整好了... 因為 MX 這樣設定,這次也順便試著用 StartSSL 申請了好幾個 SSL certificate:

;; ANSWER SECTION:
gslin.org.              3600    IN      MX      20 mx20.gslin.org.
gslin.org.              3600    IN      MX      0 mx0.gslin.org.

因為有兩個 MX,所以申請了 mx0.gslin.orgmx20.gslin.org 的 SSL certificate。

接下來的設定主要是參考「Postfix TLS Support」裡面的文件,以及 Google 後找到的很多資料...

在申請到了 SSL certificate 之後要先把 intermediate certificate 合併,然後在 Postfixmain.cf 裡這樣設定:

#
smtpd_tls_cert_file = /etc/ssl/certs/mx0.gslin.org-intermediate.crt
smtpd_tls_key_file = /etc/ssl/private/mx0.gslin.org.key
smtpd_tls_received_header = yes
smtpd_tls_security_level = may

設好後就可以用「TLS Receiver Test」這個工具測試,輸入 admin@gslin.org 可以看到兩台都過了。

然後是對外送信的部份,發現 msa.hinet.net 也有支援 STARTTLS,所以 smart relay 也可以用,這部份可以透過 tcpdump -n -vvvv -A -i ppp0 host 168.95.4.211 確認。寄出來的結果會是這樣:

Received: from home.gslin.org (114-32-152-63.HINET-IP.hinet.net [114.32.152.63])
	by msr9.hinet.net (8.14.9/8.14.9) with ESMTP id t8L2l1gU006249
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
	for ; Mon, 21 Sep 2015 10:47:01 +0800 (CST)

而 Postfix 的設定是這樣設的:

smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = encrypt
smtp_use_tls = yes

D-Link 的 open source package 內包含了拿來簽名用的 Private Key

D-LinkDCS-5020L 的 open source package (因 GPL 要求) 裡放了簽名用的 private key:「D-Link spilled its private key onto the web – letting malware dress up as Windows apps」。

而這把 key 由 Verisign 所簽,因此被 Windows 所信任,所以這把 key 可以用來簽 malware:

而不幸的是,這把 key 已經洩漏出來超過半年了:

The D-Link key was leaked in late February, and expired on September 3, it appears.

又是一連串的 revoke 過程... orz

Thawte (Symantec) 發出 www.google.com 的 EV SSL certificate

Google Online Security Blog 上公佈了一篇他們最近的發現,並且發佈 Google Chrome 的安全性更新:「Improved Digital Certificate Security」。

原因出自於 Thawte (Symantec) 發出 www.google.com 的 EV SSL certificate:

On September 14, around 19:20 GMT, Symantec’s Thawte-branded CA issued an Extended Validation (EV) pre-certificate for the domains google.com and www.google.com. This pre-certificate was neither requested nor authorized by Google.

GoogleCertificate Transparency 上發現:

We discovered this issuance via Certificate Transparency logs, which Chrome has required for EV certificates starting January 1st of this year. The issuance of this pre-certificate was recorded in both Google-operated and DigiCert-operated logs.

對應的 certificate 紀錄可以在「crt.sh | 9314698」這邊看到,包括了 public key 資訊。

然後 Google 跟 Symantec 確認後認定是內部測試造成的 (...):

During our ongoing discussions with Symantec we determined that the issuance occurred during a Symantec-internal testing process.

並且發出安全性更新把這把 key 放到 Google Chrome 的 revocation metadata 裡:

We have updated Chrome’s revocation metadata to include the public key of the misissued certificate. Additionally, the issued pre-certificate was valid only for one day.

一天的內部測試嗎?我怎麼覺得更像是 APT 攻擊?

最後補充一下,在 Google Chrome 裡面 *.google.com 的網段的 SSL certificate 是被特別保護的,可以參考「transport_security_state_static.json」這邊的 JSON 資料,裡面可以看到這幾段:

    {
      "name": "google",
      "static_spki_hashes": [
        "GoogleBackup2048",
        "GoogleG2",
        "GeoTrustGlobal"
      ],
      "report_uri": "http://clients3.google.com/cert_upload_json"
    },

以及:

    // (*.)google.com, iff using SSL, must use an acceptable certificate.
    { "name": "google.com", "include_subdomains": true, "pins": "google" },

也就是只有 Google 自己的 CA 與 GeoTrust 的 CA 是被允許發出 www.google.com 的 SSL certificate (至少在 Google Chrome 裡面會被保護到)。而 GeoTrust 也是 Symantec 的牌子。

如果讓我以陰謀論的角度來猜,這更像是在測試有會有哪些管道通報會讓 Google 發現。

Let's Encrypt 的新進展

Let's Encrypt 宣佈有新的進度了,已經可以從 Root Certificate 簽其他的 SSL Certificate 了:「Our First Certificate Is Now Live」。

測試的網站在 https://helloworld.letsencrypt.org/ 這邊,目前應該還是屬於不信任狀態。一旦 cross sign 或是被加到瀏覽器內,這個網站應該就會馬上生效了。

接下來會同時做幾件事情:

總算又聽到新的進度了...