Home » Posts tagged "protocol"

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 就可以用這個方式穿過去了...

關閉新版 Google Chrome 網址列雞婆省略 www 的行為...

因為平常用的 Google Chrome 是 beta channel,前陣子出新版後網址遇到 wwwm 時就會不見,像是網址輸入 https://www.google.com,在連上後會變成這樣:

這樣讓人很不習慣,當時在網路上找了一些資料都沒找到,結果剛剛找資料時意外發現找到解法了:「Chrome address bar no longer shows protocol or www subdomain」。

把這個選項改成 Disabled 後,重開瀏覽器就恢復原來的行為了...

End-to-End Encryption 的標準?

看到「The Messaging Layer Security (MLS) Protocol」這個被提出來的標準,還在討論中...

簡介就說明了這個標準除了標準的 E2E 外,還設計了有效率的 Group 機制:

Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.

要設計機制的人可以拿來翻翻看...

俄羅斯的 BGP traffic reroute...

前幾天 (12 號) BGPmon 發現有很多知名的網段被導去俄羅斯:「Popular Destinations rerouted to Russia」。

Early this morning (UTC) our systems detected a suspicious event where many prefixes for high profile destinations were being announced by an unused Russian Autonomous System.

可以看到相當多知名的網段都被導走:

Starting at 04:43 (UTC) 80 prefixes normally announced by organizations such Google, Apple, Facebook, Microsoft, Twitch, NTT Communications and Riot Games were now detected in the global BGP routing tables with an Origin AS of 39523 (DV-LINK-AS), out of Russia.

從圖中也可以看出來 AS39523 透過 AS31133 發出這些 routing,然後主要是透過 AS6939 (Hurricane Electric) 擴散:

這幾年俄羅斯在網路上的動作多很多...

IEEE P1735 漏洞,又是 Padding Oracle Attack...

在「IEEE P1735 Encryption Is Broken—Flaws Allow Intellectual Property Theft」這邊看到 US-CERT 發表的「IEEE P1735 implementations may have weak cryptographic protections」,裡面提到的主要漏洞:

The methods are flawed and, in the most egregious cases, enable attack vectors that allow recovery of the entire underlying plaintext IP.

主要應該是第一包:

CVE-2017-13091: improperly specified padding in CBC mode allows use of an EDA tool as a decryption oracle.

又是 CBCpadding oracle attack 啊... 看起來是標準沒有強制定義好造成的?

The main vulnerability (CVE-2017-13091) resides in the IEEE P1735 standard's use of AES-CBC mode.

Since the standard makes no recommendation for any specific padding scheme, the developers often choose the wrong scheme, making it possible for attackers to use a well-known classic padding-oracle attack (POA) technique to decrypt the system-on-chip blueprints without knowledge of the key.

去年 Cloudflare 寫的「Padding oracles and the decline of CBC-mode cipher suites」這邊有提到 padding oracle attack 的方式,比較一般性的解法是避開要自己決定 Encrypt-then-MAC (IPsec;也是數學上證明安全性) 或 Encrypt-and-MAC (SSH) 或是 MAC-then-Encrypt (SSL),而是用 AEAD 類的加密元件直接躲開 padding oracle attack 的某些必要條件 (像是 AES-GCM 或是 ChaCha20-Poly1305)。

不過這也是這幾年大家才了解這樣做的重要性,當年在訂規格的時候都比較沒在在意這些...

在 MOPCON 2017 的 Unconference「MySQL to NoSQL & Search Engine」

把投影片傳到 Speaker Deck 上了:「MySQL to NoSQL & Search Engine」。

這是在介紹 noplay/python-mysql-replication 這個軟體,我在示範時用的 python script 有增加 blocking 參數讓他保持一直讀取 MySQL replication stream:

from pymysqlreplication import BinLogStreamReader

mysql_settings = {'host': '127.0.0.1', 'port': 3306, 'user': 'root', 'passwd': ''}

stream = BinLogStreamReader(connection_settings = mysql_settings, server_id=100, blocking=True)

for binlogevent in stream:
    binlogevent.dump()

stream.close()

利用這樣的工具可以做很多事情,像是當 post 表格更新時自動更新 search engine,並且清空 memcached 內的資料。這可以避免使用 library 時有可能會漏掉忘記做 (因為有些程式不用 library 處理),可靠度比較高。

另外一方面 replication protocol 本身就有考慮重連的問題,重新接上時是可以從上一次處理完的資料繼續處理 (只要不要隔太久),這讓寫應用的人不需要用太複雜的方式確保他不會漏掉。

WPA2 安全漏洞

話說 WPA2 也撐了十三年了:

WPA2 became available in 2004 and is a common shorthand for the full IEEE 802.11i (or IEEE 802.11i-2004) standard.

這次的漏洞可以參考「Severe flaw in WPA2 protocol leaves Wi-Fi traffic open to eavesdropping」這邊。

PoC 稱作 KRACK (Key Reinstallation Attacks),漏洞將會在十一月正式發表,從會議的標題名稱大概可以知道方向,是對 Nonce 下手:「Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2」。另外站台 www.krackattacks.com 已經放好,等後續的發表更新了。

對於無線網路的各種漏洞,老方法還是目前最有效的方法,也是這次的 workaround 之一:上強度足夠的 VPN。

Update:補上論文「Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2」。

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.

Archives