Tag: dynamic

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 做就就行了...

用 Exodus 打包 Linux ELF 檔案到其他機器上

前幾天在 Hacker News Daily 上看到的工具：「Exodus」，官方的說明是這樣：

Painless relocation of Linux binaries–and all of their dependencies–without containers.

技術上是把 Linux ELF 檔案搬到其他機器上以外，也幫你把對應的 dynamic library 都一起包進去：

  • Finding and bundling all of a binary's dependencies.
  • Launching the binary in such a way that the proper dependencies are used without any potential interaction from system libraries on the destination machine.

而 Linux 的 Kernel 因為有儘量維持 ABI compatibility，應該是不會有太大的問題，除非剛好用到新的 API...

看起來是個除了用 static compile 以外的解法，好像可以來弄弄看 FFmpeg？

在 Linux 下引用 Windows 的 DLL 檔

作者為了在 Linux 下進行安全分析而弄出來的計畫：「Porting Windows Dynamic Link Libraries to Linux」。

作者對 Windows 的架構有不少抱怨 XDDD

Distributed, scalable fuzzing on Windows can be challenging and inefficient. This is especially true for endpoint security products, which use complex interconnected components that span across kernel and user space. This often requires spinning up an entire virtualized Windows environment to fuzz them or collect coverage data.

This is less of a problem on Linux, and I've found that porting components of Windows Antivirus products to Linux is often possible. This allows me to run the code I’m testing in minimal containers with very little overhead, and easily scale up testing.

This is just personal opinion, but I also think Linux has better tools. ¯\_(ツ)_/¯

而這個專案跟 WineHQ 完整模擬不一樣，這只是給 Linux 下原生的程式使用 Windows 下 DLL 內的功能：

This project does not replace Wine or Winelib.

Winelib is used to port Windows C++ projects to Linux, and Wine is intended to run full Windows applications. This project is intended to allow native Linux code to load simple Windows DLLs.

The closest analogy would be ndiswrapper but for userspace.

作者拿了 Windows Defender 當範例，示範在 Linux 下呼叫 Windows 的 DLL...

MySQL 8.0 對 4 bytes UTF-8 的效能改善

在「MySQL 8.0: When to use utf8mb3 over utf8mb4?」這邊提到了 MySQL 對 utf8 以及 utf8mb4 的故事，以及在 MySQL 8.0 預期的效能提昇：

可以看到 Oracle 的團隊花了不少力氣提昇 utf8mb4 的效能。另外提到了在 5.7 的時候將 row format 的預設值轉成 DYNAMIC：

MySQL 5.7 (2015) added some optimizations such as a variable length sort buffer, and also changed InnoDB’s default row format to DYNAMIC. This allows for indexes on VARCHAR(255) with utf8mb4; something that made migrations more difficult prior.

依照「14.11.3 DYNAMIC and COMPRESSED Row Formats」這邊的敘述，看起來 COMPRESSED 也應該支援一樣的特性，不過不確定... （因為通常不會完整 index 整個 VARCHAR(255)，只會 index 某個 prefix length)：

The COMPRESSED row format uses similar internal details for off-page storage as the DYNAMIC row format, with additional storage and performance considerations from the table and index data being compressed and using smaller page sizes.

CloudFront 支援將 Query String 內的特定 Key/Value 當作 Cache Key 的一部分

Amazon CloudFront 可以指定 query string 中的某個特定的 key/value 當做 cache key 的一部分了：「Announcing Query String Whitelisting for Amazon CloudFront」，對應的文件在「Configuring CloudFront to Cache Based on Query String Parameters」這邊可以查到。

先前只能針對選擇忽略掉整個 query string，或是把整個 query string 當作 cache key 的一部分，現在可以細部調整了。

最簡單的應用可以用在 css/js 的 asset 上，針對 v=\d+ 當作 cache key 的一部分，而其他的參數可以忽略，不過這好像沒什麼特別的意義。

目前想到比較有意義的應用是針對 dynamic content 多了一些籌碼可以用，像是 Slack 把整個網站放上 CloudFront 後，應該會有很多 API 是透過 query string 傳遞參數，而這次的改變讓 CloudFront 可以細部調整。

nginx 引入 Dynamic Module 架構

nginx 在 1.9.11 版引入了 Dynamic Module，能夠更方便的決定要掛哪些模組使用了：「Introducing Dynamic Modules in NGINX 1.9.11」。

從以往的：

多了一種選擇：

也因此多了 load_module 功能可以用：

To load a module at runtime, include the new load_module directive in the main context, specifying the path to the shared object file for the module, enclosed in quotation marks. When you reload the configuration or restart NGINX, the module is loaded in. You can specify a path relative to the source directory, as in these examples, or a full path.

load_module "modules/ngx_http_geoip_module.so";
load_module "modules/ngx_stream_module.so";

CloudFlare 對 Brotli 的測試

之前有提過這件事情，由於 Firefox 已經支援 Brotli 了 (Google 推出 Brotli 無損壓縮法)，所以 CloudFlare 的人整理了目前的效能比較：「Results of experimenting with Brotli for dynamic web content」。

主要還是 Brotli 拿了不少資源來換壓縮率，對於 static content 由於可以事先算好而大勝不少 (大約可以再榨出 15% 的壓縮率，從 zlib 9 的 27.7% 降到 brotli 10 的 23.3%)：

The current state of Brotli gives us some mixed impressions. There is no yes/no answer to the question "Is Brotli better than gzip?". It definitely looks like a big win for static content compression, but on the web where the content is dynamic we also need to consider on-the-fly compression.

另外對於大檔案、網路速度不快的連線來說也頗有幫助，但對於 on-the-fly 的壓縮反而會比較慢。

Adobe Typekit 支援 CJK 字型

Adobe Typekit 宣佈支援 CJK 字型：「Announcing East Asian web font support and new font browsing tools for Japanese customers」。中文的公告在「正式公開東亞網頁字體支援以及日文客戶適用的全新字體瀏覽工具」這邊。

這也包括了網頁版的部份。對於 CJK 單一字型檔案過大的問題，與大家的解法也都一樣，取出對應的字組出來給使用者作為 workaround (稱為 Dynamic Subsetting)：

會稱為這是 workaround 是因為當網路速度愈來愈之後，就會又變成最單純的直接整包下載...

Anyway，Adobe 這個新功能是一個大邁進，不過他用的 HTTPS (EdgeCast) 還沒支援 SPDY 或是 HTTP/2 啊... :/

Elasticsearch 1.2.0

由於 Elasticsearch 的想法與實做比起 Solr 吸引人，可以看到愈來愈多團體換過去...

而前幾天 Elasticsearch 的官方放出 1.2.0 與 1.1.2 的消息：「elasticsearch 1.2.0 and 1.1.2 released」。

1.2.0 最大的改變是強制使用 Java 7 了，也就是不能在 Ubuntu 12.04 下安裝 default-jre 了，變成要裝 openjdk-7-jre。(要注意，官方建議的是 Oracle 官方的 JDK，而非 OpenJDK)

如果是 Ubuntu 14.04 就沒這個問題。(因為 default-jre 會裝 Java 7)

另外一個大改變是，之前產生安全問題的 dynamic scripting 預設關掉了，也就是 CVE-2014-3120。

目前我的進度只到看完 mapping，但還沒實際開始塞資料進去玩...

CloudFlare 的速度...

CloudFlare 是一種 CDN 服務，相較於其他 CDN 會被歸類到 Akamai 的 Dynamic Site Accelerator，Limelight Networks 的 Dynamic Site Platform，或是 EdgeCast 的 Application Delivery Network。

這類型的 CDN 加速服務，如果用在完全沒有考慮最佳化的網站上，效果應該會很明顯。但如果拿到 WordPress 或是其他 open source 軟體上，反而會因為軟體已經做了不少處理，上了 CloudFlare 反而因為多了一層而變慢。

不過會變慢多少呢？有人跳下去測試寫報告了：「Cloudflare Showdown」，如果懶得看中間的數據，可以看最後的結論「Conclusion」。

如果用在已經最佳化過的網站上，用 CloudFlare 會慢不少，如果是 WordPress 及其他 open source 軟體，最好的情況是快一點點，但最差的情況會慢個幾倍... 作者下的結論是「不要用」。

跟預期差不多，動態資料的加速基本上是個商業包裝而已，真正需要加速還是得自己把可以 cache 的部份切割出來。