Alpine Linux 決定將 OpenSSL 換成 LibreSSL

之前看到 Alpine Linux 是從 Docker 這邊看到的,可以弄出還蠻小巧的 image...

前幾天看到他們宣佈打算將 OpenSSL 換掉,換成 LibreSSL:「[alpine-devel] Alpine edge has switched to libressl」。而且理由也講的頗直接,覺得 OpenSSL 的改善速度還是不滿意,而且市場上有其他還不錯的方案可以選:

While OpenSSL is trying to fix the broken code, libressl has simply removed it.

這樣 LibreSSL 又多了生力軍,之前比較大的應該只有 OpenBSD...

Mozilla 對於 WoSign + StartCom 根憑證的新發展:拔除

Okay,在 Mozilla 的人跟 WoSign + StartCom + 360 的人談過後有了新的進展。

幾個小時前 Mozilla 提了新版的草案出來 (對,還是草案):「Remediation Plan for WoSign and StartCom」。但由於 Kathleen Wilson 跟 Gervase Markham 都沒有太多意見,我猜這應該會接近定案了。

這次的處分草案由 Kathleen Wilson 發出來,會包括這些 root certificate,可以看到包括了所有 WoSign 與 StartCom 的 CA:

1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL

首先是認定這一連串的事件是惡意行為:

Based on the information that I have seen regarding WoSign, I believe that WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL certs, when they knew full well that was no longer allowed. I also believe that the deception continued even after Mozilla directly asked WoSign about this. WoSign has lost my confidence in their ability and intention to follow Mozilla's policies.

所以打算採取與 CNNIC 類似的處分方法,但很不幸的由於規模不一樣,所以被迫採用另外的方式來處理:

Therefore, I think we should respond similarly to WoSign as we did to CNNIC [1][2]. Unfortunately, the number of certificates and the timescales involved are such that we prefer not to create a list of the domains for which previously-issued certs that chain up to the Affected Roots may continue to be trusted, so our approach will be a little different, as Gerv previously described[3].

這次處分的過程會包括四個項目,第一個是在 Firefox 51 會用黑名單的方式將這些 root certificate 擋下,但會信任 2016/10/21 前所發出的憑證以降低對目前網站的衝擊:

1) Distrust certificates chaining up to Affected Roots with a notBefore date after October 21, 2016. If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the Affected Roots.
-- This change will go into the Firefox 51 release train [4].
-- The code will use the subject key id (hash of public key) to identify the Affected Roots, so that the control will also apply to cross-certs of the Affected Roots.

然後將之前簽出來的 SHA-1 憑證列入 OneCRL:

2) Add the previously identified backdated SHA-1 certs chaining up to the Affected Roots to OneCRL.

另外一個非常大的事情是,Mozilla 將永久不信任安永香港的稽核報告:

3) No longer accept audits carried out by Ernst & Young Hong Kong.

Gervase Markham 做了補充「永久」的部份:

To be clear, this is a permanent ban, applicable worldwide, but only to the Hong Kong branch of E&Y. (If further issues are found with E&Y audits elsewhere, then we might consider something with wider scope.)

最後一個是移除 NSS 裡包的憑證:

4) Remove the Affected Roots from NSS after the SSL certificates issued before October 1, 2016, have expired or have been replaced.

在討論裡有提到 Firefox 與 NSS 的處置日期不太一樣的問題 (一個是 10/21,一個是 10/01),應該會在正式的定案時修正。

另外在「StartCom & Qihoo Incidents」這邊,Google 家的 Ryan Sleevi 也寫了一串,也許是他目前個人的看法 (但畢竟他是 Google 家主事的人之一),基本上的立場與 Mozilla 相同 (將 WoSign 與 StartCom 視為同一個單位,而且是刻意違反 Baseline Requirement),所以後續應該也會有動作了...

把所有 HTTP 網站的 JavaScript 都關閉

一直以為 Google Chrome[*.] 只能用在開頭,剛剛測了才發現可以用在中間,所以就用這樣的方式擋下 HTTP 網站的 JavaScript:

http://[*.]

這樣就可以減少 HTTP request 被 hijack 插入 javascript 的問題...

用手勢在會議中表達意思

英國內閣辦公室中的英國政府數位服務 (Government Digital Service) 發展了一套手勢 (六個),可以在不用打斷發言過程下表達出一些簡單的意見或是表示想要有進一步的討論:「Platform as a Service team takes even-handed approach to meetings」(網站好像有點熱門,讀取速度變慢不少 XD)。

提高會議溝通的效率...

將 collectd 收集到的資料寫到 CloudWatch 裡

AWScollectd 推出的 plugin,可以將 collectd 收到的資料丟到 Amazon CloudWatch 裡:「New – CloudWatch Plugin for collectd」,GitHub 的連結在「A collectd plugin for sending data to Amazon CloudWatch」這邊。

丟上去以後就可以在 AWS 的 dashboard 上看了:

所以 Apple 也開始玩自動下載新版作業系統這招了...

在「Apple starts downloading MacOS Sierra automatically to your MacBook — Here's How to Stop It」這邊看到 Apple 會自動下載新版作業系統,大約吃 5GB 的流量愈空間:

If you have automatic downloads enabled on your Mac, a large file of around 5GB will mysteriously be downloaded to your computer in the background, using your Internet bandwidth for unrequested files.

關掉的方式在這邊:

To disable the feature, you can head on to System Preferences → App Store → Automatically check for updates and then uncheck "Download newly available updates in the background."

CloudFront 支援 IPv6

Amazon CloudFront 宣佈支援 IPv6 了:「IPv6 Support Update – CloudFront, WAF, and S3 Transfer Acceleration」。

不只是 Amazon CloudFront 支援了 IPv6,還包括了使用 CloudFront 而建出的 AWS WAFAmazon S3 Transfer Acceleration

所以對外的部份都有 IPv6 了 (包括了 ELB),現在不支援的應該是內部機器與 Elastic IP address

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」。

把 CSC (卡片背面的三碼) 變成 OTP (動態密碼)

把信用卡背面的後三碼 (Card security code) 變成動態密碼,雖然一般只會有三碼,但對於網路消費應該會有不少幫助,不過這樣就不能完全不拿出卡片了...:「This high-tech card is being rolled out by French banks to eliminate fraud」。

產品叫做 MotionCode,會先從法國開始:

Today both Société Générale and Groupe BPCE, two of France’s largest banking groups, are preparing to roll out these cards across all their customers after completing a pilot scheme last year.

然後是波蘭、墨西哥以及英國在規劃:

There are other pilots underway in Poland and Mexico, and Davis is running Oberthur’s UK operation with the hope of getting a pilot or trial started with a UK bank soon.

Nginx + FastCGI + Trac

先前試著逼自己用 Phabricator,用了一個多月後發現設計的邏輯還是跟 Trac 差了不少,算是為了 Facebook 特化的產品吧。在這一個月查資料的過程也發現當初 Wikimedia 要採用的時候也花了不少力氣送 patch 回官方,然後針對不少地方客製化調整。

另外比較痛的地方是 plugin 的支援能力還沒有很好,變成很多東西都要改主體... 而且效能也不太好 (不支援 PHP 7.0 還蠻痛的),在比較低階的 VPS 上跑特別明顯。

這幾天花了點時間把 Trac 給架起來,之前都是用 FreeBSD ports 架,但已經愈來愈沒有再接觸 FreeBSD 了,所以這次在 Ubuntu 上用 pyenv 裝起來再用 pip 裝起來。

另外一個跟之前不同的,是先前都用 Apachemod_wsgi,在低階的 VPS 上則是要找省資源的方案,這次則是用 nginx + FastCGI 去接,比起之前複雜不少...

最主要是參考了官方的文件以及「Gentoo下使用nginx+fastcgi部署trac」這邊的說明達到效果,重點是這段 location 的設定:

    location / {
        auth_basic "trac realm";
        auth_basic_user_file /srv/domain.example.com/.htpasswd;

        include fastcgi.conf;
        fastcgi_param AUTH_USER $remote_user;
        fastcgi_param HTTPS on;
        fastcgi_param PATH_INFO $fastcgi_script_name;
        fastcgi_param REMOTE_USER $remote_user;
        fastcgi_param SCRIPT_NAME "";
        fastcgi_pass unix:/var/run/trac/trac.sock;
    }

    location /.well-known/acme-challenge/ {
        alias /var/www/dehydrated/;
    }

網路上有找到用 location ~ (/.*) 去 match,然後拉出 $1PATH_INFO 用的,這這會使得這段 location 的優先權太高 (參考官方對於 location 的順序說明),而蓋掉下面 Let's Encrypt 的 acme challenge 過程,所以還是得這樣搞。

另外是自己一個人用,就用 .htpasswd 的方式認證了,沒必要弄 LDAP 之類的認證...

接下來就是裝一堆 plugin 並且調整 css/js 與 SQL query 了...