俄羅斯的 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.

nginx 記錄 TLS 連線資訊

想要在 nginx 的 access log 裡面記錄使用者在 HTTPS 連線使用的 TLS protocol 與 cipher。

在「How can I let nginx log the used SSL/TLS protocol and ciphersuite?」這邊有提到方向是 $ssl_protocol$ssl_cipher (出自「Module ngx_http_ssl_module」內的 Embedded Variables 章節)。

他的方式是在前面就插入 protocol,但我希望前面的欄位保持不變,把 protocol & cipher 放到後面,所以我就加了一個 /etc/nginx/conf.d/combined_ssl.conf (這邊我用 ondrej 的 PPA,在設定檔裡會撈 /etc/nginx/conf.d/ 下的設定,不確定其他的情況如何):

#
log_format combined_ssl '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_protocol/$ssl_cipher';

然後本來用 combined 的 HTTPS 設定就改成 combined_ssl

來放一陣子再來分析,然後想看看要怎麼調整 cipher...

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

收 Wikimedia (包括維基百科) 的 Recent Changes

所以有新的 streaming protocol 取代本來的 RCStream:「Get live updates to Wikimedia projects with EventStreams」。

這次新的 protocol 是走標準協定:

EventStreams is built on the w3c standard Server Sent Events (SSE). SSE is simply a streaming HTTP connection with event data in a particular text format. Client libraries, usually called EventSource, assist with building responsive tools, but because SSE is really just HTTP, you can use any HTTP client (even curl!) to consume it.

直接用瀏覽器打開也可以看到一直冒出來新的訊息...

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

後續好像就沒有進度了...