Home » Computer » Software » Browser » Archive by category "Firefox" (Page 3)

在 Ubuntu 上跑 Selenium (Google Chrome 與 Firefox)

最近可能會用到,所以開了一台 EC2 instance 跑 Ubuntu 16.04 測試 Selenium。拿 ChromeFirefoxLinux 平台上兩個主要的瀏覽器。

要讓他動還蠻簡單的,只是不知道真的用下去後,後面會遇到多少地雷 XDDD

基本上是按照「Installing Selenium and ChromeDriver on Ubuntu」這篇文章的方法安裝,有幾點可以注意一下:

  • ChromeDriver 可以翻一下最新版,文件上寫的是 2.26,但現在最新的是 2.27 (寫這篇時)。
  • 雖然寫「(Optional) Create and enter a virtual environment」表示可以不做,但不做其實不會動 (看錯誤訊息像是要建立目錄時權限不夠),所以乖乖的用 virtual environment 裝在自己目錄下吧 XDDD

同理,Firefox 用 APTfirefox 套件後,再去抓 geckodriver 回來裝。一樣是照文章裡 chromedriver 的方式放,並且設定連結。

原文 Python 程式裡本來的 driver = webdriver.Chrome() 改成 driver = webdriver.Firefox() 就 ok 了。

這樣手上又多了一些東西可以用...

Firefox 下一個版本 (52) 將預設關閉 SHA-1 支援

順著 SHA-1 正式被打穿,Mozilla 也正式宣佈從下一個版本的 Firefox 將完全關閉 SHA-1 支援 (看敘述應該還是可以透過 about:config 開):「The end of SHA-1 on the Public Web」。

As announced last fall, we’ve been disabling SHA-1 for increasing numbers of Firefox users since the release of Firefox 51 using a gradual phase-in technique. Tomorrow, this deprecation policy will reach all Firefox users. It is enabled by default in Firefox 52.

大家都開始有動作了...

Facebook 與 Google Chrome 以及 Firefox 的人合作降低 Reload 使用的資源

Facebook 花了不少時間對付 reload 這件事情:「This browser tweak saved 60% of requests to Facebook」。

Facebook 的人發現有大量對靜態資源的 request 都是 304 (not modified) 回應:

In 2014 we found that 60% of requests for static resources resulted in a 304. Since content addressed URLs never change, this means there was an opportunity to optimize away 60% of static resource requests.

Google Chrome 很明顯偏高:

於是他們找出原因後,發現 Google Chrome 只要 POST 後的頁面都會 revalidate:

A piece of code in Chrome hinted at the answer to our question. This line of code listed a few reasons, including reload, for why Chrome might ask to revalidate resources on a page. For example, we found that Chrome would revalidate all resources on pages that were loaded from making a POST request.

然後在討論後認為這個行為不必要,就修掉了,可以看到降了非常多:

We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional.

但還是很明顯比起其他瀏覽器偏高不少,在追問題後發現當輸入同樣的 url 時 (像是 Ctrl-L 或是 Cmd-L 然後直接按 enter),Google Chrome 會當作 reload:

The fact that the percentage of conditional requests from Chrome was still higher than other browsers seemed to indicate that we still had some opportunity here. We started looking into reloads and discovered that Chrome was treating same URL navigations as reloads while other browsers weren't.

不過這次推出修正後發現沒有大改變:(拿 production 測試 XDDD)

Chrome fixed the same URL behavior, but we didn't see a huge metric change. We began to discuss changing the behavior of the reload button with the Chrome team.

後來是針對 reload button 的行為修改,max-age 很長的就不 reload,比較短的就 reload。算是一種 workaround:

There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones.

Google 也發了一篇說明這個新功能:「Reload, reloaded: faster and leaner page reloads」。

當 Facebook 的人找 Firefox 的人時,Firefox 決定另外定義哪些東西在 reload 時不需要 revalidate,而不像 Google Chrome 的 workaround:

Firefox chose to implement this directive in the form of a cache-control: immutable header.

Firefox 的人也寫了一篇「Using Immutable Caching To Speed Up The Web」解釋這個新功能。

所以之後規劃前後端的架構時又有東西要考慮進去...

下個版本 Firefox 的 Multi-Process 將預設全面開啟

Mozilla 說明了 Multi-Process 最近的一些進度:「Update on Multi-Process Firefox」。

就目前測試的資料看起來,速度大幅提昇:

Those users have been enjoying the 400% increase in responsiveness and a 700% improvement when web pages are loading.

現在的 Firefox 是 50 版,目前的情況是當 extension 標成 multi-process compatible 就會啟用:

With Firefox 49 we deployed multi-process Firefox to users with a select set of well tested extensions. Our measurements and user feedback were all positive and so with Firefox 50 we deployed multi-process Firefox to users with a broader set of extensions, those whose authors have marked them as multi-process compatible.

下一個版本 (51) 則是會全面開啟,除非有 extension 標成 multi-process incompatible:

Beyond Firefox 50, we have more work to do to enable multi-process Firefox for users with as yet unsupported extensions. In Firefox 51, if all testing goes according to plan, we’ll be enabling multi-process Firefox for users with extensions that are not explicitly marked as incompatible with multi-process Firefox.

總算要把整個架構換過去了...

Mozilla 也在考慮對 Certificate Transparency 的掌握度

由於 Firefox 要支援 Certificate Transparency 的緣故,在「Mozilla CT Policy」這邊 Mozilla 在討論要建立自己的 CT policy 以及自己的架構:

CT is coming to Firefox. As part of that, Mozilla needs to have a set of CT policies surrounding how that will work. Like our root inclusion program, we intend to run our CT log inclusion program in an open and transparent fashion, such that the Internet community can see how it works and how decisions are made.

這樣就有個開頭了...

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),所以後續應該也會有動作了...

Mozilla 對 WoSign 事件的決策 (草稿階段)

在「Mozilla 在考慮移除 WoSign 的 CA Root」這邊提到的事情,隨著時間的發展,大家發現事情愈來愈誇張。

在兩個小時前 MozillaGervase Markham 提出了對 WoSign + StartCom 處置的草稿:「WoSign and StartCom」,草稿在 Google Docs 上的「WoSign and StartCom」這邊可以看到。另外 Mozilla 在 wiki 上「CA:WoSign Issues」將 WoSign + StartCom 的事情都整理了出來,也是重要的資料。

文章很長,先講結論:目前 Mozilla 打算把 WoSign 與 StartCom 所簽出的 certificate 都照當年 CNNIC 的方式拔掉。

從頭說明,事情發生於八月底的時候 Google 通知了 Mozilla 一連串 WoSign 出包卻沒有主動通報的事件,當時知道的大約有三或四件。而在 mozilla.dev.security.policy 不斷的討論的情況下,由於關注度變得超高,在搜尋大量的資料下發現更多問題,到現在 Mozilla 的 wiki 上已經列出了 13 個。

而這邊以 Mozilla 最後整理的草稿,將 13 個事件整合起來成幾件來說明:

WoSign and Back-Dated SHA-1

在瀏覽器會對 2016 後所簽出直接跳 error 的情況下 (像是「An update on SHA-1 certificates in Chrome」),直接偽造是 2015 年簽出的 certificate。

WoSign’s Ownership of StartCom

Mozilla 的 CA program 要求當公司擁有權轉移時必須揭露:

[...], Mozilla’s program requirements say that a change of CA ownership must be disclosed. In this case, that was not done - and in fact, the change was directly denied a few months after it happened.

直到最近被抓到而揭露後,發現 WoSign 所揭露的也不正確,StartCom 已經開始使用 WoSign 的 infrastructure 了:

More recently, even after the evidence of total control was public, WoSign referred to their interest in StartCom in a press release as “an equity investment”, and maintain that the two businesses continue to be separate even today. They say “the original system ... of StartCom remains unchanged”.

However, there is technical evidence that around a month and a half after the acquisition, StartCom issuances switched to using WoSign’s infrastructure - either the same instance of it, or their own instance.

而 Mozilla 要求 WoSign 提供他們產生 serial number 的程式碼時:(在 WoSign 簽出重複的 serial number 問題時得到的)

Mozilla asked WoSign how they generated their serial numbers, and was told that they used the Java package java.crypto.SecureRandom. They supplied the following code snippet:

[...]

However, as can be seen from this simple test harness, this code snippet does not produce serial numbers matching WoSign’s idiosyncratic pattern.

再度發現 WoSign 給的程式碼對不上。(hey)

然後再多方面分析後發現 WoSign 宣稱跟 StartCom 只共用 CRL/OCSP (revoke 機制) 是假的。Mozilla 由多方面判斷發現,至少程式碼是共用的 (i.e. clone),甚至猜測整個系統都是共用的 (在更後面提到):

We believe that, taken together, all this shows that StartCom’s certificates are now being issued using either WoSign’s existing infrastructure or a clone of it, and that WoSign’s operational control of StartCom began straight after the November 1st 2015 sale date. This evidence should be compared against WoSign’s recent assertion that “Even now, it still independent in the system, in the validation team and management team, we share the CRL/OCSP distribution resource only.”

SHA-1 Exceptions Process

再來是講一些背景。因為金流產業到了 2016 年還是有系統不支援 SHA-256 certificate,而 CA/Browser Forum 已經禁止簽發 SHA-1 憑證了,所以 2016 年二月的時候 WorldPay 跑上來尋求例外:

This became clear in February of 2016, where a payment processor called WorldPay applied to the CAB Forum for an exception so they could acquire 8 SHA-1 certificates to keep SSL working for their legacy payment terminals. Their CA was unable to help them because of the ban in the CAB Forum Baseline Requirements, and to issue in violation of the ban would lead to a “qualified” (not clean) audit, which might lead to browsers no longer accepting their audit as valid to keep them trusted.

而在亞利桑那的 face-to-face meeting 中剛好就討論了這點,允許 Symantec 簽發,而要提出來的是,WoSign 的 Richard Wang 也在場:

This issue was discussed at length in the CAB Forum face-to-face meeting from 16th-18th February 2016 in Scottsdale, Arizona (where Richard Wang of WoSign was present). Mozilla then had a public discussion about it in our policy forum starting on 23rd of February. In the end, the browsers reluctantly agreed to let Symantec issue these certificates for Worldpay - or rather, they agreed to accept that Symantec’s next audit would be qualified in this way.

所以 Mozilla 再次強調,當下大家的結論是特別許可,簽發被禁止的 SHA-1 certificate 是很嚴重違反規定的事情:

Even at this point, in February 2016, it was (or should have been) clear to all CAs, including WoSign, that issuing SHA-1 certificates in violation of the ban was a Very Big Deal, and that permission had to be sought from the browsers in order for the CA not to face difficulty.

Tyro

接下來是 Tyro,這是一家澳洲金流廠商,直接複製草稿上的時間表:

Feb 3rd 2010GeoTrust issues a SHA-1 certificate for *.tyro.com from their Equifax root, valid until May 6th 2013.
Apr 6th 2013A month before their old cert expires, GeoTrust issues a replacement SHA-1 certificate for *.tyro.com from a GeoTrust root, valid until June 7th 2016. A simple roll-over replacement.
Jan 1st 2016SHA-1 issuance ban comes into effect.
May 24th 2016A month before their old cert expires, GeoTrust issues a SHA-256 certificate for *.tyro.com from a GeoTrust root, valid until June 23rd 2019.

但 Tyro 在 2016 年五月拿到的 SHA-256 憑證很明顯不合用,於是試著找 SHA-1 憑證... 結果不管怎樣,後來拿到了 StartCom 所簽出來的 SHA-1 憑證,而藉由技術上的 pattern 可以發現這是 back-dated (偽造日期簽發):

But the strong evidence is that this SHA-256 certificate did not meet Tyro’s needs. We can see a SHA-1 certificate for *.tyro.com which was logged in CT on June 8th 2016, a day after their previous SHA-1 certificate expired. This certificate is not issued by GeoTrust (who still provide the cert for their main website) or Comodo, tyro.com’s usual providers, but by StartCom. And the notBefore date is that magic date of 20th December, 2015 - a date on which, as noted above, StartSSL.com was closed for upgrading, and on which we have seen many Macau certificates issued by WoSign, which we believe are back-dated.

也可以很清楚的確認到現在還在使用:

The SHA-1 certificate in question is still in use today on https://iclient.tyro.com/.

Conculsions

最後 Mozilla 得到的結論:

  • StartCom are using WoSign’s infrastructure (the same or a clone);
  • Certificates on this infrastructure with a notBefore of 2015-12-20 (China time) are indeed back-dated - this further confirms our suspicions about the Macau certificates we saw issued by WoSign; and
  • StartCom’s hierarchy has been directed by management to mis-issue “WoSign-style”.

同時他們認為最後一點是最嚴重的一點,你必須將 StartCom 視為與 WoSign 完全同樣的公司,所有對 WoSign 的檢查與處置都必須相同對應到 StartCom 上:

This last point is important; the practices at WoSign are now being seen at StartCom. Therefore, we conclude that all of ownership, infrastructure and control are sufficiently common between the two companies that it would therefore be reasonable for any action Mozilla chooses to take against WoSign to also be taken against StartCom and vice versa.

另外一個很嚴肅的問題,CA 架構是建立在稽核機制上,而 WoSign 所選擇的稽核單位無法稽核出應有的「多個問題」:

WoSign’s auditors, Ernst & Young (Hong Kong), have failed to detect multiple issues they should have detected. (Issue J, Issue X)

提案的處理方式類似於 CNNIC 當時被拔掉的方式,針對某個日期之後的都不信任。這同時包括了 WoSign 與 StartCom 的 certificate。這真是可喜可賀啊...

Firefox 的大量寫入對 SSD 的影響

在「Firefox is eating your SSD - here is how to fix it」這邊講到 Firefox 寫入對 SSD 的影響,先引用文章裡的解法:

After some digging, I found out that this behavior is controlled by a parameter that you can access through typing “about:config” in the address bar. This parameter is called: —browser.sessionstore.interval

預設是 15 秒一次,作者改成 30 分鐘一次,因此下降了大約 5 倍 (應該可以解讀成 1/6?):

It is set to 15 seconds by default. In my case, I reset it to a more sane (at least for me) 30 minutes. Since then, I’m only seeing about 2GB written to disk when my workstation is left idle, which still feels like a lot but is 5 times less than before.

據文章後面的 update 說明,Google Chrome 也有類似的情況,不過暫時沒給解法...

Firefox 51 (現在是 48) 將會支援 FLAC

Hacker News Daily 上看到 Firefox 要支援無損格式 FLAC 的消息:「Bug 1195723 - FLAC support / Create FLAC MediaDataDemuxer」。

隔壁棚關於 Google Chrome 也有 FLAC 相關的「Support FLAC audio codec」,也是等很久都沒消息,不知道會不會因為 Firefox 有進度後...

現在如果要無損的話只有 WAV 可以用 (話雖如此,IE 還是要到 Edge 才有支援),改用 FLAC 大約可以省下 40% 的大小 (平均值,依照音樂的類型會有不一樣的壓縮率),如果普及的話,不知道 YouTube 之類的服務在轉播音樂會時會不會試著拼看看?

Archives