CloudFront 支援 JA3 資訊 (SSL/TLS fingerprint)

看到 CloudFront 宣佈支援帶入 JA3 資訊了:「Amazon CloudFront now supports JA3 fingerprint headers」:

Details: Amazon CloudFront now supports Cloudfront-viewer-ja3-fingerprint headers, enabling customers to access incoming viewer requests’ JA3 fingerprints. Customers can use the JA3 fingerprints to implement custom logic to block malicious clients or allow requests from expected clients only.

JA3 的頁面上可以看到說明,針對 SSL/TLS 這個複雜的 handshake 過程中,就可以從中得知不同的 client 實做,比起容易偽造的 User-agent 有效:

JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.

像是 Tor 的 SSL/TLS 連線就會有對應的 fingerprint 可以偵測:

JA3 fingerprint for the standard Tor client:
e7d705a3286e19ea42f587b344ee6865

先前在「修正 Curl 的 TLS handshake,避開 bot 偵測機制」裡面提到的 curl-impersonate 就是反制這類偵測的方式。

AWS 開西班牙區

前幾天才寫了 AWS 開了中歐的瑞士 (在「AWS 加開中歐區 (瑞士,蘇黎世)」這邊),剛剛看到開了西班牙:「Now Open–AWS Region in Spain」。

注意到代碼不是掛在西歐 (eu-west),而是南歐 (eu-south),然後「Regions and Zones」這頁居然還沒更新...

另外機種比瑞士的豐富一些,像是 t4gr6g 這些 ARM 的機種。

歐洲的機房突然變好多,反倒是美洲暫時沒有新的大消息... (大家都愛 us-east-1 的關係?)

AWS 加開中歐區 (瑞士,蘇黎世)

AWS 在瑞士蘇黎世開了新的區域,代碼 eu-central-2:「A New AWS Region Opens in Switzerland」,其中代碼 eu-central-1 是德國,這次的歐洲中不稍微往南邊一點開。

I am pleased to announce today the opening of our 28th AWS Region: Europe (Zurich), also known by its API name: eu-central-2.

歐洲的 region 愈來愈多了,但可以看出來東歐一直還沒有點,不過以目前戰火的情況看起來應該不會太快...

Amazon EC2 AMI 的 root volume 可以直接抽換了

這個功能等了十年以上總算是出現了,Amazon EC2 的 AMI 總算是能直接抽換 root volume,不用先停掉機器:「Amazon EC2 enables easier patching of guest operating system and applications with Replace Root Volume」。

Starting today, Amazon EC2 supports the replacement of instance root volume using an updated AMI without requiring customers to stop their instance. This allows customers to easily update their applications and guest operating system, while retaining the instance store data, networking and IAM configuration.

算是 pre-container 時代會遇到的問題,後來大家都把 workaround 變成 practice 了:每次需要時候都是直接整包重新打包 (像是 Packer 這類的工具),然後用工具更新 AMI id 改開新的機器,這樣就能夠避開需要先停掉現有機器的問題...

怎麼會突然想到要回來支援這個功能 XD

Netflix 在 2013 年 Open Connect Appliances

Reddit 上的原文在「So I got a Netflix cache server...」這邊,但看起來作者自己刪掉內容了 (可能是被接觸要求刪掉?),可以看 Internet Archive 上的「20221026080226」,以及報導「How a Redditor Ended Up With an Industrial-Grade Netflix Server」。

所以是 Netflix 退役的機器,看起來適合法取得的?

I work for a large ISP, and we are retiring/replacing quite a few 2013 era Netflix OCA caches, and I was offered one. Of course, I couldn't say no 😅

資料當然是被清過的:

I knew that Netflix had wiped them all in the decommissioning process, that they ran FreeBSD, that they were crammed full of drives, and that's about it.

然後這台 2013 年的機器以現在的角度來看也算很大台,尤其是看到硬碟的部份是 36 顆 HGST 的 7.2TB 硬碟:

36x 7.2TB 7200RPM HGST's

再加上 4 個 10Gbps 的界面可以接:

One 4x 10G SFP+ NIC

作者後來裝了 TrueNAS 來用,就這些規格資料看起來的確是個很適合當 NAS:

I expected some resistance when trying to install an OS, but it was already set to boot from USB and took a TrueNAS install like a champ!

但不確定會吃多少電,放在家裡用還是得考慮這點... 不然就是當紀念品收起來。

Amazon EC2 的 Trn1 正式開放使用

AWS 自家研發晶片的 trn1.* 上線了:「Amazon EC2 Trn1 Instances for High-Performance Model Training are Now Available」。

先前三家雲端的廠商只有 Google Cloud PlatformTPU 可以 train & evaluate,現在 AWS 推出 AWS Trainium,補上 train 這塊的產品。其中官方宣稱可以比 GPU 架構少 50% 的計算成本:

Trainium-based EC2 Trn1 instances solve this challenge by delivering faster time-to-train while offering up to 50% cost-to-train savings over comparable GPU-based instances.

然後 PyTorchTensorFlow 都有支援:

The Neuron plugin natively integrates with popular ML frameworks, such as PyTorch and TensorFlow.

另外用 neuron-ls 可以看到 Neuron 裝置的資訊,不過沒看懂為什麼要 mask 掉 private ip 的資訊:

大型的 cluster 會使用 Amazon FSx for Lustre 整合提供服務:

For large-scale model training, Trn1 instances integrate with Amazon FSx for Lustre high-performance storage and are deployed in EC2 UltraClusters. EC2 UltraClusters are hyperscale clusters interconnected with a non-blocking petabit-scale network.

但第一波開放的區域有點少,只有萬年美東一區 us-east-1 與美西二區 us-west-2

You can launch Trn1 instances today in the AWS US East (N. Virginia) and US West (Oregon) Regions as On-Demand, Reserved, and Spot Instances or as part of a Savings Plan.

us-east-1trn1.2xlarge 的價錢是 US$1.34375/hr,但沒有實際跑過比較好像沒辦法評估到底行不行...

但總算是擺出個產品對打看看,畢竟要夠大才能去訂製這些東西。

AWS 東京區有 12TB 記憶體的機器了

月初 AWS 宣佈東京區有 u-12tb1.112xlarge 可以用了:「Amazon EC2 High Memory instances with 3, 6, 9, and 12TiB of memory are now available in Asia Pacific (Tokyo) region」。查了一下 on-demend 的價錢是 $131.733/hr,如果一個月以 720 小時來算,要 $94847.76/mo...

沒記錯的話,這種機器應該是要另外申請 limit 才能開,沒辦法說測就測。另外在公告裡面有提到 savings plan ,但沒提到 RI (reserved instance),不確定是不是還沒開 RI 讓使用者買 (不過我記得 savings plan 好像也有類似的折扣結構):

Starting today, Amazon EC2 High Memory instances with 3TiB (u-3tb1.56xlarge), 6TiB (u-6tb1.56xlarge, u-6tb1.112xlarge), 9TiB (u-9tb1.112xlarge), and 12TiB of memory (u-12tb1.112xlarge) are available in Asia Pacific (Tokyo) region. Customers can start using these new High Memory instances with On Demand and Savings Plan purchase options.

這種機器是用暴力解決問題的機器...

Amazon CA 在 renew 時將引入動態的 Intermediate CA

上個月 AWS 發的公告,其實已經生效了,但整理的時候才發現還沒寫:「Amazon introduces dynamic intermediate certificate authorities」。

先介紹一下 Amazon CA,這是 Amazon 自己維護的 Root CA,有走過 CA/Browser Forum 的規範與稽核,以及各家瀏覽器額外的要求,所以是個用戶端預設都有信任的 CA。

這個服務後來也被用在 AWS Certificate Manager (ACM) 上,由 ACM 申請到的憑證也都可以掛到 AWS 的各種服務上。

通常 root CA 的憑證不會直接拿來簽最終使用者使用的憑證 (leaf certificate),而是 root CA 的憑證先簽 intermediate CA 的憑證,然後 intermediate CA 可能有好幾層一路簽下來,到最後面再用 intermediate CA 的憑證簽最終使用者使用的憑證。

這次公告的內容就題到了,之前的 intermediate CA 是一個固定範圍的量,而且會確保 renew 時用的 intermediate CA 跟先前的是相同的:

Before this change, Amazon maintained a limited number of intermediate CAs and issued and renewed certificates from the same intermediate CAs.

這次則是會變成動態:

With this change, leaf certificates issued to you will be signed by different intermediate CAs.

生效日期是這個月十一日,其實已經生效了:

Starting October 11, 2022 at 9:00 AM Pacific Time, public certificates obtained through ACM will be issued from one of the multiple intermediate CAs that Amazon manages.

一般的用戶端 (像是瀏覽器) 基本上應該是不會有問題,因為大多數預設都是信任 root CA,而非 intermediate CA,而這次的改變還是可以從 root CA 產生出對應的 trust chain。

官方有提到一個有可能的情況:如果你的應用程式有設定 certificate pinning 的話,應該是對 root CA 設定,而非對 intermediate CA 或是 leaf 做:

If you use intermediate CA information through certificate pinning, you will need to make changes and pin to an Amazon Trust Services root CA instead of an intermediate CA or leaf certificate.

這個也算通則,因為就 certificate pinning 想要做到的效果,對 root CA 做就就行了...