新的 TLS 攻擊:Raccoon Attack

這次看到的是針對 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.

是個離散對數類的問題,之後有空再來翻一翻好了。

RIPE 的 IPv4 位置發完了

RIPE 在上個禮拜宣佈 IPv4 address 發完了:「[ripe-list] The RIPE NCC has run out of IPv4 Addresses」。

但這不代表不能申請,只是會進到「IPv4 Waiting List」這個列表裡面等待,各種原因取回的會發個這些申請者。

在台灣應該還是沒什麼感覺,因為固網 ISP 手上其實都拿一堆 IP 屯著,讓動態 IP 的架構輪著用,而行動網路上也可以看到不少 ISP 使用 Carrier-grade NAT 之類的架構在跑,最差也還可以拿 Private IP 硬上,暫時也不是太缺...

IPv6 的部份的確有愈來愈好,但還是常常可以看到 IPv4 的 routing 比較好,IPv6 有時候會繞到歐美再回亞洲...

話說起來,應該做看看 IPv6 上的 SmokePing 了,這樣才能比較 IPv4 與 IPv6 的 routing...

Chrome 打算要終止支援 FTP 協定

從「Google plans to deprecate FTP URL support in Chrome」這邊看到的,狀態資訊可以在「Deprecate FTP support」這邊看到。

以目前的 timeline 資訊,看起來是 M82 版本會完全拔掉:

M78 (2019Q4)
Finch controlled flag and enterprise policy for controlling overall FTP support.

Support disabled on pre-release channels.

M80 (2020Q1)
Gradual turndown of FTP support on stable.

M82 (2020Q2)
Removal of FTP related code and resources.

不過這樣就沒有方便的 FTP downloader 了 (雖然不常見),得另外再找軟體下載...

OAuth 2.0 Device Authorization Grant

看到「OAuth 2.0 Device Authorization Grant」這個變成 PROPOSED STANDARD 了,看了一下歷史是 2015 年年底的時候被提出來的,記得在前公司的時候有用這個 (當時還是 draft) 做智慧型電視上的 OAuth 認證:

The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

因為這些裝置的輸入設備受限,照原來 OAuth 2.0 的方式授權,使用者體驗不會太好 (可以想像用遙控器登入 Google 或是 Facebook 帳號?),所以設計了替代的方案,讓使用者可以用手機授權 (比較常見的是透過 QR code),然後電視機再去取得 access token。

robots.txt 的標準化

雖然聽起來有點詭異,但 robots.txt 的確一直都只是業界慣用標準,而非正式標準,所以各家搜尋引擎加加減減都有一些自己的參數。

在經過這麼久以後,Google 決定推動 robots.txt 的標準化:「Formalizing the Robots Exclusion Protocol Specification」,同時 Google 也放出了他們解讀 robots.txt 的 parser:「Google's robots.txt Parser is Now Open Source」,在 GitHubgoogle/robotstxt 這邊可以取得。

目前的 draft 是 00 版,可以在 draft-rep-wg-topic-00 這邊看到,不知道其他搜尋引擎會給什麼樣的回饋...

ACME,RFC 8555

這邊講的是因為 Let's Encrypt 所發明的 ACME 協定,可以協助自動化發憑證的協定。

剛剛看到「Automatic Certificate Management Environment (ACME)」這個頁面,上面標 PROPOSED STANDARD,但點進去的 txt 檔開頭則是 Standards Track 了:

Internet Engineering Task Force (IETF)                         R. Barnes
Request for Comments: 8555                                         Cisco
Category: Standards Track                             J. Hoffman-Andrews
ISSN: 2070-1721                                                      EFF
                                                             D. McCarney
                                                           Let's Encrypt
                                                               J. Kasten
                                                  University of Michigan
                                                              March 2019

不知道是不是兩邊不同步 (或是我對流程有誤會?),但這有一個標準文件可以參考了...

HTTP-over-QUIC 將變成 HTTP/3

cURL 作者那邊看到的,之前 HTTP-over-QUIC 的名稱實在太長,想要找個短一點的名字來用,這邊算是把命字確定下來了:「HTTP/3」。從文章後的說明就可以看出來:

No more confusion. HTTP/3 is the coming new HTTP version that uses QUIC for transport!

不過這代表 HTTP/3 需要 443/udp 了,之後防火牆預設應該要打開...

Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

UpdateApple 也宣佈了,時間點跟大家都差不多:「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。

Mozilla 宣佈了「Removing Old Versions of TLS」,而 Google 也宣佈了「Modernizing Transport Security」,兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。

Mozilla 這邊的計畫是 2020 年三月移除:

In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.

Google 這邊的計畫則是 Chrome 81 移除,換算成時間會從 2020 年一月開始影響到 canary channel,到 release channel 應該跟 Firefox 差不多時間:

In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.

差不多試從現在開始的一年半。

雖然這是講瀏覽器端的支援,但如果伺服器想要只支援 TLS 1.2+ 的話,就得考慮一下舊 client 支援的情況了。

桌機影響會比較小 (升級比較方便,替代方案也比較多),而行動平台看起來需要 Android 4.4+、iOS 7+,就要看各網站或是服務的族群了...

nginx 1.15.2 開始支援單一 Port 多服務...

nginx 的新功能,單一 port 支援多服務:「Running SSL and Non-SSL Protocols over the Same Port with NGINX 1.15.2」,最常見的還是混搭 SSH 了:

One key feature in this release is the new $ssl_preread_protocol variable, which allows you to distinguish between SSL/TLS and other protocols when forwarding traffic using a TCP (stream) proxy. This is useful if you want to avoid firewall restrictions by (for example) running SSL/TLS and SSH services on the same port.

雖然 L7 firewall 還是可以看出來 (並且擋下),但簡易的 firewall 就可以用這個方式穿過去了...