Tag: compression

前陣子在 Black Hat 上發表的 HEIST 攻擊 (對 HTTPS 的攻擊)

又是一個對 HTTPS 的攻擊：「HEIST attack on SSL/TLS can grab personal info, Black Hat」、「New attack steals SSNs, e-mail addresses, and more from HTTPS pages」。

一樣是 Compression 產生的 side-channel attack，只是這次是結合 TCP window size 的攻擊。投影片可以在「HTTP Encrypted Information can be Stolen through TCP-windows (PDF)」這邊看到。

這次的攻擊只需要在瀏覽器上插入 HTTP 產生 HTTPS 的流量，然後從旁邊看 HTTPS 連線的 TCP packet 就可以了，而且對 HTTP/2 也很有效：

而且很不幸的，目前沒有太好的解法，因為所有的攻擊手法都是照著使用者無法發現的路徑進行的 @_@

對於使用者，大量使用 HTTPS (像是 HTTPS Everywhere 這樣的套件)，能夠降低政府單位與 ISP 將 javascript 插入 HTTP 連線，產生 HTTPS 的行為。

而對於網站端來說，全站都隨機產生不同長度的 HTTP header 可能是個增加破解難度的方式 (而且不會太難做，可以透過 apache module 或是 nginx module 做到)，但還是可以被統計方法再推算出來。

不知道有沒有辦法只對 HTTPS 開 javascript，雖然攻擊者還是可以用 <img> 攻擊...

也許以後 HTTP/3 之類的協定會有一區是不壓縮只加密的，避開這類 compression-based attack @_@

MySQL 5.7 中 InnoDB 的 innodb_page_size 在 SSD 硬碟上對效能的巨大影響

在 Percona 的「Small innodb_page_size as a performance boost for SSD」這篇文章裡提到了 MySQL 5.7 的 innodb_page_size 在 SSD 上對效能的差異，主要是這張圖的解釋：

先講一下標示的部份，有三個產品線 (都是 Samsung 的 SSD)，中間的 sam850 是消費級的 SSD 硬碟 (所以不是本次重點)，而 sam863 是企業級 SATA SSD，pm1725 則是企業級 PCI-e SSD。下方的 BP 指的是 Buffer Pool 大小，單位是 GB。左邊是速度，數字愈大愈好。

InnoDB 預設 16KB 的 page size，配合 SSD 大多都是 4KB 的 block size 後，效能的提昇非常巨大 (70% 的提昇)，雖然既有的 InnoDB 要換過去會花不少功夫，但作者還是很建議評估：

I think a 70% performance gain is too significant to ignore, even if manipulating innodb_page_size requires extra work. I think it is worthwhile to evaluate if using different innodb_page_size settings help a fast SSD under your workload.

不過 comment 有不少額外重要的資訊。

有提到 Galera Cluster 目前有 bug，無法使用 4KB page size，可以在「Restarting a cluster with innodb_page_size=4096 segfaults」這邊看到 bug report。

另外有提到，使用 InnoDB Compression 的前提下，4KB 也許不是個好主意，用 8KB 也許是個方向：

You’re right – if you’re using Innodb Compression 4K base page is unlikely to be the good choice. Though we do not see Innodb compression (any of them) being used too frequently.

If using compression 8K base page size with 4K compressed page size might be good idea if 2x compression is routinely reached

不過我覺得應該還是有幫助才對 (可能提昇不高，但想了一下應該不會有負面的影響)，之後有機會再測試看看吧 :o

Dropbox 針對 JPEG 圖片再次「無損壓縮」的 Lepton

Dropbox 針對 JPEG 圖片再次無損壓縮所發展出來的 Lepton：「Lepton image compression: saving 22% losslessly from images at 15MB/s」。

直接用傳統壓縮方式對 JPEG 檔壓縮是沒有用的，他們針對 JPEG 裡的內容分析後再次無損壓縮，並且可以還原成原來的 JPEG：

Lepton achieves a 22% savings reduction for existing JPEG images, by predicting coefficients in JPEG blocks and feeding those predictions as context into an arithmetic coder. Lepton preserves the original file bit-for-bit perfectly.

當檔案夠大時的壓縮率大約就是 22%：

很可觀的數字... 另外 Dropbox 也透漏了至少有 160 億張 JPEG 圖片：

We have used Lepton to encode 16 billion images saved to Dropbox, and are rapidly recoding our older images.

CloudFront 總算支援 gzip 壓縮了...

CloudFront 總算是宣佈支援 gzip 壓縮了：「New – Gzip Compression Support for Amazon CloudFront」。

cloudfront_console_compress_option_1

不過在「Serving Compressed Files」文件裡提到，CloudFront 有可能不壓縮 (居然還有這種的...)：

CloudFront is busy

In rare cases, when a CloudFront edge location is unusually busy, some files might not be compressed.

另外看起來也沒辦法指定壓縮哪些 Content-Type，只能用選好的值。

Amazon Redshift 的新功能 (BZIP2)

Amazon Redshift 也推出了好幾個新功能，不過有個有點奇怪的壓縮格式 bzip2 出現了：「Amazon Redshift announces tag-based permissions, default access privileges, and BZIP2 compression format」。

BZIP2 data format: The COPY command now accepts data in BZIP2 compression format, in addition to GZIP and LZOP formats, when loading data into Amazon Redshift. Refer to Data Format Parameters for more details.

既然出了 bzip2，為什麼不一起出個效率與壓縮率都更好的 xz？但不管怎樣，總是多了一個壓縮率再更高一點的選擇... @_@

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 的壓縮反而會比較慢。

完全關閉 HTTPS 的 gzip

在「Perceived Web Performance – What Is Blocking the DOM?」這邊看到 Google PageSpeed Insights，突然發現我的 nginx 設定還是有打開 gzip，而目前因為 BREACH 攻擊的關係，有 cookie 的 SSL/TLS 下不應該開 gzip：

gzip off;

目前好像沒有比較好的解法可以對抗 BREACH...

對 SHA-1 的攻擊進展

在 Bruce Schneier 這邊看到對 SHA-1 的攻擊又有新的進展了：「SHA-1 Freestart Collision」。

這次的論文不是真的找出 collision，而是對 internal compression function 攻擊，不過即使如此，這是首次攻擊完整的 80 rounds：

We present in this article a freestart collision example for SHA-1, i.e., a collision for its internal compression function. This is the first practical break of the full SHA-1, reaching all 80 out of 80 steps, while only 10 days of computation on a 64 GPU cluster were necessary to perform the attack.

論文資訊可以在「The SHAppening: freestart collisions for SHA-1」這邊看到。

Google 推出 Brotli 無損壓縮法

Google 推出了 Brotli 這個無損壓縮法：「Introducing Brotli: a new compression algorithm for the internet」。

Google 推出的 Zopfli 相容於 DEFLATE 的超慢壓縮演算法，但可以多壓榨出 3%～8% 的壓縮率。而 Brotli 則是重新設計，壓縮與解壓縮速度跟 DEFLATE 差不多，但壓縮率比 Zopfli 多了 20%～26%。

This new format allows us to get 20–26% higher compression ratios over Zopfli. In our study ‘Comparison of Brotli, Deflate, Zopfli, LZMA, LZHAM and Bzip2 Compression Algorithms’ we show that Brotli is roughly as fast as zlib’s Deflate implementation.

由於目標是希望讓瀏覽器支援新的壓縮法，Google 把 Brotli 往 RFC 提案，試著變成公開標準：「Brotli Compressed Data Format」。

看了看 commit log，看起來已經開發一陣子了...

使用 PNG 對圖片失真壓縮...

PNG 是無失真影像壓縮格式，但我們仍然可以修改 pixel (失真) 讓 PNG 壓縮率更好。今天在「PNG can be a lossy format」看到的 Mac OS X 應用程式就是這個用途。

雖然是應用程式，但作者還是有說明 algorithm 是哪些，分別是從哪裡來。其中兩個是：

文章最後，作者對 GIF 很感冒... XD

GIF has antiquated compression and it's a complete waste of bandwidth. Even lossy GIF is worse than lossless optimized PNG.

另外，JPEG/WebP 還是比較小，不過 JPEG 有很多格式，瀏覽器與作業系統的支援度還是很大的阻礙：

Whether lossy PNG gives better results than JPEG depends on the image. JPEG often gives smaller files, except when image has sharp edges (e.g. text) or any transparency (which JPEG does not support at all).

Optimized lossy PNG is still a bit larger than lossy JPEG-XR/WebP/JPEG-2K, but unlike these formats it's supported by all browsers and operating systems without any fuss or hacks.

最後發現 lossypng 是 Go 寫的，程式碼也不長，看起來頗好玩的... (也許包成 ports？)