IE11 的淘汰計畫

微軟宣佈了淘汰 IE11 的計畫:「The future of Internet Explorer on Windows 10 is in Microsoft Edge」。

標題上方的說明先把重點提出來了:

The Internet Explorer 11 desktop application will be retired on June 15, 2022

不過要注意,Windows 10 LTSC 與 server 版的日期不在這次公告的範圍:

Note: This retirement does not affect in-market Windows 10 LTSC or Server Internet Explorer 11 desktop applications. It also does not affect the MSHTML (Trident) engine. For a full list of what is in scope for this announcement, and for other technical questions, please see our FAQ.

FAQ 裡面看起來 Windows 10 LTSC 與 Server 版應該會照著本身作業系統的維護週期走。

另外在文章裡也有提到 Microsoft 365 產品線只支援到今年八月 17 日 (文字部份出自維基百科的「Internet Explorer 11」):

On August 17, 2020, Microsoft published a timeline indicating that the Microsoft Teams product will stop supporting Internet Explorer 11 on November 30, 2020, and Microsoft 365 products will end Internet Explorer 11 support on August 17, 2021.

對一般使用上影響應該不會太大,因為目前市占率的關係,一般網站使用 Chromium 為底的瀏覽器應該都會動,主要的影響應該是遇到一些古董系統,一定得用 IE 才能使用。

Bootstrap v5 將會拔掉對 IE 的支援

如同標題所說的,Bootstrap 打算拔掉對 IE 的支援,在 GitHub 上的 Pull Request:「v5: drop Internet Explorer support」。

當然下面可以看到有反對意見,不過基本上還是尊重 Bootstrap 團隊做的決定,另外一方面也是現在的選擇多了很多,市場自由競爭總是會看出結果的。

測了一下先前提到的「MVP.css」,本來以為只做 semantic html 的設計,純 css 應該是有機會往下支援到蠻早的版本,結果拿 IE11 一開官網,看起來還是不少東西掛掉了 XD

看起來還得再找找... 也許繼續龜在 v4?

相對路徑的攻擊方式 (Relative Path Overwite,RPO)

在「Large-scale analysis of style injection by relative path overwrite」這邊看到的,記得這個方式不是新方法,不過還是有人會中...

這種攻擊是組合技,基礎是引用 css 或是 js 時使用相對路徑 (像是 static/style.css 這樣的引用法),再加上 https://www.example.com/a.php 這樣的頁面通常也可以吃 https://www.example.com/a.php/,甚至是後面再加東西... 在某些情境下組不出來,但精心策劃後就有機會在頁面上弄出奇怪的 xss 或是其他攻擊了。而論文內列出了常見的的組合:

然後拿 Alexa 的排名來看,其實還是有些站台可以打:

防禦的方式也不算太難,absolute path 是個還不錯的方式:

One option is to use only absolute URLs, taking away the relative path expansion.

base tag 也是個方式 (不過在 IE 上還是有問題):

Alternatively you can specify a base tag, though Internet Explorer did not appear to implement the tag correctly (i.e., was still vulnerable) at the time of the evaluation.

另外作者也提到了 document type 的方式 (看起來是建議用 html5 的 <!DOCTYPE html>),然後 IE 另外做些處理避免失效:

One of the best mitigations is to avoid exploitation by declaring a modern document type that causes rendering in standards compliant mode. This defeats the attack in all browsers apart from IE. For IE it is also necessary to prevent the page being loaded in a frame by using X-Frame-Options , using X-Content-Type-Options to disable ‘content type sniffing,’ and X-UA-Compatible to turn off IE’s compatibility view.

不過大型站台本來就因為業務需求,會把 asset domain 切開 (然後透過 CDN 加速),而且會設計系統讓 programmer 很容易使用這樣的架構,反而因此比較不會用到 relative path,中這個攻擊的機會就低多了...

IE 與 Edge 推出更新,阻擋 SHA-1 憑證

微軟這幾天推出更新,IEEdge 將不會接受 SHA-1 憑證:「Microsoft Makes it Official, Cuts off SHA-1 Support in IE, Edge」。微軟的公告則是在「Deprecation of SHA-1 for SSL/TLS Certificates in Microsoft Edge and Internet Explorer 11」這邊。

根憑證不受影響 (所以企業自己產生的 Root CA 也不受影響):

Beginning May 9, 2017, Microsoft released updates to Microsoft Edge and Internet Explorer 11 to block sites that are protected with a SHA-1 certificate from loading and to display an invalid certificate warning. This change will only impact SHA-1 certificates that chain to a root in the Microsoft Trusted Root Program where the end-entity certificate or the issuing intermediate uses SHA-1. Enterprise or self-signed SHA-1 certificates will not be impacted, although we recommend that all customers quickly migrate to SHA-2 based certificates.

修改 User-Agent 讓 Office 365 服務變快...

Facebook 上看到剛剛在 Hacker News 上熱起來的「Onedrive is slow on Linux but fast with a “Windows” user-agent (2016)」這篇,引用了 2016 年在 Microsoft Community 上的討論:「Onedrive for Business open is very slow on Linux (Chrome/Firefox) but with very fast with a "Windows" user-agent」。

Reddit 的「Office 365 Onedrive looks at user-agent to determine performance.」有更多的討論。

因為工作上也會用到 Office 365,也覺得在 Ubuntu 上用起來超級慢,然後看到有使用者也講了 Linux 下的 Google Chrome 也會有類似的問題:

I just tried this same thing--changing the OS in the user agent--on Chome on Linux. The difference really is incredible. Normally I find 365 to be so slow as to be borderline unusable, now it's almost as quick as Google docs. Even the institutional log-ins for my university are faster.

EDIT: Just to clarify, I was testing specifically the web apps for Word and OneNote hosted by my uni. I tried loading them both in normal tabs and ones where I had changed the OS useragent in Chrome's developer panel. The normal tabs hung badly as usual (30+ seconds to load the UI), while the modified tabs loaded very quickly. I tried this several times, but I suppose YMMV.

所以我也拿「User-Agent Switcher for Chrome」加上 IE11 的 user-agent 後測試:

最明顯的差異就是 redirect 變少了,然後開 Word 與 Excel 的速度變快好多 @_@

在原討論串上的官方回應是:

As Office 365 for Business services(e.g. SharePoint Online, including OneDrive for Business, Exchange Online) are not supported on Linux as shown below, for the best experience, we recommend the operating system listed in the article.

所以只能拿老招出來,把 User-Agent 改成 IE 後就變得超~級~快~

然後最 helpful 的回答是:

Thank you
I go back to Google Apps suite.
DL

棍 XDDD

微軟預定在 2017 年的西洋情人節淘汰 SHA-1 certificate

經過多次改動後,微軟這次宣佈 SHA-1 certificate 將在明年淘汰:「SHA-1 deprecation countdown」。

影響的範圍包括 Internet Explorer 11Microsoft Edge,在 2017 年 2 月 14 日之後不信任 SHA-1 certificate:

Starting on February 14th, 2017, Microsoft Edge and Internet Explorer 11 will prevent sites that are protected with a SHA-1 certificate from loading and will display an invalid certificate warning.

與其他家類似,還是提供了管道讓企業內部建立的 SHA-1 certificate 可以用:

This will only impact SHA-1 certificates that chain to a Microsoft Trusted Root CA. Manually-installed enterprise or self-signed SHA-1 certificates will not be impacted, although we recommend for all customers to quickly migrate to SHA-256.

HTTPS 因為安全性而不能使用 Referrer 的問題

Nuzzel 上看到老文章在討論 HTTPS 環境下因為安全性考量,而不能帶出 Referrer 的問題:「Where did all the HTTP referrers go?」。

原文中「Fixing Referrers in HTTPS: The Meta Referrer」這邊就有提到 HTML5 meta referrer,也就是 W3C 的「Referrer Policy」,問題是到現在還是 Draft 啊...

也因為過了三年,其實 draft 裡面多了不少參數可以用:

  • neverno-referrer 表示不傳。
  • origin 表示只傳 protocol + host 的部份,後面 path 的部份不要傳。
  • defaultno-referrer-when-downgrade 表示當 downgrade 時 (HTTP request 的部份) 不要傳。
  • origin-when-cross-origin 表示當跨站時用 origin 的邏輯,但本站還是用完整的路徑。
  • always 或是 unsafe-url 則是永遠都傳。

其中刪節號表示 W3C 不建議再使用,應該用後者比較新的。

不過因為在 Can I use 上面可以看到 Microsoft Edge 只支援舊的關鍵字 (也就是刪節號的那些),所以還是可以考慮先用舊的關鍵字,讓 Microsoft Edge 也可以被保護到:「Referrer Policy」。

HTML 的 preconnect

在「Preconnect」這邊看到 Preconnect 這個功能,目前在 Mozilla FirefoxGoogle Chrome 以及 Opera 都有支援,用法也很簡單:

<link rel="preconnect" href="//example.com">
<link rel="preconnect" href="//cdn.example.com" crossorigin>

感覺如果要用的話,可以先送出 head 的部分,打 flush 讓瀏覽器先收到後再送出其他部分?不過對 MVC 架構來說好像變複雜了,不知道有什麼設計比較好...

另外一個是 Prerender,目前是 IE11+、Google Chrome 以及 Opera 有支援,看起來也頗有趣的...

微軟讓 Windows 7 與 Windows 8.1 上的 IE11 支援 HSTS

本來只有 Windows 10 的 IE11 有支援 HSTS,而前幾天的更新則是讓 Windows 7 與 Windows 8.1 的 IE11 也支援了:「HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7」。

With today’s monthly security updates (KB 3058515), we’re bringing the protections offered by HSTS to Internet Explorer 11 on Windows 8.1 and Windows 7. HSTS is also available in both Internet Explorer 11 and Microsoft Edge on Windows 10.

這次的更新讓所有主流瀏覽器都支援 HSTS 了,再加上前一篇「Wikimedia (包括維基百科) 推出 HSTS (強制使用 HTTPS)」提到的,愈來愈多人用啦...

然後據 zonble 說,iOS 9 有些東西會 HTTPS only (預設值),該回頭去催自己人支援了 :o

Windows 10 的 IE 將會有 asm.js 支援

Twitter 上看到的:「Bringing asm.js to the Chakra JavaScript engine in Windows 10」。

這樣只剩下 Safari 還沒支援,其他幾個主流瀏覽器都支援了:(出自維基百科「asm.js」條目)

Mozilla Firefox was the first web browser to implement asm.js-specific optimizations, starting with Firefox 22. The optimizations of Google Chrome's V8 JavaScript engine in Chrome 28 made asm.js benchmarks more than twice as fast as prior versions of Chrome.