Mitmproxy 11: Hỗ trợ HTTP/3 hoàn chỉnh

(mitmproxy.org)

3 điểm bởi GN⁺ 2024-10-06 | 1 bình luận | Chia sẻ qua WhatsApp

Khi tỷ trọng lưu lượng QUIC và HTTP/3 ngày càng tăng, mitmproxy 11 bật HTTP/3 theo mặc định để mở rộng phạm vi phân tích lưu lượng web hiện đại
HTTP/3 hoạt động không chỉ trong proxy trong suốt và reverse proxy mà còn cả với WireGuard và local mode, nên có thể áp dụng trong nhiều môi trường capture khác nhau
Chrome không tin cậy Certificate Authority do người dùng thêm vào khi dùng QUIC, nên cần chọn một trong các phương án: chứng chỉ được tin cậy công khai, cờ dòng lệnh, hoặc fallback về HTTP/2
Phần triển khai DNS được chuyển sang dựa trên Hickory DNS, xử lý truy vấn ngoài A/AAAA, HTTPS records, DNS-over-TCP, kiểm soát hosts file và loại bỏ khóa ECH
Các tính năng riêng tư như ECH khiến luồng tạo chứng chỉ của proxy trung gian trở nên khó khăn hơn, nhưng mitmproxy vẫn duy trì khả năng hoạt động bằng cách điều chỉnh phản hồi DNS

Phạm vi hỗ trợ HTTP/3

mitmproxy 11 hỗ trợ HTTP/3 trong chế độ proxy trong suốt và reverse proxy
Trong reverse proxy, một instance mitmproxy duy nhất nhận cả gói TCP và UDP và xử lý phiên bản HTTP được chuyển tiếp
- Ví dụ lệnh:
```
mitmproxy --mode reverse:https://http3.is
```
Có thể dùng HTTP/3 cả trong WireGuard và local mode
- Ví dụ lệnh:
```
mitmproxy --mode wireguard
mitmproxy --mode local
```
Đã thử nghiệm với Firefox, Chrome, nhiều bản build cURL và các client khác để giảm vấn đề tương thích
Công việc hỗ trợ HTTP/3 bắt đầu từ năm 2022 bởi Manuel Meitinger và Maximilian Hils, và được bật mặc định trong mitmproxy 11

Giới hạn chứng chỉ QUIC của Chrome

Giới hạn lớn hiện được biết đến là Chrome không tin cậy Certificate Authority do người dùng thêm vào khi dùng QUIC
Để xử lý lưu lượng HTTP/3 trong Chrome, cần một trong các cách sau
- Cung cấp chứng chỉ được tin cậy công khai như Let’s Encrypt
- Chạy Chrome kèm cờ dòng lệnh liên quan
- Chấp nhận hành vi fallback về HTTP/2
Firefox không có hành vi như vậy
Có thể xem mẹo xử lý sự cố HTTP/3 tại #7025

Tái triển khai dựa trên Hickory DNS

Khi xuất hiện các tính năng riêng tư như DNS HTTPS records và Encrypted Client Hello(ECH), việc xử lý DNS của mitmproxy trở nên quan trọng hơn
Phần triển khai DNS cũ có giới hạn vì dùng getaddrinfo
- Chỉ hỗ trợ truy vấn A/AAAA cho địa chỉ IPv4 và IPv6
- Không thể phản hồi các truy vấn như HTTPS records dùng để thông báo hỗ trợ HTTP/3
mitmproxy 11 triển khai lại hỗ trợ DNS trên Hickory DNS, một thư viện DNS viết bằng Rust
Thông qua Hickory, trên Windows, Linux và macOS có thể lấy nameserver mặc định của hệ điều hành và chuyển tiếp các truy vấn không phải A/AAAA đến nameserver đó
Tùy chọn mới dns_name_servers cho phép chỉ định nameserver đích
```
mitmdump --mode dns --set dns_name_servers=8.8.8.8
```

Kiểm soát hosts file và DNS-over-TCP

Cùng với việc chuyển sang Hickory, một tùy chọn để bỏ qua hosts file của hệ thống đã được thêm vào
Có thể dùng tùy chọn mới dns_use_hosts_file để kiểm soát việc có áp dụng hosts file như /etc/hosts trên Linux hay không
Cũng có kế hoạch chuyển phần phân giải DNS nội bộ của mitmproxy sang Hickory; sau đó tính năng này sẽ hữu ích khi chuyển hướng trong suốt một domain cụ thể trên cùng máy
- Hiện tại, vì luôn xét hosts file nên trong cấu hình chuyển hướng trên cùng máy, mitmproxy có thể tự kết nối đệ quy đến chính nó

Ví dụ hoạt động:

echo "192.0.2.1 mitmproxy.org" >> /etc/hosts
mitmdump --mode dns
dig @127.0.0.1 +short mitmproxy.org
192.0.2.1
mitmdump --mode dns --set dns_use_hosts_file=false
dig @127.0.0.1 +short mitmproxy.org
3.161.82.13

DNS mặc định dùng UDP, nhưng có thể cần TCP khi xử lý các bản ghi không vừa trong một gói UDP đơn lẻ
Vì mitmproxy 11 hỗ trợ kiểu truy vấn tùy ý nên tầm quan trọng của kích thước thông điệp và xử lý TCP tăng lên, và DNS-over-TCP cũng hoạt động

Loại bỏ khóa ECH và tạo chứng chỉ

mitmproxy dùng Server Name Indication(SNI) của TLS ClientHello để tạo chứng chỉ hợp lệ khi không có chứng chỉ tùy chỉnh
Nếu không có SNI, có thể không tạo được chứng chỉ mà client sẽ tin cậy
Encrypted Client Hello(ECH) là cơ chế mà client lấy khóa ECH từ DNS HTTPS records rồi mã hóa thông điệp bắt tay ClientHello ban đầu bằng khóa đó
Nếu cả truy vấn DNS và bắt tay đều được mã hóa, proxy trung gian thụ động sẽ không biết domain đích mà chỉ thấy địa chỉ IP đích
- Trong môi trường shared hosting và Content Delivery Networks, rất khó xác định chính xác domain đích chỉ từ địa chỉ IP
Cải tiến quyền riêng tư này xung đột với cách mitmproxy tạo chứng chỉ
mitmproxy 11 loại bỏ khóa ECH khỏi HTTPS records để lấy được thông tin domain cần cho việc tạo chứng chỉ
- Client sẽ không lấy được khóa để mã hóa thông điệp bắt tay ban đầu
- mitmproxy có thể xác định domain đích và tạo chứng chỉ khớp
ECH có thể khiến việc dùng mitmproxy trở nên khó hơn, nhưng đây cũng có thể được xem là một thay đổi giúp tăng quyền riêng tư trên web nói chung

1 bình luận

GN⁺ 2024-10-06

Ý kiến trên Hacker News

Thật vui khi thấy Mitmproxy vẫn còn được phát triển. Công cụ này đã gián tiếp tạo dựng sự nghiệp của tôi
Năm 2011, khi học phát triển API bằng cách chặn các request của ứng dụng di động, tôi phát hiện API của Airbnb bị lộ trước lỗ hổng gán hàng loạt của Rails (https://github.com/rails/rails/issues/5228). Sau khi thử thay đổi vài thuộc tính vô hại, tôi liên hệ với công ty, chuyện đó dẫn đến một buổi phỏng vấn, và phần còn lại thì đúng là lịch sử
- Số lượng nhà phát triển chủ chốt phản đối thay đổi trong issue đó thật sự nhiều đến mức khó tin
- Đến giờ nó vẫn cực kỳ hữu ích với tôi, nhưng đáng ngạc nhiên là nhiều người lẽ ra phải biết lại không rành Mitmproxy
  Đôi khi gắn mitmproxy vào một triển khai hiện có còn dễ hơn đọc tài liệu
Điều thú vị là Chrome không tin cậy các cơ quan chứng thực do người dùng thêm vào trong QUIC
Trong issue liên quan, đội Chrome nói rằng “chúng tôi không chủ động cho phép các chứng chỉ không được tin cậy công khai, nhằm ngăn việc triển khai phần mềm/phần cứng chặn QUIC. Nếu không, về dài hạn sẽ làm hại khả năng tiến hóa của giao thức QUIC. Những trường hợp sử dụng dựa vào chứng chỉ không thuộc diện tin cậy công khai thì có thể dùng TLS+TCP thay cho QUIC”
Tôi không theo sát sự tiến hóa của giao thức, nhưng không rõ việc chặn chứng chỉ tùy chỉnh liên quan thế nào đến khả năng tiến hóa. Không biết có ai biết lý do không
- Tôi đoán là vì Google kiểm soát cả client lẫn các endpoint máy chủ lớn (Google Search, Youtube, v.v.), nên họ muốn tự do thử nghiệm các thay đổi QUIC
  Họ có thể đưa một phiên bản QUIC chỉnh sửa nhẹ vào Chrome, hỗ trợ nó ở những nơi như Youtube, rồi dựa trên các chỉ số đó để đề xuất thay đổi tiêu chuẩn “thật”, hoặc tiếp tục chạy một phiên bản đặc biệt chỉ trong dịch vụ của mình
  Nếu cho phép chứng chỉ tùy chỉnh, các doanh nghiệp dùng những thứ như ZScaler ZIA để kiểm tra lưu lượng nhân viên theo kiểu trung gian có nguy cơ bị hỏng khi giao thức thay đổi. Nếu luồng dữ liệu được mã hóa hoàn toàn và trở nên mờ đục với thiết bị trung gian, Google gần như có thể làm bất cứ điều gì họ muốn
  Khái niệm liên quan: https://en.wikipedia.org/wiki/Protocol_ossification
- Thiết bị trung gian (https://en.m.wikipedia.org/wiki/Middlebox) là một nguyên nhân nổi tiếng gây trì trệ giao thức
  Với các giao thức có thể mở rộng, thường chỉ cần nâng cấp client và server, nhưng nếu có thiết bị trung gian thì có khả năng phải cập nhật thêm N thiết bị. Người dùng và nhà cung cấp dịch vụ có động lực áp dụng tính năng mới, còn chủ sở hữu thiết bị trung gian thì có thể không. Kết quả là giao thức khó tiến hóa hơn
- Cũng có thể họ đang ám chỉ trường hợp nổi tiếng khi các tổ chức tài chính phản đối TLS 1.3. Động cơ là họ không muốn cập nhật phần mềm trung gian cần thiết cho tuân thủ quy định: https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA/
- Một trong những lý do tạo ra HTTP/2 và HTTP/3 cũng là vì việc thay đổi HTTP 1.1 quá khó
  Có nhiều middleware phụ thuộc mạnh vào chi tiết triển khai, nên chỉ cần thay đổi chút gì đó cũng dễ vô tình phá trải nghiệm người dùng. Có vẻ họ muốn tránh tình huống tương tự trong phiên bản mới
- QUIC tồn tại để tăng tỷ lệ phân phối quảng cáo, nên việc trao tự do cho người dùng mâu thuẫn với mục tiêu đó
Tôi thắc mắc liệu HTTP/2 hoặc HTTP/3 có lợi ích gì không nếu chỉ được hỗ trợ ở reverse proxy chứ không phải ở web server thực tế
Hầu hết các framework chính trong JS/Python/Ruby không hỗ trợ các chuẩn HTTP mới. Vậy web server có trở thành nút thắt cổ chai của kết nối reverse proxy không?
- Có. HTTP/2 hoặc HTTP/3 giúp tăng độ tin cậy của kết nối giữa client và reverse proxy
  Kết nối giữa reverse proxy và web server thực tế thường nhanh và ổn định hơn nhiều, nên lợi ích khi nâng đoạn đó lên HTTP/2 hoặc HTTP/3 nhỏ hơn nhiều
- Truyền tải giữa reverse proxy và backend không phải lúc nào cũng là HTTP. Ví dụ Python đôi khi dùng uWSGI, PHP dùng FastCGI
  Ngay cả khi dùng HTTP, reverse proxy có thể thiết lập kết nối với backend nhanh hơn nhiều so với với client từ xa thực sự. Vì vậy dùng stream HTTP/2 trên đoạn chậm vẫn có lợi
- Có lẽ không quá liên quan, nhưng mitmproxy không phải là reverse proxy dành cho môi trường production
  Nó là công cụ chạy trên máy cục bộ để kiểm thử giao thức cấp thấp hoặc bảo mật web
- Có một điểm còn thiếu. Trình duyệt web giới hạn số kết nối mỗi domain ở 6
  Với HTTP/2 trở lên, nhiều request đồng thời được xử lý trên một kết nối
- Có. Ngoài các lợi ích hiệu năng khác, HTTP/3 kết hợp bắt tay TCP và TLS, giúp giảm 1 vòng khứ hồi khi kết nối
Vẫn còn vấn đề fingerprinting. Cho đến khi có thể bắt chước bắt tay TLS của một trình duyệt phổ biến, bạn sẽ thấy các trang kiểu “Just a quick check...” hoặc “Sorry, it looks like you're a bot” trên khoảng 80% web
https://github.com/mitmproxy/mitmproxy/issues/4575
- Vậy có vẻ Firefox không còn là trình duyệt phổ biến nữa rồi
Cảm ơn vì đã nhắc đến Hickory. Luôn thú vị khi thấy mọi người xây dựng gì với nó, và đây là một công việc được làm tốt
- Cảm ơn vì công sức với Hickory. Thật sự thú vị khi khả năng tương tác Python↔Rust của PyO3 cho phép dùng trong Python các thư viện DNS cấp production như Hickory và các stack mạng user-space vững chắc như smoltcp
  Những thứ như vậy vốn khó có được chỉ bằng Python
Tôi thắc mắc có thể dùng Mitmproxy như Privoxy/Proxomitron/Yarip không
Ví dụ khi duyệt bằng Ungoogled Chromium, có thể đặt Mitmproxy làm proxy và loại bỏ thẻ script của một số site cụ thể không? Hiệu năng sẽ bị ảnh hưởng thế nào?
- Về lý thuyết là có thể. Trên thực tế, mitmproxy được viết bằng Python, nên vì ngôn ngữ này không quá nhanh, nó sẽ tạo thêm độ trễ
  Khi xem trang web, những độ trễ nhỏ cộng dồn hàng trăm lần có thể cảm nhận được
  Dù vậy, với những ai quan tâm đến mục đích này thì đây có thể là một lựa chọn. Về mặt kỹ thuật không có gì ngăn cản
  Khi viết lại file JavaScript, có một rủi ro nhỏ là đụng đến kiểm tra tính toàn vẹn tài nguyên con, nhưng nếu thật sự có vấn đề thì có lẽ cũng có thể viết lại cả hash để giải quyết
mitmproxy có thể là lựa chọn thay thế cho Fiddler không?
- Gần như vậy. Điểm tôi thích ở mitmproxy là rất dễ dùng plugin Python để chặn hoặc sửa request và response
  https://docs.mitmproxy.org/stable/addons-overview/
Ừm: https://github.com/mitmproxy/mitmproxy/issues/4170
- https://github.com/mitmproxy/mitmproxy/issues/6199

Mitmproxy 11: Hỗ trợ HTTP/3 hoàn chỉnh

Phạm vi hỗ trợ HTTP/3

Giới hạn chứng chỉ QUIC của Chrome

Tái triển khai dựa trên Hickory DNS

Kiểm soát hosts file và DNS-over-TCP

Loại bỏ khóa ECH và tạo chứng chỉ

Bài viết liên quan

1 bình luận

Ý kiến trên Hacker News