才講完要成立南韓機房的計畫「AWS 將在 2016 年成立南韓機房」，直接由老大 Werner Vogels 加碼宣佈了倫敦機房 (英國機房) 的計畫：「London Calling! An AWS Region is coming to the UK!」。
預定在 2016 年年底或是 2017 年年初對外運作，這將會成為歐洲的第三個機房，而前兩個是冰島愛爾蘭與德國。可以看出來 2016 年大舉擴張的態勢...
Month: November 2015
檢查 Android 裝置的安全性問題
在「How to check if your Android device is vulnerable to attack」這邊看到有新的 open source 工具可以偵測 Android 裝置的安全性問題，在 Google Play 上可以下載：「VTS for Android」。
官方的擷圖可以看到偵測的項目，以及對應的 CVE 編號。拿手上的 LG G2 測試 (官方的最新韌體)，看起來是該刷 3rd-party 韌體了...
AWS 將在 2016 年成立南韓機房
AWS 宣佈了將會在 2016 年年初建立南韓機房：「In the Works – AWS Region in South Korea!」，考慮到地理位置的話，南韓機房的 latency 有機會比日本機房還低，不過台灣對韓國的國際頻寬可能不太夠，應該還是得用日本當主力...
這樣 2016 年預定會加開印度、俄亥俄州以及韓國三個區域了。不知道還有沒有能量開其他地區...
微軟也宣佈 SHA-1 的 SSL certificate 將於 2016 年七月停用
在「SHA-1 Deprecation Update」這篇文章中宣佈本來在「Windows Enforcement of Authenticode Code Signing and Timestamping」這邊宣佈 2017 年停用 SHA-1 SSL certificate 的進度將提前到 2016 年七月 (到 2016 六月前仍然可以使用)。
在微軟的文章裡也有提到，如同 Mozilla 在前幾個禮拜宣佈的「Continuing to Phase Out SHA-1 Certificates」計畫，也是預定把 2017 年的淘汰計畫提前到 2016 年七月。
主要是因為「對 SHA-1 的攻擊進展」這邊提到對 SHA-1 的新攻擊，所以決定提前半年...
把家裡的機器換上 Let's Encrypt 的 SSL certificate
依照「Beta Program Announcements」這邊的指示去填單申請 Let's Encrypt 的 SSL certificate (先幫 home.gslin.org 申請)，等了好幾天，在剛剛收到信就弄了弄，還蠻順利就設好了。
可以看到 Let's Encrypt Authority X1 被 DST Root CA X3 簽名的情況，而後者已經被大多數瀏覽器所確認了：
首先是先把 letsencrypt client 拉下來：
$ git clone https://github.com/letsencrypt/letsencrypt
接著執行認證：
$ cd letsencrypt $ ./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory certonly
執行時會先建立環境 (由於需要寫到 /etc/letsencrypt 裡面，會需要 root 或 sudo 權限)。
接下來會跳出一些畫面讓你設定，包括 hostname 以及聯絡資訊，再來就是認證的方式 (我是跳出使用 apache 或是 standalone web server)，由於我的 port 443 已經被 apache 吃掉，所以需要用 apache。
最後認證成功會出現：
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/home.gslin.org/fullchain.pem. Your cert will expire on 2016-02-02. To obtain a new version of the certificate in the future, simply run Let's Encrypt again.
有效期限 90 days，雖然裡面是講 fullchain.pem，但其實每個檔案都有拆開放，看一下 /etc/letsencrypt/live/home.gslin.org/ 路徑裡的檔案，設定對應的 cert/chain/key 應該還是比較習慣的作法。
官方目前的建議是 60 days 重新 renew 一次，也許可以設成 cron，每兩個月自動更新一次 (並且 reload apache)。
CloudFlare 通過 PCI DSS 3.1 Level 1
CloudFlare 宣佈通過 PCI DSS 3.1 Level 1：「CloudFlare is now PCI 3.1 certified」。
早在去年的時候 CloudFlare 就已經通過 PCI DSS 2.0 Level 1：「CloudFlare is PCI Certified」，這次過 PCI DSS 3.1 主要還是因為 2.0 即將失效，不升級就不能處理信用卡資料了...
Slack 的 User Groups 功能
Slack 最近除了推出了 Group Messages 以外 (參考「Slack 支援多人討論群組」)，也推出了 User Groups 的功能給付費用戶使用：「Introducing User Groups」：
User Groups are enabled for all Slack teams on paid plans (both Standard and Plus). New groups can be created in the Team Directory panel in your desktop app. You can give each a descriptive name and add a note on purpose to help others understand what each group is for. The team directory will then list your team’s existing user groups and show the details of each, along with the the group’s members.
使用者可以被分類成 Group，然後可以針對某一個 Group 傳訊息。而 Plus Plan 的用戶可以透過 SSO 機制將群組資訊帶進來用：
For teams using Single Sign On (SSO) on the Plus plan, you can even use groups to control provisioning accounts from your SSO tools. Users of Active Directory in OneLogin, PingOne, PingFederate, or Okta can take advantage of this built-in user provisioning support to add employees automatically into Slack User Groups matching each employee’s existing group rights, roles and permissions in your internal directory.
另外也有提供 API 讓你用，所以 Standard Plan 用戶也可以自己寫，然後塞進去。
用 jQuery Audit 在 Google Chrome 的 Developer Tools 看到 jQuery 的資料
在「jQuery Audit lets you analyze jQuery from Chrome Developer Tools」這邊看到 jQuery Audit 這個 Google Chrome 的套件。這個套件讓你在 Developer Tools 裡看到 jQuery 的資料：
在大家都用 jQuery 操作的情境下，這個套件超好用...
STARTTLS 的不完整性以及大規模監控電子郵件
在「Don’t count on STARTTLS to automatically encrypt your sensitive e-mails」這邊提到了 STARTTLS 的問題，引用「Neither Snow Nor Rain Nor MITM ... An Empirical Analysis of Email Delivery Security」這篇論文的說明。
SMTP 裡 STARTTLS 的設計雖然可以加密，但仲所皆知，可以阻擋 EHLO 回應結果避免建立 STARTTLS 連線，而讓發送端改用傳統未加密的 SMTP 傳輸。而研究發現其實目前就有大規模的這種監控行為：
可以看到突尼西亞的監控情況遠超過想像...
目前的想法是發展一套類似 HSTS 的 Trust on first use 設計，也許在這份報告出來後可以加速催生...
Symantec 的 SSL Certificate 醜聞繼續爆發...
tl;dr：目前的外部稽核還沒有完成，有可能會有更慘烈的情況。如果你最近要買 SSL certificate，不要碰 Symantec 旗下的產品，包括了 Verisign、Thawte、GeoTrust、Equifax (GeoTrust 下)、RapidSSL。
在「Symantec 的 Thawte 發出 Google 的 SSL certificate 的後續」這邊有提到先前 Google 抓到 Symantec 發出 Google 憑證的問題，後續稽核時發現更多問題...
Google 在「Sustaining Digital Certificate Security」這篇提到了幾件事情。首先是基於 Symantec 第一版的稽核報告，發現有 23 個 SSL certificate 在 domain owner 沒有被通知的情況下被簽名，這包括了 Google 與 Opera 的五個單位：
Following our notification, Symantec published a report in response to our inquiries and disclosed that 23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google and Opera.
但 Google 光是透過 Certificate Transparency 認為問題不僅於此 (於是認為 Symantec 的稽核不確實)，通報了其他主要的 Root Certificate 管理單位：
However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research.
而 Symantec 再次稽核，這次就大爆炸，光是他們查出來的就有 164 個 SSL certificate 橫跨 76 個網域被簽出，並且有 2458 的不存在的 domain 被簽出：
Symantec performed another audit and, on October 12th, announced that they had found an additional 164 certificates over 76 domains and 2,458 certificates issued for domains that were never registered.
Symantec 這次提供的報告包括了比較完整的資料，爆發的品牌包括了 Symantec 所有的產品：Verisign、Thawte、GeoTrust、Equifax (GeoTrust 下) 以及 RapidSSL。
要不是 Symantec 的市占率高到爆炸，Google 大概就像 CNNIC 那樣直接拔掉了。(參考「CNNIC 的根憑證 (包括 EV) 從 Google 全系列產品移除」，市占率的部份可以參考「Usage of SSL certificate authorities for websites」這邊的資料，目前看到是 29.9% 第二高，僅次於 Comodo 的 39.1%)
由於沒辦法砍，所以 Google 直接下了幾個通牒，第一個是從 2016 六月開始所有簽出的 SSL certificate 都必須發紀錄到 Certificate Transparency (目前規範中只有 EV SSL certificate 有要求)，否則之後的簽出的 SSL certificate 不保證會動：
It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. In this case, logging of non-EV certificates would have provided significantly greater insight into the problem and may have allowed the problem to be detected sooner.
After this date, certificates newly issued by Symantec that do not conform to the Chromium Certificate Transparency policy may result in interstitials or other problems when used in Google products.
再來是對報告要求補上為什麼稽核機制沒有偵測到，以及「每一次」為什麼沒有按照 Baseline Requirements (一般 SSL certificate 的規範) 以及 EV Guidelines (EV SSL Certificate 的規範) 的詳細資訊：
More immediately, we are requesting of Symantec that they further update their public incident report with:
- A post-mortem analysis that details why they did not detect the additional certificates that we found.
- Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.
同時要求第三方稽核確認這次事件，而僅非 Symantec 自己稽核：
Following the implementation of these corrective steps, we expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit.
而且也清楚要求第三方稽核確認包括：簽的 public key 沒有任何時間點可以被 Symantec 員工取得 private key、Symantec 員工無法使用該項測試工具簽自己擁有 private key 的 SSL certificate、再次確認 Symantec 的稽核紀錄是無法被更改與刪除的。
The third-party security audit must assess:
- The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool.
- That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key.
- That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS.
最後還特地放話說，有新的消息時會再考慮更進一步的反擊：
We may take further action as additional information becomes available to us.
可以發現語氣非常硬，要不是 Symantec 的市占率這麼高，Google 大概也不會這麼費工...
Symantec 提供的報告可以在「Test Certificates Incident Final Report」、「Incident Report 1」、「Incident Report 2」取得。