GitHub 停用過時加密演算法的計畫

先前有提到 GitHub 廢除 SSH 中的弱演算法 (參考「GitHub 明年關閉 SSH 上 SHA1 相關的 Kx (Key Exchange) 演算法」),現在宣佈詳細作法了:「Weak cryptographic standards removal notice」。

包括 HTTPS 的 TLSv1/TLSv1.1 以及 SSH 的 diffie-hellman-group1-sha1/diffie-hellman-group14-sha1 都會被廢止。而作法跟其他家不太一樣:

  • February 8, 2018 19:00 UTC (11:00 am PST): Disable deprecated algorithms for one hour
  • February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms


GitHub 明年關閉 SSH 上 SHA1 相關的 Kx (Key Exchange) 演算法

GitHub 定下落日條款了:「Weak cryptographic standards deprecation update」。

這次目標是 diffie-hellman-group1-sha1diffie-hellman-group14-sha1,同時啟用了 diffie-hellman-group-exchange-sha256

Since the announcement, we have been focusing on the impact of disabling the diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 key exchanges for SSH. As of last week, we have enabled diffie-hellman-group-exchange-sha256. This key exchange method is widely supported and will allow most legacy clients to seamlessly transition away from diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1.

明年二月拔掉 diffie-hellman-group1-sha1diffie-hellman-group14-sha1

This is a very small percentage of traffic, but we would like to see if we can reduce the incompatible traffic percentage even further before disabling support for the older key exchange algorithms on February 1, 2018.

AWS CodeCommit 總算支援東京區了...

AWS CodeCommit 宣佈支援東京、新加坡、雪梨、法蘭克福四個區域了:「AWS CodeCommit is Now Available in Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney), and EU (Frankfurt) Regions」。

AWS CodeCommit 算是純 Git Hosting 的服務,但可以很容易跟 Lambda 之類的東西整合,所以要串其他的服務也不難。之前一直沒用主要還是會抱怨他的 latency...

比較特別的地方是 SSH username 的地方需要用他產生出來的 name,需要在 ~/.ssh/config 裡面設定,會比較麻煩一些,其他的到是還好。

然後由於 SSH 是採用 Trust on first use 的概念,不像是透過 PKI 稽核架構有 Root CA,所以 AWS 有提供每個區域 CodeCommit 的 SSH Fingerprint,包括了 MD5 與 SHA256 的值:「Setup Steps for SSH Connections to AWS CodeCommit Repositories on Linux, macOS, or Unix」。

前五個 active user 提供這樣的量,對於個人應該是夠用:

Unlimited repositories
50 GB-month of storage
10,000 Git requests/month


$0.06 per GB-month
$0.001 per Git request

是可以考慮把一些 Private Repository 從 GitHub 上搬出來了... (當初買 GitHub 是因為他的穩定度比 Bitbucket 以及 都好不少)

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 的功能了...

SSH 在 Port 22 的故事

雖然現在全世界都在用 OpenSSH,但當初 SSH 其實是 SSH Communications Security 所發展出來的。最近上面在講當初申請 port 22 的故事:「How SSH Port Became 22」。

選 port 22 是因為剛好要取代 port 21 的 ftp 與 port 23 的 telnet:

Anyway, I designed SSH to replace both telnet (port 23) and ftp (port 21). Port 22 was free. It was conveniently between the ports for telnet and ftp. I figured having that port number might be one of those small things that would give some aura of credibility. But how could I get that port number? I had never allocated one, but I knew somebody who had allocated a port.

而後來就寫信去要 port 22 這個位置...

GitHub 決定在 2018/02/01 停用不安全的 HTTPS/SSH 演算法

在「Discontinue support for weak cryptographic standards」這邊訂了日期,2018/02/01 將會關閉:

看起來最苦的應該是 Android 4.3 以及更早的版本,以現在的官方數字來看還有 13%+ (Dashboards),這些版本內建的瀏覽器不支援 TLSv1.2,不過另外裝 browser 就還能過...

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


OpenSSL 的 DSA 被 Side-channel attack 打爆

在「Make Sure DSA Signing Exponentiations Really are Constant-Time」這篇文章裡面,直接透過 end-to-end 的 timing attack 打爆 (也就是透過 internet 觀察攻擊),而不需要在同一台機器上對 cache 之類的區域攻擊:

A unique feature of our work is that we target common cryptographic protocols. Previous works that demonstrate cache-timing key-recovery attack only target the cryptographic primitives, ignoring potential cache noise from the protocol implementation. In contrast, we present end-to-end attacks on two common cryptographic protocols: SSH and TLS. We are, therefore, the first to demonstrate that cache-timing attacks are a threat not only when executing the cryptographic primitives but also in the presence of the cache activity of the whole protocol suite.

而且次數相當的少,就可以 key recovery:

260 SSH-2 handshakes to extract a 1024/160-bit DSA host key from an OpenSSH server, and 580 TLS 1.2 handshakes to extract a 2048/256-bit DSA key from an stunnel server.

CVE 編號為 CVE-2016-2178OpenSSL 全系列 (包括 fork 出去的版本) 與 OpenSSH 只要是 DSA 的實作都中獎...

關於 Juniper ScreenOS 防火牆被放後門的研究

一樣是從 Bruce Schneier 那邊看到的:「Details about Juniper's Firewall Backdoor」,原始的研究連結在「Cryptology ePrint Archive: Report 2016/376」這邊。

ScreenOS 被放了兩個後門,一個是 SSH 的後門:

Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker.

另外一個是「Dual EC 的 Q 值」被放了後門,而「NIST 所制定的 Dual EC 的 Q 值」本身就是個後門,所以有人把這個後門又給換掉了:

The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator's output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack.

第二個後門更發現嚴重的問題,Juniper 所宣稱的反制措施根本沒被執行到:

In this work, we report the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. Due to apparent flaws in the code, Juniper's countermeasures against a Dual EC attack are never executed.

也因此團隊確認選定 Q 值的人可以輕易的成功攻擊 IPSec 流量:

Moreover, by comparing sequential versions of ScreenOS, we identify a cluster of additional changes that were introduced concurrently with the inclusion of Dual EC in a single 2008 release. Taken as a whole, these changes render the ScreenOS system vulnerable to passive exploitation by an attacker who selects Q. We demonstrate this by installing our own parameters, and showing that it is possible to passively decrypt a single IKE handshake and its associated VPN traffic in isolation without observing any other network traffic.