Tag: https

CloudFront 支援 HTTP/3

雖然 HTTP/3 還沒有進到 Standard Track，但看到 CloudFront 宣佈支援 HTTP/3 了：「New – HTTP/3 Support for Amazon CloudFront」。

只要在 CloudFront 的 console 上勾選起來就可以了：

看了看 RFC 9114: HTTP/3 文件裡的描述，client 可以試著建立 UDP 版本的 QUIC 連線，但要有機制在失敗時回去用 TCP 的 HTTP/2 或是 HTTP/1.1：

A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.

Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.

另外一條路是在 TCP 連線時透過 HTTP header 告訴瀏覽器升級：

An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame ([ALTSVC]) using the "h3" ALPN token.

像是這樣：

Alt-Svc: h3=":50781"

然後 client 就可以跑上 HTTP/3：

On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.

另外在 FAQ 裡面有提到啟用 HTTP/3 是不另外計費的，就照著本來的 request 費用算：

Q. Is there a separate charge for enabling HTTP/3?

No, there is no separate charge for enabling HTTP/3 on Amazon CloudFront distributions. HTTP/3 requests will be charged at the request pricing rates as per your pricing plan.

先開起來玩看看...

Let's Encrypt 更新了 ToS

在「Let's Encrypt’s subscriber agreement changes on Sept 21 (letsencrypt.org)」這邊看到的，Let's Encrypt 有提供 diff 的內容，在「LE-SA-v1.2-v1.3-diff.docx」這邊，你也可以用 Google Docs Viewer 看：「LE-SA-v1.2-v1.3-diff.docx」。

看起來主要是用語上的改變 (可能是律師的建議？)，除了 revoke 的章節外看起來沒什麼大變化。而 revoke 的章節部份增加了這兩段文字：

You warrant to ISRG and the public-at-large, and You agree, that before providing a reason for revoking Your Certificate, you will have reviewed the revocation guidelines found in the “Revoking Certificates” section of the Let’s Encrypt documentation available at https://letsencrypt.org/docs/ , and that you will provide Your corresponding revocation reason code with awareness of such guidelines.

You acknowledge and accept that ISRG may modify any revocation reason code provided by You if ISRG determines, in its sole discretion, that a different reason code for revocation is more appropriate or is required by industry standards.

不確定自動化的 client 需不需要重新再 accept 一次？

AWS 宣佈了 API 的 TLS 1.0/1.1 日落期

AWS 宣佈了 API 的 TLS 1.0/1.1 日落期：「TLS 1.2 to become the minimum TLS protocol level for all AWS API endpoints」。

公告裡提到是 2023/06/28：

This update means you will no longer be able to use TLS versions 1.0 and 1.1 with all AWS APIs in all AWS Regions by June 28, 2023.

TLS 1.0 目前還堪用的應該是 AES + CBC 類的 cipher，在正確實做 mitigation 下加減可以用：

對於像是 Java 6 環境這類很老舊的系統，如果真的無法升級的話，可以想到 workaround 的方法是透過 self-signed CA + TLS proxy 來幫忙把 TLS 1.0 的連線請求解開，重包成 TLS 1.2 的連線。

25Gbps 下 HTTPS 的效率

作者家裡拉了 25Gbps 的 Internet 後 (可以參考先前寫的「25Gbps 的家用 Internet」這篇)，然後發現 Internet 上好像拉不動 25Gbps 的量，所以自己在家裡先測試了現在 HTTPS 的極限速度：「25 Gbit/s HTTP and HTTPS download speeds」。

Client 是 AMD 的 5600X，算是目前最新的世代；Server 則是 Intel 的 9900K，目前最新應該是 12 代；測試用 35GB 的檔案來測，然後使用 TCP BBR (這邊沒有特別講，目前 kernel 內建的還是 v1)。

在單條 HTTP 的情況下 curl + nginx 與 curl + caddy 都可以直接跑滿 (23.4Gbps)，Go 的 net/http 會卡在 20Gbps 左右。

如果是多條 HTTP 的話都可以跑滿 23.4Gbps。

但到了 HTTPS 的情況下最快的是 Go + net/http，可以跑到 12Gbps；curl + nginx 剩下 8Gbps；接下來 curl + caddy 的部份只有 7.5Gbps，而 go + caddy 只有 7.2Gbps。

上到多條 HTTPS 的情況大家都可以跑滿 23.4Gbps，除了 go + caddy 只能跑到 21.6Gbps。

另外作者試著用 kTLS 把 TLS 的工作丟進 kernel，就不需要全部在 nginx 內處理，速度基本上沒有太大變化，主要是降低了 CPU loading：

In terms of download speeds, there is no difference with or without KTLS. But, enabling KTLS noticeably reduces CPU usage, from ≈10% to a steady 2%.

算是一個有趣的發現，如果目前的 HTTPS 想要在 25Gbps 上面單線直接跑滿，還需要再 tune 不少東西...

HTTPS Everywhere 將在明年一月 (2023/01) 停止運作

在「Set Up HTTPS by Default in Your Browser」這頁看到的東西：

Note: HTTPS Everywhere will sunset in January 2023.

我把他 submit 到 Hacker News 上：「HTTPS Everywhere will sunset in January 2023 (eff.org)」，裡面有一些有趣的討論，像是這跟 Google 硬幹 Manifest v2 也有關：

It doesn't seem to be mentioned by the EFF, but coincidentally, January 2023 is when Manifest v2 extensions stop working in Google Chrome: https://developer.chrome.com/blog/mv2-transition/

但查了一下，目前好像沒有好的技術標準可以確保第一次的 HTTPS request。馬上想的到的是透過 DNS 的方式指定，這樣就可以透過 DNSSEC 保護不被竄改，但看起來沒有這個標準...

AWS Lambda 可以直接有 HTTPS Endpoint 了

AWS 宣佈 AWS Lambda 可以直接有一個 HTTPS Endpoint 了：「Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices」。

如同文章裡面提到的，先前得透過 API Gateway 或是 ALB 才能掛上 Lambda：

Each function is mapped to API endpoints, methods, and resources using services such as Amazon API Gateway and Application Load Balancer.

現在則是提供像 verylongid.lambda-url.us-east-1.on.aws 這樣的網域名稱給你用，而且看說明似乎是直接包含在本來的 Lambda 價錢內？就不用另外搞 API Gateway 或是 ALB 了：

Function URLs are included in Lambda’s request and duration pricing. For example, let’s imagine that you deploy a single Lambda function with 128 MB of memory and an average invocation time of 50 ms. The function receives five million requests every month, so the cost will be $1.00 for the requests, and $0.53 for the duration. The grand total is $1.53 per month, in the US East (N. Virginia) Region.

這讓我想到可以用 Lambda 當特製的 HTTP proxy 的專案，好像可以拿來整到 feedgen 裡面用？

截聽本機的 HTTPS 內容

在 Hacker News 上看到「Decrypting your own HTTPS traffic with Wireshark」這篇，就是用 SSLKEYLOGFILE 請 library 把 TLS 相關的 key 與 random number 寫到檔案裡面讓 Wireshark 可以解讀拿來用。對應的討論在「Decrypting your own HTTPS traffic with Wireshark (trickster.dev)」這邊。

看起 OpenSSL 系列的 library 都有支援這個變數，另外 NSS 也支援這個變數，所以常見的程式應該都包含在內了...

比起 MITMA 類的方式 (像是 mitmproxy)，這個方式會更接近真實的情境，不另外產生 CA 與 key，不過缺點就是使用的情境就再受限一些，算是除了 MITMA 類方式的另外一個方案...

使用 Tor 的 .onion 位置，而非透過 Exit Node 存取網站的好處

在「Twitter 的 Tor Onion 位置」與「BBC 這次拿出短波廣播...」這兩篇我都有在懷疑為什麼要提供 Tor 的 .onion 位置，不是直接透過 exit node 連出去就好了嗎，結果今天看到「Why offer an Onion Address rather than just encourage browsing-over-Tor?」這篇在解釋。

對使用者來說，用 .onion 的好處是隱私性會更好，因為 exit node 本身不一定安全，必須透過 HTTPS 保護才有基本的防護，而且就算用了 HTTPS 還是可以從 HTTPS 的 handshake 得到不少資訊。

對網路本身來說，exit node 算是稀缺資源，大多數人可以架 Tor 的 relay node，但沒辦法做 exit node，因為 exit node 的特性會導致常常收到各種警告。因此能用 .onion 位置存取，也會降低對 exit node 的壓力。

另外 CA/Browser 在 2020 的時候就允許發出 .onion 憑證：「讓 Tor 的 .onion 支援 HTTPS」，看起來應該也是多一層保護...

自動偵測 DNS over HTTPS 或是 DNS over TLS 的 Discovery of Designated Resolvers (DDR)

看到 Cloudflare 宣佈支援 Discovery of Designated Resolvers (DDR)：「Announcing experimental DDR in 1.1.1.1」。

看了一下這以後會是新的標準 (現在還在 draft)，可以自動偵測現在用的 DNS resolver 是否支援 DNS over HTTPS 或是 DNS over TLS，如果有的話就 upgrade 到 DoH 或 DoT：

This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.

目前的 spec 是去查 _dns.resolver.arpa，下面第一個是支援 DoH 的回應，第二個則是支援 DoT 的回應：

_dns.resolver.arpa  7200  IN SVCB 1 doh.example.net ( alpn=h2 dohpath=/dns-query{?dns} )
_dns.example.net  7200  IN SVCB 1 dot.example.net ( alpn=dot port=8530 )

實際上拿 1.1.1.1 測試，在 Ubuntu 20.04 下用 dig 可以看到一堆亂碼 XDDD

;; ANSWER SECTION:
_dns.resolver.arpa.     300     IN      TYPE64  \# 104 0001036F6E65036F6E65036F6E65036F6E6500000100060268320268 330003000201BB000400080101010101000001000600202606470047 00000000000000000011112606470047000000000000000000100100 0700112F646E732D71756572797B3F6E616D657D
_dns.resolver.arpa.     300     IN      TYPE64  \# 81 0002036F6E65036F6E65036F6E65036F6E65000001000403646F7400 03000203550004000801010101010000010006002026064700470000 00000000000000111126064700470000000000000000001001

改用 Docker 開了 Ubuntu 22.04 (jammy) 的 image 後，裡面的 dig 可以用 SVCB 查詢 (本來的 type64 也還是會動)，另外也把內容解出來了：

;; ANSWER SECTION:
_dns.resolver.arpa.     300     IN      SVCB    1 one.one.one.one. alpn="h2,h3" port=443 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001 key7="/dns-query{?name}"
_dns.resolver.arpa.     300     IN      SVCB    2 one.one.one.one. alpn="dot" port=853 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001

這樣就不需要寫死在系統內，但要注意這樣還是會有 attacker 擋住讓你 upgrade 的問題...

修正 Curl 的 TLS handshake，避開 bot 偵測機制

利用 TLS handshake 的 pattern 可以當作是某種 fingerprint，就可以知道你是用 Curl，這個方式在蠻多 CDN 都會用在 anti-bot 機制 (像是 Cloudflare)，而剛剛看到有人投稿自己的 patch，試著將 Curl 修改成 Firefox 的 pattern：「curl-impersonate」，Hacker News 上的討論在這邊可以看到：「Show HN: Curl modified to impersonate Firefox and mimic its TLS handshake (github.com/lwthiker)」。

作者有提到這次的 patch 偏 hack，不太可能整進上游，但希望未來改的乾淨一點，然後整進上游：

I hope to do so in the future, for now the implementation is extremely hacky so I doubt it can get accepted into curl.

另外有人提出來說應該要用 Firefox ESR 版本的 pattern 而非 stable channel，也有人提出來說用 Google Chrome 的更好，不過我覺得有人開始做就已經很棒了 XD