這方法有種掩耳盜鈴的感覺... (SYN scan 很快的啊)
而即時再過了兩年半，還是沒辦法確認你抓到的 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
在「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.
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.
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.
Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting.
由於等級到了 glibc 這種每台 Linux 都有裝的情況，在不經意的情況下發生 segfault，表示在刻意攻擊的情況下可能會很糟糕，所以 Google 投入了人力研究，想知道這個漏洞到底可以做到什麼程度：
Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!
In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn't immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”
攻擊本身需要繞過反制機制 (像是 ASLR)，但仍然是可行的，Google 的人已經成功寫出 exploit code：
Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post.
技術細節在 Google 的文章裡也有提到，buffer 大小固定為 2048 bytes，但取得時有可能超過 2048 bytes，於是造成 buffer overflow：
glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query.
Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated.
另外 glibc 官方的 mailing list 上也有說明：「[PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow」。
It was discovered that the OpenSSH client experimental support for resuming connections contained multiple security issues. A malicious server could use this issue to leak client memory to the server, including private client user keys.
這下除了要更新以外，要重新生 ssh key 然後更新一堆機器了...
In 2012, James Bamford published an article quoting anonymous former NSA officials stating that the agency had achieved a “computing breakthrough” that gave them “the ability to crack current public encryption.” The Snowden documents also hint at some extraordinary capabilities: they show that NSA has built extensive infrastructure to intercept and decrypt VPN traffic and suggest that the agency can decrypt at least some HTTPS and SSH connections on demand.
但在這之前一直都不清楚是怎麼解出來的，直到最近才猜測應該是 Diffie-Hellman 的強度以及實作問題：「Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice」。
We go on to consider Diffie-Hellman with 768- and 1024-bit groups. We estimate that even in the 1024-bit case, the computations are plausible given nation-state resources. A small number of fixed or standardized groups are used by millions of servers; performing precomputation for a single 1024-bit group would allow passive eavesdropping on 18% of popular HTTPS sites, and a second group would allow decryption of traffic to 66% of IPsec VPNs and 26% of SSH servers. A close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community.
作者群給的建議有三個方向，一個是把長度加長到 2048 bits，另外一個是改用 ECDH，而最差的情況 (如果還是需要使用 1024 bits DH) 則是避免使用固定的 prime number。
這個分析主要用的是 GitHub 的
A little known feature of GitHub is the ability to look at the public SSH keys that other users have set to be authorised on their account (for example https://github.com/torvalds.keys)
作者從去年 2014 年 12 月 27 日跑到今年 2015 年 1 月 9 日，共取得了 1376262 把 public key，然後就針對這些 key 分析。
另外還有 256 bits 與 512 bits 的 RSA key，作者自己建立了一把測試，用 i5-2400 只要 25 分鐘就可以解出 256 bits 的 private key：
This risk isn’t only real if someone had gathered together top of the line mathematicians or supercomputers worth of power, the 256 bit key I factored was factored on a i5-2400 in 25 mins.
[27th December 2014] Key Crawl Started
[28th Feb 2015] Disclosed low bits issue to a peer at GitHub
[1st March 2015] Discovered the weak Debian Keys (and disclosed)
[5th May 2015] Debian keys revoked, emails sent out
[1st June 2015] Weak and low quality keys revoked
在「Huthos VPS Provider: Totally legit, 1000% not a criminal organization.」這篇文章裡，作者因為平常就有弄密罐 (Honeypot)，意外發現這種「業務」：
作者發現有人打進他的 Honeypot 並且留下紀錄，一路追蹤後發現...