Cách Chúng Tôi Phát Hiện Lỗi TLS 1.3 Âm Thầm Trên Hàng Nghìn Thiết Bị Android

Nếu bạn vận hành mobile proxy, bạn hiểu cái đau đó: có gì đó hỏng, và không ai có thể nói cho bạn biết tại sao. Thiết bị đang ở một quốc gia khác. Người dùng nói "nó không hoạt động". Không có log, không có thông báo lỗi, không có stack trace. Chỉ là sự im lặng.

Đó chính xác là điều đã xảy ra với chúng tôi — ngoại trừ việc chúng tôi phát hiện ra trước khi hầu hết người dùng kịp nhận ra. Đây là lý do tại sao.

Cần proxy di động tư nhân?
Hãy tạo proxy di động ngay bây giờ!
Bắt đầu dùng thử miễn phí 48 giờ

iProxy chạy chẩn đoán mạng trên mọi thiết bị. Liên tục.

Ứng dụng Android của chúng tôi không chỉ chuyển tiếp lưu lượng. Nó chạy một bộ kiểm tra sức khỏe mạng đầy đủ — kiểm tra kết nối, độ trễ, phân giải DNS, khả năng tiếp cận HTTP và HTTPS, và nhiều hơn nữa. Các kiểm tra này chạy liên tục đối với các máy chủ được kiểm soát, vì vậy chúng tôi biết trạng thái mạng của mọi thiết bị tại bất kỳ thời điểm nào.

Đó là cách chúng tôi phát hiện ra nó: một tỷ lệ nhỏ các thiết bị bắt đầu thất bại kiểm tra HTTPS trong khi HTTP hoạt động hoàn hảo. Lỗi xảy ra ở giai đoạn bắt tay TLS. Không có lỗi, không có thông báo hết thời gian chờ — chỉ là một kết nối âm thầm đi vào hư không.

Nếu không có chẩn đoán tích hợp, điều này sẽ hoàn toàn vô hình. Người dùng sẽ thấy các lỗi proxy gián đoạn không có quy luật và không có giải thích. Chúng tôi sẽ chỉ đoán mò.

Điều thực sự đã xảy ra

Các lỗi liên quan cụ thể đến TLS 1.3. Các kết nối TLS 1.2 qua cùng một thiết bị, đến cùng một máy chủ, cùng một thời điểm — hoạt động bình thường. TLS 1.3 thì không.

Nguyên nhân gốc rễ hóa ra là sự kết hợp của hai yếu tố:

Các TLS client hiện đại gửi các tin nhắn bắt tay lớn hơn nhiều so với trước đây. Go 1.23+ và Chrome 124+ hiện bao gồm các chia sẻ khóa mật mã hậu lượng tử (ML-KEM) theo mặc định. Điều này khiến tin nhắn đầu tiên trong kết nối TLS — ClientHello — đủ lớn để vượt quá một gói TCP đơn lẻ. Phản hồi của máy chủ trong TLS 1.3 cũng được gửi như một khối lớn (bao gồm chuỗi chứng chỉ), có thể là 4-6 KB đối với các trang như Google hoặc Cloudflare.

Các thiết bị Android dưới áp lực bộ nhớ gặp khó khăn khi đệm các tin nhắn lớn hơn này. Ứng dụng của chúng tôi hoạt động như một TCP proxy — nó đọc byte từ socket này và ghi vào socket khác. Khi thiết bị thiếu RAM, việc đệm này có thể thất bại âm thầm. Dữ liệu bắt tay không được chuyển tiếp, hoặc phản hồi không trở về được. Không có lỗi. Không có crash. Chỉ là không có gì.

TLS 1.2 hoàn toàn tránh được điều này: quá trình bắt tay của nó được chia thành nhiều vòng đi-về nhỏ hơn, và không có tin nhắn đơn lẻ nào đủ lớn để gây ra vấn đề.

Tại sao điều này quan trọng với chất lượng proxy

Đây là loại vấn đề phân biệt một dịch vụ proxy đáng tin cậy với một dịch vụ gây bực bội.

Nếu không có chẩn đoán chủ động, một nhà cung cấp sẽ thấy người dùng phàn nàn về các lỗi HTTPS ngẫu nhiên. Bộ phận hỗ trợ sẽ nói "khởi động lại ứng dụng" hoặc "kiểm tra kết nối internet của bạn." Vấn đề sẽ xuất hiện và biến mất. Không ai liên kết nó với phiên bản TLS hay bộ nhớ thiết bị.

Tại iProxy, chúng tôi phát hiện ra quy luật một cách tự động. Hệ thống chẩn đoán của chúng tôi xác định rằng TLS 1.3 đang thất bại trong khi TLS 1.2 hoạt động — trên các thiết bị cụ thể, vào các thời điểm cụ thể. Điều đó cho chúng tôi biết chính xác cần tìm ở đâu.

Chúng tôi đã làm gì

Sau khi hiểu vấn đề, chúng tôi đã triển khai hai bản sửa lỗi:

Chuyển dự phòng TLS thông minh. Khi chẩn đoán của chúng tôi phát hiện mẫu lỗi TLS 1.3 trên một thiết bị, chúng tôi tự động điều chỉnh. Lưu lượng tiếp tục chảy mà người dùng không cần làm gì.

Khôi phục tự động. Nếu một thiết bị vào trạng thái bị suy giảm, chúng tôi có thể kích hoạt khởi động lại ứng dụng từ xa để giải phóng áp lực bộ nhớ và khôi phục toàn bộ chức năng. Hệ thống chẩn đoán phát hiện khi nào cần thiết và xử lý mà không cần sự can thiệp của người dùng.

Chúng tôi cũng tìm ra và sửa các rò rỉ bộ nhớ trong ứng dụng của mình đang góp phần vào vấn đề. Sự cải thiện ngay lập tức hiện ra trên các bảng điều khiển giám sát của chúng tôi — tỷ lệ lỗi TLS 1.3 giảm đáng kể trên toàn bộ thiết bị.

Đây là ý nghĩa thực sự của "hạ tầng proxy được quản lý"

Bất kỳ ai cũng có thể viết một ứng dụng chuyển tiếp gói TCP. Phần khó là biết khi nào nó ngừng hoạt động, tại sao nó ngừng hoạt động, và sửa nó trước khi người dùng mở một phiếu hỗ trợ.

iProxy giám sát sức khỏe mạng trên mọi thiết bị theo thời gian thực. Chúng tôi không chờ người dùng báo cáo sự cố — chúng tôi phát hiện chúng, chẩn đoán chúng, và trong nhiều trường hợp sửa chúng tự động. Đó là sự khác biệt giữa một ứng dụng proxy và một hạ tầng proxy.

Đội kỹ thuật của chúng tôi đã công bố một phân tích kỹ thuật chuyên sâu đầy đủ về cuộc điều tra này. Nếu bạn quan tâm đến các chi tiết — các bản bắt gói, sự khác biệt giữa Go và curl, góc độ mật mã hậu lượng tử — bạn có thể đọc tại đây: Khi TLS 1.3 chết lặng lẽ bên trong proxy Android của bạn.

iProxy.online cung cấp hạ tầng mobile proxy tại 100+ quốc gia và 600+ nhà mạng. Ứng dụng Android của chúng tôi biến điện thoại thành máy chủ proxy đáng tin cậy với chẩn đoán mạng tích hợp, giám sát sức khỏe tự động và quản lý từ xa.