integrity

Amazon S3 支援 MD5 以外的檢查演算法了

Amazon S3 宣佈支援 MD5 以外的檢查演算法了：「New – Additional Checksum Algorithms for Amazon S3」。

In particular, you can specify the use of any one of four widely used checksum algorithms (SHA-1, SHA-256, CRC-32, and CRC-32C) when you upload each of your objects to S3.

雖然有拿 cryptographic hash function 來用，但其實是當作 checksum algorithm 在用，拿來檢查檔案正確性的，而不是防中間被竄改之類 (這個部份是靠 HTTPS)，本來支援的 MD5 應該算是夠用，只是現在多了不少選擇。

然後全商用區都可以用了：

The four additional checksums are now available in all commercial AWS Regions and you can start using them today at no extra charge.

從 Homebrew 換用 MacPorts...

看到「Thoughts on macOS Package Managers」這篇的介紹，文章作者在裡面提到從 Homebrew 換用 MacPorts 的幾個原因...

裡面有提到 root 權限的問題 (Homebrew 的 workaround)，以及軟體豐富度的問題 (常用的應該都有，這邊的差異會是冷門一些的軟體)。不過這些大概都是之前都已經知道的... 比較新的是目前維護者在 integrity 上的問題：

用「How to uninstall Homebrew?」這邊的方法移除 Homebrew 後，再去 MacPorts 官網上下載檔案安裝，跑一陣子看看會不會有什麼問題...

目前看起來比較大的問題都是出自 /opt/local/{bin,sbin} 架構，這個可以靠在 /etc/profile 裡面設定解決 (不是很愛這個方法，但至少這樣會動...)。

在 ext4 上的 CCFS

在「Application crash consistency and performance with CCFS」這篇看到的東西。

CCFS 目標是拉高 ext4 的 data integrity，並且還是有高效能：

CCFS (the Crash-Consistent File System) is an extension to ext4 that restores ordering and weak atomicity guarantees for applications, while at the same time delivering much improved performance.

如果你需要絕對的 data integrity，你需要用 data=journal 確保資料可以在 system crash 後被 replay，預設的 data=ordered 是無法達到的，而 CCFS 也沒打算達到絕對的 data integrity，而是盡量達到。所以在測試上可以發現 CCFS 大幅改善了 data integrity：

而效能還提昇了 (喂喂)：

這真是太神奇了...

翻了一下好像沒 open source 出來 (至少現在沒看到)，來等看看有沒有人會實做出來...

用 mRemoteNG 取代 PuTTY

由於架構的隔離政策，有些服務需要透過 VM 裡面的 Windows 存取，所以又花了點時間看看 PuTTY 到底有沒有改善下載問題，也就是 2014 年「Downloading Software Safely Is Nearly Impossible」這邊作者提到的問題 (之前在「如何安全下載軟體...」這篇有提過)。

而即時再過了兩年半，還是沒辦法確認你抓到的 PuTTY 是正確的，Let's Encrypt 還是沒上...

找了一些替代方案，看到 mRemoteNG 這個可以連多種不同 Protocol 的專案，應該會是解法，裝起來用了一陣子感覺還算 okay，之後應該會拿這個用：「mRemoteNG is the next generation of mRemote, open source, tabbed, multi-protocol, remote connections manager.」。

話說回來，找資料的時候發現「simon-git: putty-website (master): Owen Dunn」這篇，在三月提到了：

Switch to https for release binary downloads from the.earth.li

The main PuTTY website is still http until chiark sorts out
LetsEncrypt or other SSL arrangements, but I think we can sensibly
switch to https for the release binaries from the, which already
provides https.

後續好像就沒有進度了...

Stripe 所提到的 TLS 1.1 不安全

Stripe 在宣佈要淘汰 TLS 1.0 與 TLS 1.1 的計畫公告中 (「Upgrading to SHA-2 and TLS 1.2」) 提到了：

Why SHA-1, TLS 1.0 and 1.1 are insecure

但在文章裡面還是沒有提到為什麼 TLS 1.1 不安全。

在維基百科的「Transport Layer Security」條目中試著找內容，發現應該是 Data integrity 這段，TLS 1.1 不支援 HMAC-SHA256/384 與 AEAD，只支援比較弱的 HMAC-MD5 或是 HMAC-SHA1。

HTTPS 的好處

在 Akamai 網誌上的 PR 文章「The move to an Encrypted Web」提到使用 HTTPS 的好處，其中的「Improve data integrity」這點不僅僅是對使用者有好處，另外站在這兩年把 KKBOX 轉向 HTTPS 化時，使得被 ISP 干擾的問題消失。

早期 KKBOX 的服務都是走 HTTP (包括網站與 API)，三不五十就會遇到使用者抱怨登入會失敗，或是某些功能有問題。實際透過 TeamViewer 追蹤會發現 HTTP traffic 被 ISP 改掉了。

取自「Comcast Wi-Fi serving self-promotional ads via JavaScript injection」

從 2013 年買 CDN 服務時要求包含 HTTPS (圖片與 assets)，然後升級 load balancer 並且先設定 HTTP 與 HTTPS 都可以用，然後到 2015 年一路改寫 (包括 server 的支援與 client 的改寫)，到 2016 總算把大部份的服務 (API 與網站) 都搞定了。

這其實也歸功於目前其他大多數服務都已經上 HTTPS (包含了網站與 IM)，所以 port 80 + port 443 已經變成現代防火牆一定要打開的部份，不然很多服務會沒辦法使用。比起十年前有些單位會擋 port 443 已經好很多。

對 RD 來說，是個換過去就不會想要換回來的情況...

Mac OS X El Capitan (也就是 10.11 版) 上跑 Homebrew 的問題

在新版 Mac OS X El Capitan (10.11) 上因為引入了「System Integrity Protection (SIP)」而導致 /usr、/System 以及 /bin 被保護無法寫入 (即使你使用 root 權限)。

這會使得 Homebrew 無法安裝軟體，所以在 Homebrew 的說明文件裡給對應的解決方式 (關閉 SIP 的方式)：「El Capitan & Homebrew」。

不知道之後會不會移到其他目錄下...

Subresource Integrity

GitHub Engineering 的「Subresource Integrity」這篇提到了新的 W3C 提案「Subresource Integrity」。

其實就是要做這件事情：

<script src="https://example.com/example-framework.js"
        integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg="
        crossorigin="anonymous"></script>

可以確保 CDN 被攻陷時還有一定程度的抵抗力。在 MDN 上的「Subresource Integrity」也可以參考。

目前 Google Chrome 45+ (stable 版) 與 Firefox 43 (目前是 Nightly 版) 有支援。