SSH 在 Port 22 的故事

雖然現在全世界都在用 OpenSSH,但當初 SSH 其實是 SSH Communications Security 所發展出來的。最近上面在講當初申請 port 22 的故事:「How SSH Port Became 22」。

選 port 22 是因為剛好要取代 port 21 的 ftp 與 port 23 的 telnet:

Anyway, I designed SSH to replace both telnet (port 23) and ftp (port 21). Port 22 was free. It was conveniently between the ports for telnet and ftp. I figured having that port number might be one of those small things that would give some aura of credibility. But how could I get that port number? I had never allocated one, but I knew somebody who had allocated a port.

而後來就寫信去要 port 22 這個位置...

Android 上透過 DAC (i.e. 耳機或是喇叭) 再做 ADC (i.e. 麥克風) 的傳輸

看到「Quiet for Android - TCP over sound」這個給 Android 用的專案,就是以前的撥接數據機嘛... 在直接拉線對連時連速度都還蠻像的:

Quiet's provided audible mode transfers at approximately 7kbps. In cases where two devices are connected over a cable (via 3.5mm jack) it can run in cable mode, which transfers at approximately 64kbps.

拿來做一些 (邪惡的) 事情?

Google 研發出的 BBR: Congestion-Based Congestion Control

Google 針對 TCP 的 congestion control 研究出了新的方法,是個純 sender-side 的演匴法,可以讓現有的 internet 直接換上去使用:「[net-next,14/14] tcp_bbr: add BBR congestion control」。

在 long-lived TCP connection 愈來愈普及後 (像是 HTTP/2),TCP 連線的最佳化可以用統計模型來計算,這也就是 BBR 的想法:

In a nutshell, BBR creates an explicit model of the network pipe by sequentially probing the bottleneck bandwidth and RTT. On the arrival of each ACK, BBR derives the current delivery rate of the last round trip, and feeds it through a windowed max-filter to estimate the bottleneck bandwidth. Conversely it uses a windowed min-filter to estimate the round trip propagation delay. The max-filtered bandwidth and min-filtered RTT estimates form BBR's model of the network pipe.

不過 QUIC 不是也開始有進展了嗎?(參考「Google Chrome 52 預設開啟了更快的 QUIC (被戲稱為 TCP/2)」這篇)

感覺 QUIC 解決的比較徹底,不過 443/udp 的 firewall 問題的確也是個需要時間解決的課題...

前陣子在 Black Hat 上發表的 HEIST 攻擊 (對 HTTPS 的攻擊)

又是一個對 HTTPS 的攻擊:「HEIST attack on SSL/TLS can grab personal info, Black Hat」、「New attack steals SSNs, e-mail addresses, and more from HTTPS pages」。

一樣是 Compression 產生的 side-channel attack,只是這次是結合 TCP window size 的攻擊。投影片可以在「HTTP Encrypted Information can be Stolen through TCP-windows (PDF)」這邊看到。

這次的攻擊只需要在瀏覽器上插入 HTTP 產生 HTTPS 的流量,然後從旁邊看 HTTPS 連線的 TCP packet 就可以了,而且對 HTTP/2 也很有效:

而且很不幸的,目前沒有太好的解法,因為所有的攻擊手法都是照著使用者無法發現的路徑進行的 @_@

對於使用者,大量使用 HTTPS (像是 HTTPS Everywhere 這樣的套件),能夠降低政府單位與 ISP 將 javascript 插入 HTTP 連線,產生 HTTPS 的行為。

而對於網站端來說,全站都隨機產生不同長度的 HTTP header 可能是個增加破解難度的方式 (而且不會太難做,可以透過 apache module 或是 nginx module 做到),但還是可以被統計方法再推算出來。

不知道有沒有辦法只對 HTTPS 開 javascript,雖然攻擊者還是可以用 <img> 攻擊...

也許以後 HTTP/3 之類的協定會有一區是不壓縮只加密的,避開這類 compression-based attack @_@

Google Chrome 52 預設開啟了更快的 QUIC (被戲稱為 TCP/2)

在「Google’s QUIC protocol: moving the web from TCP to UDP」這篇前半部在介紹 QUIC (走 UDP 的 TLS),後半部則提到了幾個重點。

首先是 Google Chrome 從 52 開始 (也就是現在的 stable 版) 預設會開啟 QUIC (以前是只有 Google 自家的 domain),這讓採用的價值變高:

Since no one has QUIC support enabled by default in the client, you're probably still safe to run it and enable QUIC in your own browser(s). (Update: since Chrome 52, everyone has QUIC enabled by default, even to non-whitelisted domains)

再來是 QUIC 走 UDP/443:

Well, if we want to allow the QUIC protocol, we will need to allow 443/UDP too.

同時因為走的 Protocol 跟以前不同,所以我可以跑另外一隻 Server 服務使用者,目前只有 Caddy 有支援,雖然是實驗性質:

Right now, the only webserver that can get you QUIC is Caddy since version 0.9.

Both client-side and server-side support is considered experimental, so it's up to you to run it.

至少可以先把 firewall 打開了...

GitHub 對抗 TCP SYN Flood 的方式:synsanity

GitHub 提出了自己對抗 TCP SYN Floord 的方式:「SYN Flood Mitigation with synsanity」。

synsanity 是一個 netfilter (iptables) 用的 target,利用現有的理論阻擋 TCP SYN Flood 這種 DDoS:

synsanity is a netfilter (iptables) target for high performance lockless SYN cookies for SYN flood mitigation, as used in production at GitHub.

前人的作法 (SYNPROXY) 以 module 形式運作,需要過濾每一個封包,而這在 GitHub 這種規模上會導致效能不足並且 kernel panic:

This is quite an intrusive way of solving the problem since it touches every packet during the entire connection, but it does successfully mitigate SYN floods. Unfortunately we found that in practise under our load and with the amount of malformed packets we receive, it quickly broke down and caused a kernel panic.

GitHub 所開發的 synsanity 則是透過 netfilter (iptables) 的 target,只處理 initial packets,在撰寫的時候考慮多 CPU 的 lock 問題:

沒有檢查 TCP checksum 的 bug 造成的慘案

Twitter 家的工程師努力通靈找靈異現象,最後發現是 kernel bug 造成 veth 沒檢查 TCP checksum 造成的慘案:「Linux kernel bug delivers corrupt TCP/IP data to Mesos, Kubernetes, Docker containers」。

而隔壁棚 PagerDuty 在 2015 年五月也有遇到類似的問題,不過當時看起來沒找出 root cause,只有提出 workaround 解法暫時避開:「The Discovery of Apache ZooKeeper’s Poison Packet」。

這個 bug 已經被 patch 掉了,之後應該會再 backport 回到舊版 kernel

I’m really impressed with the linux netdev group and kernel maintainers in general; code reviews were quite prompt and our patch was merged in within a few weeks, and was back-ported to older (3.14+) -stable queues on various kernel distributions (Canonical, Suse) within a month.

文章中間有寫找 bug 的過程,可以看到都是在通靈...

nginx 的 TCP Fast Open

在「Enabling TCP Fast Open for NGINX on CentOS 7」這邊看到 nginxTCP Fast Open (TFO,RFC 7413) 的支援早在 1.5.8 就有了,而 Linux Kernel 也是 3.7 之後就全面支援了。

TCP Fast Open 利用第一次連線後產生的 TCP cookie,在第二次連線時可以在 3-way handshake 的過程就開始傳輸,藉此大幅降低 latency。

設定方法不難,先在 kernel 設定 net.ipv4.tcp_fastopen=3,再加上 fastopen=number 就可以了,像是這樣:

listen 80 fastopen=256

不過目前 NGINX Mainline 上的版本好像沒有編進去,暫時沒辦法測...

在 LAN 裡把 TCP timestamps 關閉擠出頻寬

由於 TCP timestamps 會使得封包多 12 bytes,關掉後可以在 LAN 裡面擠出頻寬,是個小孩子不要亂學的方法:「Save Some Bandwidth By Turning Off TCP Timestamps」。

文章裡是在 10Gbps 網路上測試,看測出來的圖片也只是一點點 (不到 1%),但仍然是有提昇:

Results show that it's reasonable to turn off timestamps on 10GE interfaces, but keep in mind that it should be performed only in low latency networks.

沒必要就不要亂動 :o