這次看到的是針對 TLS 實做上的問題產生的 Raccoon Attack，反正先取個名字就對了，原圖有點大張，設個 medium size 好了 XDDD：
Why is the attack called "Raccoon"?
Raccoon is not an acronym. Raccoons are just cute animals, and it is well past time that an attack will be named after them :)
先講影響的產品，首先是經常中槍的 F5，這次連 timing measurement 都不需要太準確就可以打穿：
In particular, several F5 products allow executing a special version of the attack, without the need for precise timing measurements.
OpenSSL 的部份因為從 1.0.2f 之後因為其他的 security issue 所以改善了實做方式，就不會受到這次的攻擊手法影響。
剛剛翻了一下 Ubuntu 上的的資料，看起來 16.04 (xenial) 上的 OpenSSL 就已經是 1.0.2g 了，所以目前只要是有在 Ubuntu 支援的版本應該都不受影響：
OpenSSL assigned the issue CVE-2020-1968. OpenSSL does use fresh DH keys per default since version 1.0.2f (which made SSL_OP_SINGLE_DH_USE default as a response to CVE-2016-0701).
Firefox 直接拔了 DH 與 DHE 相關的 cipher suite，反正在這次攻擊手法出來前本來就已經計畫要拔掉：
Mozilla assigned the issue CVE-2020-12413. It has been solved by disabling DH and DHE cipher suites in Firefox (which was already planned before the Raccoon disclosure).
微軟的部份則是推更新出來：
Microsoft assigned the issue CVE-2020-1596. Please refer to the Microsoft Security Response Center portal.
回到攻擊手法，這次的問題是因為 DH 相關的實做造成的問題。
TLS 要求去掉 premaster secret 裡開頭的 0，造成會因為開頭的 0 數量不同而實做上就不會是 constant time，所以有了一些 side channel information 可以用：
Our Raccoon attack exploits a TLS specification side channel; TLS 1.2 (and all previous versions) prescribes that all leading zero bytes in the premaster secret are stripped before used in further computations. Since the resulting premaster secret is used as an input into the key derivation function, which is based on hash functions with different timing profiles, precise timing measurements may enable an attacker to construct an oracle from a TLS server.
然後一層一層堆，能夠知道 premaster secret 開頭是不是 0 之後，接下來因為 server side 會重複使用同一組 premaster secret，所以可以當作一個 oracle，試著去計算出更後面的位數：
This oracle tells the attacker whether a computed premaster secret starts with zero or not. For example, the attacker could eavesdrop ga sent by the client, resend it to the server, and determine whether the resulting premaster secret starts with zero or not.
Learning one byte from a premaster secret would not help the attacker much. However, here the attack gets interesting. Imagine the attacker intercepted a ClientKeyExchange message containing the value ga. The attacker can now construct values related to ga and send them to the server in distinct TLS handshakes. More concretely, the attacker constructs values gri*ga, which lead to premaster secrets gri*b*gab. Based on the server timing behavior, the attacker can find values leading to premaster secrets starting with zero. In the end, this helps the attacker to construct a set of equations and use a solver for the Hidden Number Problem (HNP) to compute the original premaster secret established between the client and the server.
所以針對這個攻擊手法的解法就是用「新鮮的」premaster secret (像是完全不重複使用)，然後保留開頭的 0，不需要去掉。而 TLS 1.3 在定義的時候把這兩件事情都做了，所以不會受到影響：
Is TLS 1.3 also affected?
No. In TLS 1.3, the leading zero bytes are preserved for DHE cipher suites (as well as for ECDHE ones) and keys should not be reused.
另外在這邊提到的 Hidden Number Problem (HNP) 也是個不熟悉的詞彙，網站上有提到論文，也就是「Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes」這篇：
Given an oracle Oα(x) that on input x computes the k most significant bits of (α * gx mod p) , find α mod p.
是個離散對數類的問題，之後有空再來翻一翻好了。
