Mozilla 對 WoSign + StartCom 的正式處分

MozillaWoSign + StartCom 的不信任處分出爐了:「Distrusting New WoSign and StartCom Certificates」,最後處分的內容跟之前的討論差不多 (參考先前寫的「Mozilla 對於 WoSign + StartCom 根憑證的新發展:拔除」)。

Mozilla 台灣有放出中文版的說明 (差不多就是英文翻譯的版本):「取消對 WoSign 與 StartCom 新簽發憑證的信任」。

這次比較麻煩的地方在於要信任已經發出的 certificate,而且量太大無法窮舉。所以必須改增加程式碼處理,而這個方法無法對使用 Mozilla CA Certificate Store 的人生效 (因為這包套件只是一堆 pem 檔案,沒辦法放特殊的邏輯進去...)

另外現在 Firefox 是 49 版,要到 51 版才會生效,看起來還會花一陣子...

在 Google Chrome 連上因 HSTS 而無法連線的網站

Update (2018/03/15):字串改了,請參考「本來 Google Chrome 要繞過 HSTS 的 badidea 被換掉了...」。

像是把 StartCom 停用掉後造成 www.kernel.org 無法連線的問題:

前幾天在 Twitter 上看到解法:

說道 StartCom,StartCom 與 WoSign 的故事才剛要開始,前陣子在「Mozilla 在考慮移除 WoSign 的 CA Root」這邊提到的問題,最近 mailing list 上越來愈刺激了。(發現更多沒有通報的問題)

另外也發現 StartCom 被 WoSign (的 CEO) 買下來了,當初因為「Why I stopped using StartSSL (Hint: it involves a Chinese company)」而移除信任,看起來情況只會更糟糕...

強迫要求使用者改密碼反而會不安全?

在「Want Safer Passwords? Don't Change Them So Often」這邊在討論改目前 password policy 會有要求一定時間要改密碼造成的問題。原報導出自 美國聯邦貿易委員會 blog 上的「Time to rethink mandatory password changes」。

當你強制要求改密碼時,由於因為是被逼的,他們不會放太多心力:

Lorrie Cranor recently outlined, the weight of recent research agrees that when people are forced to change their passwords on the regular, they don’t put a whole lot of mental muscle behind it.

而在沒有準備的情況下產生出來的密碼將會是比較容易預測的:

Instead, Cranor notes, according to one UNC study, people “tended to create passwords that followed predictable patterns, called ‘transformations,’ such as incrementing a number, changing a letter to similar-looking symbol (for example changing an S to a $), adding or deleting a special character (for example, going from three exclamation points at the end of a password to two), or switching the order of digits or special characters (for example moving the numbers to the beginning instead of the end).”

另外你應該鼓勵使用者用 password manager 管理密碼,雖然不是完美的,但至少是目前比較合理的方案:

If for whatever reason you still can’t let go of making people change passwords as often as they turn the pages of their wall calendars, Cranor suggests that you at least encourage them to use a password manager, like LastPass or DashLane. They’re not perfect, but they can be a “very reasonable strategy” for coping, mostly because they don’t require people to balance unpredictable passwords with ones they can actually remember.

Mozilla 的人提出討論,把 Debian 上的 Iceweasel 改名回 Firefox

2006 年時因為 Mozilla 的人認為 Debian 改了太多東西 (以及其他原因),不應該使用 Mozilla Firefox 這個帶有商標的名稱,要求 Debian 改名 (事情的經過可以參考維基百科上的「Mozilla software rebranded by Debian」條目)。

而在九年後,最近 Mozilla 的人在 Debian 上開了一個 bug report,討論是否還需要維持 Iceweasel 這個名字:「#815006 - Renaming Iceweasel to Firefox」。

Debian 這邊的人也提出了很多不一樣的意見 (尤其是對 Mozilla 的商標使用規範),目前還在爭論...

PCI DSS 的更新:PCI DSS 3.1

PCI DSS 3.1 出了:「PCI COUNCIL PUBLISHES REVISION TO PCI DATA SECURITY STANDARD — PCI DSS 3.1 and supporting guidance helps organizations address vulnerabilities within SSL protocol that put payment data at risk; PA-DSS revision to follow —」(PDF)。

與 3.0 相比,修正了 SSL 與 TLS 的安全性問題。分成兩大塊討論,對於新的系統:

  • 禁止使用 SSL 與早期的 TLS (包括了 TLS 1.0 與 TLS 1.1 的某些設定)。

而對於舊的系統:

  • 在 2016 年 6 月 30 日後,禁止使用 SSL 與早期的 TLS。
  • 在這之前,不符合上述條件的設備必須修正到可以防禦已知的 SSL 與 TLS 問題。
  • 對於 POS (Point-of-sale) 與 POI (Point-of-interaction) 系統則是例外處理:確認可以防禦已知 SSL 與 TLS 問題的話,期限後仍然可以使用。

Google 的 Project Zero 修正 Policy

在之前受到批評後,GoogleProject Zero 修正了對應的 Policy:「Feedback and data-driven updates to Google’s disclosure policy」。

原先的 Policy 是 90 天強制公開,修正的 Policy 有幾個改善:

  • 如果揭露日是週末或是美國的假日,會順延到下一個工作日。
  • 如果原廠有告知需要更多時間修復,Project Zero 會延長 14 天的寬限期。
  • 在公開前會申請對應的 CVE 號碼。

要瀏覽器不要送出 Referrer 的 Referrer Policy

在讀「The No CAPTCHA problem」這篇的時候看到的:「Referrer Policy」。

<meta name="referrer" content="never">

目前正式版本的瀏覽器中,只有 Google Chrome 有支援,而其他瀏覽器正在開發,像是 Firefox 上個月才進 trunk:「Bug 704320 - Implement <meta name="referrer">」,預定在 36 版才會納入 (目前是 34)。

還蠻新的 HTML5 標準 (還在制定),可以來定期追進度...

CSP (Content Security Policy)

Twitter 上看到 Dan Kaminsky 的 retweet:

開頭的幾篇就列出不少 CSP 常見的情況,並且說明 CSP 應該要在軟體開發時就引入:

另外提到的 CSP Level 2 也是個很有趣的觀念,像是 nonce:

以及 hash:

不過 Level 2 目前還在 working draft:「Content Security Policy Level 2」,這個功能應該還要等...

用 Content-Security-Policy 攻擊

在「When Security Generates Insecurity」這篇文章裡,介紹了如何利用 Content-Security-Policy 攻擊網站。

首先,我想要知道是不是有登入 Facebook 或是 Google

Interest piqued by the report-uri feature, I looked into abusing it to glean information about user state, my idea was this: when a user is not logged into Google Calendar, accessing calendar.google.com redirects them to accounts.google.com via a Location header. If I whitelisted calendar.google.com but not accounts.google.com, accessing that resource within my web page would break CSP, subsequently sending me a message telling me whether they were logged into Google.

也就是說,利用 CSP 的 report-uri 以及重導的特性,可以分辨出使用者是否有登入。以 Facebook 以及 Google 的例子:

The implementation was like this: I had a single image on the page <img src="http://calendar.google.com"/>, and I sent the Content-Security-Policy header Content-Security-Policy: image-src calendar.google.com. The test was a success, I was able to detect login on Google. The same extended to Facebook; apps.facebook.com would redirect to www.facebook.com only if the user was logged in.

另外,由於實務上可以偵測 path,所以可以去「猜測」使用者是不是某個特定的人,在文章裡假設的是美國總統 Barack Obama:

By using CSP to whitelist facebook.com/me and facebook.com/barackobama and embedding http://facebook.com/me as an image, I can conditionally create a CSP report only if the current user on Facebook is not Barack Obama.

很有趣的安全性問題...

AWS ELB 加強安全性...

AWS ELB 加強對 SSL 安全性的功能:「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy),愈大多數的實做相同,是使用 ECDH

第二個是 Server Order Preference,由 server 這邊決定最終的 cipher。

最重要的是第三個,也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01,把上面兩個都設進去了。

這次的升級是對安全性的提昇...