Home » 2015 » September (Page 2)

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."

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

Google 推出 Brotli 無損壓縮法

Google 推出了 Brotli 這個無損壓縮法:「Introducing Brotli: a new compression algorithm for the internet」。

Google 推出的 Zopfli 相容於 DEFLATE 的超慢壓縮演算法,但可以多壓榨出 3%~8% 的壓縮率。而 Brotli 則是重新設計,壓縮與解壓縮速度跟 DEFLATE 差不多,但壓縮率比 Zopfli 多了 20%~26%。

This new format allows us to get 20–26% higher compression ratios over Zopfli. In our study ‘Comparison of Brotli, Deflate, Zopfli, LZMA, LZHAM and Bzip2 Compression Algorithms’ we show that Brotli is roughly as fast as zlib’s Deflate implementation.

由於目標是希望讓瀏覽器支援新的壓縮法,Google 把 Brotli 往 RFC 提案,試著變成公開標準:「Brotli Compressed Data Format」。

看了看 commit log,看起來已經開發一陣子了...

最近 Facebook 破圖的問題 (168.95.1.1 出問題)

最近在 Facebook 上常看到有同事在抱怨破圖,其實是 168.95.1.1 的問題... 在 zsh 下跑一百次查詢可以偵測到對應的問題,不只是 Facebook 的網站,包括 HiNet 自家網站都查不到:

gslin@GSLIN-HOME1404 [~] [01:12/W5] repeat 100 host www.hinet.net 168.95.1.1 | grep REFUSED
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)
Host www.hinet.net not found: 5(REFUSED)

隔壁的 168.95.192.1Google 家的 8.8.8.8 就沒這個問題:

gslin@GSLIN-HOME1404 [~] [01:13/W5] repeat 100 host www.hinet.net 168.95.192.1 | grep REFUSED
gslin@GSLIN-HOME1404 [~] [01:13/W5] repeat 100 host www.hinet.net 8.8.8.8 | grep REFUSED     
gslin@GSLIN-HOME1404 [~] [01:14/W5]

所以 workaround 就呼之欲出了:把 DNS resolver 換成 8.8.8.8

Percona 正式推出相容於 MongoDB 的產品「Percona Server for MongoDB」

Percona 正式推出與 MongoDB 相容的產品 Percona Server for MongoDB:「Percona Delivers Free, Open Source Percona Server for MongoDB」。

挑重點講,其實最重要的是 data engine 多了 Percona 自家的 PerconaFT 以及 FacebookRocksDB

Percona Server for MongoDB offers all the features of MongoDB 3.0 Community Edition, along with two additional storage engine options – PerconaFT and Facebook’s RocksDB

PerconaFT 是基於被併購的 Tokutek 所研發的 TokuDB (Fractal tree index) 而誕生的產品,在效能上有相當的優勢...

如果有機會的話來研究看看吧 :o

AVG 更新隱私條款,以便能夠蒐集使用者的搜尋紀錄並且賣給其他人

在「AVG can sell your browsing and search history to advertisers」這邊整理的比較清楚:

The updated policy explained that AVG was allowed to collect "non-personal data", which could then be sold to third parties.

或是抓原文:

Do you share my data?

Yes, though when and how we share it depends on whether it is personal data or non-personal data. AVG may share non-personal data with third parties and may publicly display aggregate or anonymous information.

新的條款會在今年 (2015) 的十月十五日生效。

把 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

Subresource Integrity

GitHub Engineering 的「Subresource Integrity」這篇提到了新的 W3C 提案「Subresource Integrity」。

其實就是要做這件事情:

<script src="https://example.com/example-framework.js"
        integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg="
        crossorigin="anonymous"></script>

可以確保 CDN 被攻陷時還有一定程度的抵抗力。在 MDN 上的「Subresource Integrity」也可以參考。

目前 Google Chrome 45+ (stable 版) 與 Firefox 43 (目前是 Nightly 版) 有支援。

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 發現。

Archives