Tag: http

Problem Details for HTTP APIs (RFC 7807 變成 RFC 9457)

之前寫過「RFC 定義的 application/problem+json (或是 xml)」，最近在找資料發現 2016 年的 RFC 7807 被 2023 年的 RFC 9457 取代了，兩份的標題都是「Problem Details for HTTP APIs」。

在「Appendix D. Changes from RFC 7807」這邊有提到做了什麼修改，看起來有三點：

Section 4.2 introduces a registry of common problem type URIs
Section 3 clarifies how multiple problems should be treated
Section 3.1.1 provides guidance for using type URIs that cannot be dereferenced

看起來大骨架沒有變，主要是補充了一些不足而已...

API 不該自動 HTTP 轉到 HTTPS

在「API Shouldn't Redirect HTTP to HTTPS (jviide.iki.fi)」這邊看到的，原始文章在「Your API Shouldn't Redirect HTTP to HTTPS」這邊。

仔細想一下沒錯，API 應該要一開始就被正確設定，所以要 fail fast。

另外在 id=40505525 這邊還提到了透過 HTTP 的 token 會自動被 revoke 掉，這個作法也很漂亮：

The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.

另外一個想法是直接不聽 port 80，不過這點在 Endpoint 的 IP 不是自己專用的情況下不一定能做到 (像是大多數的 CDN 環境)。

的確有戳中我手上預先準備好的 nginx config，來想看看怎麼改會比較好... 也許改成整個傳回 403，只開 /.well-known/acme-challenge/ 讓 ACME (Let's Encrypt) 的 HTTP-01 認證可以過。

Common Media Client Data (CMCD)

從 Amazon CloudFront 的公告看到的東西：「Amazon CloudFront now supports Common Media Client Data (CMCD) fields in real-time logs」。

CMCD (Common Media Client Data) 是一個私有的 log format，可以讓 client 透過 HTTP(S) header 回報狀態，所以 AWS 這邊有提到你可以設定讓 CloudFront 記錄下來，然後透過其他軟體分析：

Previously, CloudFront logged CMCD parameters as part of the full query string log field, or the HTTP headers log field. Now, you can simply select to include specific CMCD parameters in your real-time logs and save on compute needed to search and extract the CMCD key-value pairs, and reduce the data set for your log analysis.

現在 CloudFront 則是支援判讀做一些處理：

Starting today, you can enable Common Media Client Data (CMCD) fields in your CloudFront real-time logs. You can select key client-side performance parameters and CloudFront delivery performance parameters in the same log record. This can help you correlate variations in Quality of Experience (QoE) for your viewers to CloudFront performance at the granularity of single viewer sessions, simplifying the troubleshooting of QoE issues that impact your viewers engagement.

看了一下就是定義一些欄位，用 JSON 包起來後讓 client 打回伺服器端，可以利用這些資訊動態從伺服器端調整策略，而不像以前主要的調整策略都放在 client 端。

拿 WireGuard 當作 SOCKS5 Proxy 的用戶端

pufferffish/wireproxyHacker News 上看到「Wireproxy: WireGuard client that exposes itself as a HTTP/SOCKS5 proxy (github.com/pufferffish)」這個有趣的東西，GitHub 上的專案頁在 pufferffish/wireproxy 這邊：

A wireguard client that exposes itself as a socks5/http proxy or tunnels.

不需要連上完整版本的 WireGuard VPN，而是透過 proxy 協定讓使用者可以使用，這樣配合瀏覽器的工具 (像是 SwitchyOmega) 可以很方便的設定各種變化，像是針對日本限定的網站走日本的 VPS instance 出去。

另外值得一提的是，這是一個 userland 而且不需要 root 權限的實作；這點蠻容易可以理解的，只是聽一個 TCP port 然後用 WireGuard protocol 跟遠端溝通，的確是不需要 root 權限。

另外在 Hacker News 的留言裡面還看到了 aramperes/onetun 這個工具，看起來是 server 端的實作，支援 TCP 與 UDP：

A cross-platform, user-space WireGuard port-forwarder that requires no root-access or system network configurations.

這兩個看起來剛好可以搭在一起...？

Go 的 net/http 在 1.22 的 routing 新功能

Go 的 net/http 在 1.22 引入了更方便的 pattern matching：「Routing Enhancements for Go 1.22」。

用官方的範例，現在可以處理路徑裡的參數了：

http.Handle("GET /posts/{id}", handlePost2)

後續可以透過 PathValue() 取出來：

idString := req.PathValue("id")

而優先順序則是依照吻合度定義：

The precedence rule is simple: the most specific pattern wins. This rule matches our intuition that posts/latests should be preferred to posts/{id}, and /users/{u}/posts/latest should be preferred to /users/{u}/posts/{id}. It also makes sense for methods. For example, GET /posts/{id} takes precedence over /posts/{id} because the first only matches GET and HEAD requests, while the second matches requests with any method.

但是當有重疊卻無法判斷相對吻合度的 rule 被加進去時，會直接 panic()：

What if two patterns overlap but neither is more specific? For example, /posts/{id} and /{resource}/latest both match /posts/latest. There is no obvious answer to which takes precedence, so we consider these patterns to conflict with each other. Registering both of them (in either order!) will panic.

這的確是種方法啦... 而且留有之後處理的空間，真的有好的方法就可以把 panic() 的邏輯改成新的共識。

Amazon EC2 的 IMDSv2 計畫

2019 的時候 Amazon EC2 推出了 IMDSv2 (Instance Metadata Service)：「Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service」。

舊版 v1 的 IMDS 可以直接拿到很多東西，像是這樣：

curl -v http://169.254.169.254/latest/dynamic/instance-identity/document

對於有使用 IAM Role 授權 EC2 instance 操作的，還可以參考「How to hack AWS instances that have the metadata service (IMDSv1) enabled」這邊的方法取得對應的 AWS credential。

當攻擊者可以「操弄」時 (像是 proxy server 或是 crawler)，就會蠻危險的。

而 IMDSv2 則是多了一個步驟，你要先拿到 token，再把這個 token 帶到之後的 HTTP request header 裡面，而蠻多可以「操弄」的情境下是無法修改 HTTP request header 的：

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl http://169.254.169.254/latest/meta-data/profile -H "X-aws-ec2-metadata-token: ${TOKEN}"

而這次 2023 年則是推出了對應的計畫，將在 2024 年年中把預設值改成只提供 IMDSv2：「Amazon EC2 Instance Metadata Service IMDSv2 by default」。

Effective mid-2024, newly released Amazon EC2 instance types will use only version 2 of the EC2 Instance Metadata Service (IMDSv2). We are also taking a series of steps to make IMDSv2 the default choice for AWS Management Console Quick Starts and other launch pathways.

舊的 IMDSv1 還是可以開，但需要指定才會啟用。

德國法院認為 DNT header 具有法律的告知效力

HN 上面看到「German court declares Do Not Track to be legally binding (vzbv.de)」這個消息，原文是德文：「Gericht untersagt Datenschutzverstöße von LinkedIn」，Google Translation 翻譯的結果：「Court bans LinkedIn data protection violations」。

LinkedIn 告知使用者他們不會理會 DNT，德國法院則是認為 DNT header 是已經告知對方不願意被追蹤了：

„Wenn Verbraucher:innen die ,Do-Not-Track‘-Funktion ihres Browsers aktivieren, ist das eine klare Botschaft: Sie wollen nicht, dass ihr Surfverhalten für Werbe- und andere Zwecke ausgespäht wird“, sagt Rosemarie Rodden, Rechtsreferenin beim vzbv. „Webseitenbetreiber müssen dieses Signal respektieren.“

“When consumers activate the 'Do Not Track' function of their browser, it sends a clear message: They do not want their surfing behavior to be spied on for advertising and other purposes,” says Rosemarie Rodden, legal officer at vzbv. “Website operators must respect this signal.”

這好像是第一次看到 DNT 相關的法律判決？可以看看後續有沒有新的消息 (上訴之類的)，來看看最終的判決會是怎麼樣。

Uptime Kuma：UptimeRobot 的 Open Source Clone

UptimeRobot 算是我自己還蠻喜歡用的監控服務，各種常見的類型都支援，像是 HTTP/HTTPS website 的監控，ICMP Ping 或是 TCP 的監控，另外也提供 SSL certificate 的監控。

前陣子找資料的時候找到 Uptime Kuma，這是香港的 Louis Lam 開發的 open source software，光看名字就懷疑是 UptimeRobot 的致敬版本，裝起來用過後就更確定...

差不多用了一個多月了，基本上功能還蠻完整的，我把他接到我自己的 Slack 以及 Pushover 上，就很方便的可以監控服務：

挑一個點：

ISP 偽造出合法的 SSL certificate，對放在德國的 xmpp.ru 進行 MITM 監聽

標題有點複雜，先講一下 http-01 認證，這是目前 Let's Encrypt 上最常被使用的認證方式，是透過 HTTP 協定完成認證，你只要能回答 http://www.example.com/.well-known/acme-challenge/XXX 的內容就能過。

一般來說，這個 HTTP 位置只有這台伺服器的 owner 才有辦法提供，也就能確保不是任何人都可以申請。

但因為這邊走的是 HTTP，對於 ISP 這種比較特別的身分來說，他可以從中架設 HTTP 的 MITM Proxy 做到這件事情。

而有了合法的 SSL certificate 之後，中間的 MITM Proxy 就不只能聽 HTTP 了，還可以聽 HTTPS 的內容 (甚至修改內容)。

這次發生的事情就是在德國的 Linode 與 Hetzner 機房內的服務，俄羅斯最大的 XMPP 服務 xmpp.ru 被搞出這件事情 (XMPP 是一個開放協定，不熟的話可以想像成類似 Line 或是 Telegram 的服務，但 XMPP 是開放協定，可以用自己喜歡的軟體連上)：「Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service」。

他們在 Hetzner 的伺服器上有發現 network offline 的訊號：

[Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Down
[Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

而在這個 network offline 的時間不久後 Let's Encrypt 發出了 xmpp.ru 與 jabber.ru 的 SSL certificate (crt.sh 上可以查到，在 9997694704 與 9997621208)：

18 July 2023 issuing time is about the same when Hetzner server has lost network link for several seconds.

這些徵兆符合改接到 MITM Proxy 上的行為。

這次的事情很大條，因為這些伺服器是在德國，不是在俄羅斯... 事情才剛開始被報導出來，後續得繼續追蹤，而且應該也會促成新的機制被引入？