OpenSSH 完全移除 SSHv1 的程式碼

在「OpenSSH Removes SSHv1 Support」這邊看到 OpenSSH 拔掉 SSHv1 程式碼的消息。

In a series of commits starting here and ending with this one, Damien Miller completed the removal of all support for the now-historic SSHv1 protocol from OpenSSH.

在新的 distribution 裡引入新版 OpenSSH 時就不會有 SSHv1 的功能了...

收 Wikimedia (包括維基百科) 的 Recent Changes

所以有新的 streaming protocol 取代本來的 RCStream:「Get live updates to Wikimedia projects with EventStreams」。

這次新的 protocol 是走標準協定:

EventStreams is built on the w3c standard Server Sent Events (SSE). SSE is simply a streaming HTTP connection with event data in a particular text format. Client libraries, usually called EventSource, assist with building responsive tools, but because SSE is really just HTTP, you can use any HTTP client (even curl!) to consume it.

直接用瀏覽器打開也可以看到一直冒出來新的訊息...

用 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.

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

CloudFlare 放出可以同時支援 HTTP/2 與 SPDY 的 nginx patch

CloudFlare 放出可以同時支援 HTTP/2SPDYnginx patch:「Open sourcing our NGINX HTTP/2 + SPDY code」。

不過 patch 的版本有點舊:

We've extracted our changes and they are available as a patch here. This patch should build cleanly against NGINX 1.9.7.

如同原文下面 comment 提到的問題,nginx 1.9.7 太舊了 (2015/11/17 放出的版本),到現在有出了不少安全性更新,以及對 HTTP/2 的 bugfix。應該會需要再等官方把新版的 patch 拿出來改之後才能用。

Amazon 之前放出的 s2n 的安全性問題

Amazon 之前放 s2n 出來當作 TLS protocol 的方案,於是就有人摸出東西來:「Lucky Microseconds: A Timing Attack on Amazon's s2n Implementation of TLS」。

即使是經過外部資安檢證,仍然還是有找到問題。這次找到的問題是 timing attack 類在 CBC-mode 下的 plaintext recovery:

At the time of its release, Amazon announced that s2n had undergone three external security evaluations and penetration tests. We show that, despite this, s2n - as initially released - was vulnerable to a timing attack in the case of CBC-mode ciphersuites, which could be extended to complete plaintext recovery in some settings.

攻擊分成兩個階段:

Our attack has two components. The first part is a novel variant of the Lucky 13 attack that works even though protections against Lucky 13 were implemented in s2n. The second part deals with the randomised delays that were put in place in s2n as an additional countermeasure to Lucky 13. Our work highlights the challenges of protecting implementations against sophisticated timing attacks.

最後還是酸了一下 Amazon:

It also illustrates that standard code audits are insufficient to uncover all cryptographic attack vectors.

Amazon 的官方說明則在「s2n and Lucky 13」這邊可以看到。

OCSP stapling

OCSP (Online Certificate Status Protocol) 是用來檢查 SSL certificate 是否被撤銷的方法。OCSP server 接受 HTTP POST 後,回答 client 這個 SSL certificate 是否仍然有效。

對於 client 來說,這主要有兩個問題:

  • client 需要多花時間連到 OCSP server 確認。
  • 隱私問題:OCSP server 會知道「這個使用者試著連到使用這個 SSL certificate」的資訊。

而對於 OCSP server 來說,這個方法的 scalability 很差,熱門的站台會產生大量的流量打進 OCSP server。

OCSP stapling 則是解決這個問題的方法。藉由 server 向 OCSP server 要一次 OCSP response 後,直接傳回 OCSP response 給 client (通常是 browser) 避開了上面的問題。這個方法也逐漸在普及了:(取自英文版維基百科文章內的說明)

OCSP stapling has not seen broad deployment to date, however this is changing. The OpenSSL project included support in their 0.9.8g release with the assistance of a grant from the Mozilla Foundation.

Apache HTTP Server supports OCSP stapling since version 2.3.3, the nginx web server since version 1.3.7, and LiteSpeed Web Server since version 4.2.4. and Microsoft's IIS since Windows Server 2008

On the browser side, OCSP stapling was implemented in Firefox 26 and in Internet Explorer since Windows Vista.

所以已經有不少 client 與 server 都支援了...

擋 Open Redirect 的問題...

Open Redirect 的問題可以參考:

這兩個連結。主要是要避免 phishing 的問題上。

一開始是以「只允許 / 開頭」為條件過濾,但 protocol-relative 的 //www.example.com 可以繞開。

如果變成「只允許 / 開頭,但不允許 // 開頭」,是不是就沒事了呢?

在「Evolution of Open Redirect Vulnerability.」這邊又看到新招:「/\www.example.com」。

想要用 parse_url() 檢查?沒問題:

$ php -a
Interactive mode enabled

php > var_dump(parse_url("/\\www.example.com"));
array(1) {
  'path' =>
  string(17) "/\www.example.com"
}

但實際測試會發現 IE8 與 Google Chrome 都會跳到 www.example.com (沃槽),其他瀏覽器就先不測了 ~_~

不過原文說的 ///www.example.comPHP 上測試應該是不會過的?

$ php -a
Interactive mode enabled

php > var_dump(parse_url("///www.example.com"));
bool(false)

反正又冒出一堆問題要處理了 ~_~

WebFinger 協定

Finger 是個 1977 年發展的協定 (RFC 742 - NAME/FINGER,以及 1991 年的 RFC 1288 - The Finger User Information Protocol),現在幾乎廢棄不用了...

2013 年,基於 OpenID 協定的 WebFinger 出現了!而且是進入 Standards Track 狀態了:「WebFinger is now RFC 7033!」。

用了 OpenID 基礎以及 JSON 格式... 看起來 blog 可以先支援?至於其他的東西就還要再想想...

OCSP 是如何影響 HTTPS 的效率...

Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability,然後發現各家 OCSP 的穩定性都不太好:「Certificate revocation and the performance of OCSP」。

OCSP 是 Online Certificate Status Protocol 的縮寫,當 HTTPS 連線建立中,client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制,因為已經發出去的簽名是無法被收回的,只好靠連線時再查詢。

另外一個機制比較舊,叫 CRL (Certificate Revocation List),則是屬於清單類的機制,更新速度比 OCSP 慢。

目前是以 OCSP 為主,而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。

可以看到 OCSP 檢查打開後對於速度的影響,有的影響很明顯,有的還好。而原文下面很多張 uptime 圖表也可以看出來各家 OCSP 的穩定性其實不怎樣,有些是直接上 Akamai 解決,有些是上 CloudFlare 解決 (然後遇到幾次 CloudFlare 爆炸就跟著炸 XD)

目前瀏覽器大多都是 soft-fail,也就是查不到就當作 pass。照目前的穩定性要推動 hard-fail (查不到就 break) 應該是頗有難度...

對於 HTTPS 速度很在意的人可以看一下內文的說明,可以挑 OCSP 速度比較快的幾家簽,對速度會有幫助...