AWS 推出 CloudShell

AWS 推出了 CloudShell,讓使用者可以繼承 IAM 的權限,在瀏覽器裡面用 command line 操作 AWS 資源:「AWS CloudShell – Command-Line Access to AWS Resources」。

使用方式很簡單,在 web console 上方的 icon 點下去就可以用了,只是第一次使用的時候會看到需要建立環境的訊息,會等比較久:

連進去後測了一下,看起來是跑一個 30GB Disk 與 4GB RAM 的 container 起來,/dev/cpuinfo 裡面可以看到是 Intel E5-2676 v3 的機器,以這個資訊來查,看起來可能是 m4 系列的機器。

網路的部份基本上對 internet 的 TCP 與 UDP 都可以通,但需要操作 raw socket 丟 ICMP 的 ping 與 mtr 就不會通了。

目前支援的區域只有這些,之後應該會陸陸續續再開放:

Regions – CloudShell is available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions, with the remaining regions on the near-term roadmap.

費用的部份,官方是說不需要另外的費用,只需要付出用到的 AWS 資源,但這邊沒給範例啊,到底是怎麼算的... 看了一圈 EC2ECSEKS 都沒有機器,應該是不會算到這邊?

Pricing – You can use up to 10 concurrent shells in each region at no charge. You only pay for other AWS resources you use with CloudShell to create and run your applications.

刷了一下的感覺是,對於已經習慣跳板機的人來說好像還好,尤其是 command line 已經用熟了,太習慣用 Ctrl-W 刪字串,而在瀏覽器裡面按下去就會直接出事的情況,還是有點難用...

比較明顯的好處應該是整合了 IAM 的權限,所以在 awscli 下的權限是一樣的,另外對於有些 web console 沒支援的操作可以用這個方法補強,而不需要自己弄機器出來跑。

Cloudflare 拔掉使用 Cookie 分析的功能

這兩則應該可以一起看,雖然相差了兩個多月。

首先是今年九月底的時候提供隱私優先的分析系統:「Free, Privacy-First Analytics for a Better Web」,接下來是最近 (十二月) 宣佈要把 __cfduid 這組 cookie 拔掉:「Deprecating the __cfduid cookie」。

文章裡面沒有提到現在是怎麼偵測的,但我猜是瀏覽器的 fingerprint 資料已經足夠辨識了,不需要用到 cookie,這點可以參考 EFF 的「Cover Your Tracks」。

所以 privacy-first 這件事情也只是程度上而已,為了要防禦 bot,還是得正確辨識出不同的使用者,也就是說,現在不用 cookie 不代表 privacy 就高很多。不過這的確是試著在技術上努力降低疑慮就是了...

真的想要在 internet 上隱藏身份的人還是用 Tor 吧,基本上最少應該拿 Tor Browser,更小心一點應該用 Tails 這類軟體。

Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?

在「Preloading Intermediate CA Certificates into Firefox」這邊看到 Mozilla 的人打算在 Firefox 上預載所有的 Intermediate CA,以降低 HTTPS 連線發生錯誤的作法。這點在 Mozilla 的 Wiki 上也有記錄:「Security/CryptoEngineering/Intermediate Preloading」。

的確如文章裡說的,沒有正確放入 Intermediate CA 是個 server 設定上很常見的錯誤。像是前幾天看到「【茶包射手日記】網站憑證無效案例分析」這篇講的摩斯 https://www.mos.com.tw/ 其實就是這個案例,用 SSL Labs 的工具就可以掃出來問題:「SSL Report: www.mos.com.tw (210.59.225.242)」。

問題出在於沒有送出正確的 Intermediate CA(s),所以在 Android 上找不到一條完整的 trust chain:

不過在 Windows 系統內的 CA store 是可以建立出一條完整的 trust chain,所以 Windows 上的 Microsoft EdgeGoogle Chrome 是不會有問題的 (這兩個都吃系統的 CA store):

Linux 上的 Google Chrome 就會出問題 (這邊會吃 Google 自家的 CA store 資料,就是 Android 那包)。

交叉比對中華電信自家的網站,像是「SSL Report: www.cht.com.tw (2001:b000:1a4:d000:203:75:129:111)」這組,可以看到同樣都叫做「Chunghwa Telecom Co., Ltd. / Public Certification Authority - G2」的 Intermediate CA,但有兩種不同的 SHA256,可以翻到是:「609930eb807ad420afda2a8aa61b67483039168cd766e09942a48bfe7f3bdc10」與「f5fb67c8453eda34dbec8a766574f07a03548c084af2f5e6455ea769608d9ad5」,點入裡面的「Trust」tab 中可以看到中華自己的 CA 與 ePKI 的 CA 都有交叉簽,但卻不是每一個 CA 都有被所有瀏覽器認可,所以在設定的時候就得注意...

話說回來,現在因為 CA/B Forum 的標準有強制要送 CT (Certificate Transparency),的確是有辦法抓出所有的 Intermediate CA 沒錯,但瀏覽器幫使用者預載感覺好像怪怪的?

In essence, Firefox pre-downloads all trusted Web Public Key Infrastructure (PKI) intermediate CA certificates into Firefox via Mozilla’s Remote Settings infrastructure. This way, Firefox users avoid seeing an error page for one of the most common server configuration problems: not specifying proper intermediate CA certificates.

目前大約有 2000 筆資料:

Given this information, we periodically synthesize a list of these intermediate CA certificates and place them into Remote Settings. Currently the list contains over two thousand entries.

這個比較像是 client 端的 hack?

Cloudflare 也要支援 AVIF

Cloudflare 針對 Image Resizing 增加了 AVIF 的支援:「Introducing support for the AVIF image format」。

We've added support for the new AVIF image format in Image Resizing.

照 comment 的地方看起來是 Business 功能,之後有機會下放到 Pro,但免費版應該不會出現:

Kornel Ian K Homan • 15 hours ago
This is part of the Image Resizing feature, which is currently available for Business plans. It's coming to Polish in the near future, which is a Pro plan feature.

這跟「Chrome 85 支援 AVIF」應該有些關係,加上其他瀏覽器也陸陸續續打算要支援,是個先做不虧的感覺...

Chrome 85 支援 AVIF

看到「How to Use AVIF: The New Next-Gen Image Compression Format」這篇在推銷用 AVIF 取代 JPEGWebP

首先是跑去 Can I Use 翻,發現 Google Chrome 85 之後支援了,另外在「Issue 960620: Support AVIF」這邊可以看到對應的 ticket,以及「AVIF Image Decode」這邊有狀態:

Enabled by default (tracking bug) in:
Chrome for desktop release 85

現在的 stabel channel 是 84,所以是下個 release 就會有了。以 Google Chrome 的市占率來說,推出來等於是支援度直接過半... 這點也的確有人批評,不過又是另外一個話題了。

對於不支援 AVIF 的瀏覽器,也有對應的 polyfill 可以上 (用 javascript 去補功能),不過因為是透過 AV1 codec,能夠向下支援的版本還是不多,除非連 AV1 都透過 polyfill 支援:「AVIF (AV1 Still Image File Format) polyfill for the browser」。

另外在寫「WebP 的檔案大小未必比 JPEG 小...」這篇時有提過 AVIF 其實也不是完美的,畢竟是從 video codec 演化來的演算法,對於演算法判斷不重要的部位會掉比較多細節...

GPU.js

前幾天在 Hacker News Daily 上看到的專案:「GPU.js - GPU accelerated JavaScript」,對應的 GitHub 頁面在 gpujs/gpu.js 這邊。

看起來是用 WebGL 接進去的,不過他用來 benchmark 的硬體頗暴力啊:

Hardware: Xeon Gold 5217 + 8 x RTX 2080ti

這邊用了八張 2080Ti,如果一張就大約是 1/8 效能的話,看起來好像還好... 一張 2080Ti 跟 Xeon Gold 5217 跑出來差不多?價錢也在同一個範圍區間...

暫時不知道用途...

libtorrent 要支援 WebTorrent 協定了

一開始是看到「Libtorrent Adds WebTorrent Support, Expanding the Reach of Browser Torrenting」這篇,但看的時候發現裡面把 libtorrentlibTorrent 搞混 (這兩套不一樣,libTorrent 是 rTorrent 作者開發的),就暫時沒管這篇文章了...

剛剛看到「libtorrent adds support for the WebTorrent protocol」這篇,然後回頭去看本來 TorrentFreak 上的文章,發現已經拿掉本來提到的 rTorrent 了。(可以參考 Internet Archive 上的存檔資料 20200709223911)

WebTorrent 的支援對於 BitTorrent 社群算是很大的進展,主要是因為瀏覽器內就算用上 WebRTC 也沒有辦法模擬出 BitTorrent 的協定,所以只能調整協定,也就是這邊提到的 WebTorrent。

但訂了新的協定,最大的問題還是現有的 BitTorrent 程式都不支援 WebTorrent,所以沒辦法享用現有的 ecosystem,變成獨立的系統,對於推廣上面很不利...

而 libtorrent 算是第一個夠大的 library (對應到 client 的數量) 宣佈支援 WebTorrent,這樣用瀏覽器的人就會有更多機會透過 WebTorrent 協定對通了,接下來等更加發佈新版後應該就可以在 WebTorrent 上看到更多節點了...

TLS 憑證的最長時效將從 825 天降到 398 天

在「Reducing TLS Certificate Lifespans to 398 Days」這邊看到才想起來沒寫這篇,這邊發生了一些有趣的事情...

提案是降低 TLS 憑證的有效時效,這件事情一開始是在 CA/B Forum 討論,但經過投票後沒有通過:「Ballot SC22 - Reduce Certificate Lifetimes (v2)」。

從投票記錄可以看到所有的憑證使用方 (包括了許多瀏覽器的廠商) 都贊同,但有大約 2/3 的憑證發行方都反對:

7 votes total including abstentions:

  • 7 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360
  • 0 No votes:
  • 0 Abstain:

33 votes total including abstentions

  • 11 Yes votes: Amazon, Buypass, Certigna (DHIMYOTIS), certSIGN, Sectigo (former Comodo CA), eMudhra, Kamu SM, Let’s Encrypt, Logius PKIoverheid, SHECA, SSL.com
  • 20 No votes: Camerfirma, Certum (Asseco), CFCA, Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy, Izenpe, Network Solutions, OATI, SECOM, SwissSign, TWCA, TrustCor, SecureTrust (former Trustwave)
  • 2 Abstain: HARICA, TurkTrust

然後幾個比較大的憑證使用方 (AppleGoogleMozilla) 在提案被否決後就決定放到自家的規則了:「Apple strong-arms entire CA industry into one-year certificate lifespans」。

從 2020/09/01 開始,如果發出來的憑證超過 398 天就當作是無效憑證,也就是 2020/08/31 是最後一天可以發有效期限為 825 天的憑證,會落在 2022/12/05 失效:

$ date --date='Sep 1 2020 GMT+0000 +825days'
Mon Dec  5 08:00:00 CST 2022

這三家搞下去,就等於是強制性讓這些 CA 到九月就不能賣兩年的憑證了 (雖然還沒看到 Microsoft),這些 CA 一定是在心裡幹爆... XD

在瀏覽器內跑 Python

看到「A Python 3 implementation for client-side web programming」這個專案,在瀏覽器裡把 Python 程式碼用 <script type="text/plain"></script> 包起來,然後掛個 js 進去,就可以在瀏覽器裡面跑 Python 操作 DOM:

Brython is designed to replace Javascript as the scripting language for the Web. As such, it is a Python 3 implementation (you can take it for a test drive through a web console), adapted to the HTML5 environment, that is to say with an interface to the DOM objects and events.

另外在 Brython 3.8.9 performance compared to CPython 3.8.0 這頁也有跟 CPython 的比較 (看起來是用 Firefox 測的),其實速度看起來不慢?我猜是 JS 這邊的軍備競賽把整個引擎弄的超快 XDDD

微軟透過 Windows Update 強制安裝新版 Edge

前幾天在虛擬機內的 Windows 突然被裝了新版的 Edge,發現國外也有報導出來了:「With Edge, Microsoft’s forced Windows updates just sank to a new low」。

這次是 Windows Update 推進來的,即使在 Windows 7 上已經 EoL (2020/01/14),不會有任何安全性更新,微軟也是濫用透過這個方式推進來:

這種方式也都讓大家想到與 antitrust 的關係:

It all immediately made me think: what would the antitrust enforcers of the ‘90s, who punished Microsoft for bundling Internet Explorer with Windows, think about this modern abuse of Microsoft’s platform?

到底會不會觸發呢...