VPN đã kết nối nhưng nội dung hỗn hợp vẫn bị chặn: cần sửa gì
Phân loại URL bị chặn theo nguồn tạo ra nó, sửa tham chiếu hoặc chuyển cho chủ sở hữu máy chủ, rồi xác nhận bản sửa từ bảng điều khiển của trình duyệt.
Một nửa trang được hiển thị, một tệp định kiểu bị xám trong bảng Network, và ứng dụng VPN vẫn báo đường hầm khỏe mạnh. Cả ba quan sát đều đúng cùng lúc, vì trình duyệt đã xét một yêu cầu do trang tạo ra và đường hầm không có tiếng nói trong phán xét đó. Thứ khép lại vụ việc là một quyết định chứ không phải một cài đặt: sửa tham chiếu, chuyển nó lên chủ sở hữu máy chủ, hoặc bỏ phụ thuộc. Mỗi lựa chọn đều có một phép thử rẻ, và chọn sai tốn một chu kỳ hỗ trợ.
Vì sao đường hầm không thể bao phủ tài nguyên con
Nội dung hỗn hợp bắt đầu bằng một tài liệu HTTPS yêu cầu tài nguyên con qua HTTP thường. Mỗi URL được xét theo lược đồ riêng của nó, nên sự bảo vệ của tài liệu cha không bao giờ mở rộng sang yêu cầu con. Mã hóa được thêm bên dưới trình duyệt thay đổi thứ đi trên đường dây, không phải http:// mà đánh dấu đã yêu cầu.
Các trình duyệt hiện tại chia những yêu cầu này thành hai nhóm và xử lý khác nhau. Script, tệp định kiểu, iframe và lệnh gọi qua fetch, XMLHttpRequest hoặc WebSocket bị từ chối ngay, không thử nâng cấp trước. Hình ảnh, âm thanh và video được viết lại thành https:// và yêu cầu lại, và việc tải bị bỏ khi lần lấy an toàn đó thất bại. URL tài nguyên con có máy chủ là địa chỉ IP trần được miễn nâng cấp, nên một hình ảnh HTTP trên máy chủ IP vẫn bị chặn thay vì được sửa lặng lẽ. Cách phân chia, gồm cả ngoại lệ đó ở phía nâng cấp được, được ghi lại trong hướng dẫn về nội dung hỗn hợp của Mozilla. Chrome áp dụng cách từ chối tương tự với các lượt tải xuống không an toàn bắt đầu từ trang an toàn, nên một liên kết PDF có thể chết trong khi trang xung quanh trông vẫn nguyên vẹn.
Vì vậy hàng xám là bằng chứng việc kiểm soát đang hoạt động, không phải bằng chứng đường hầm đã rò rỉ văn bản thường. Hãy coi hàng đó là một phát hiện chỉ vào một tham chiếu, không phải cả trang.
Xác định tham chiếu không an toàn thuộc về ai
Phân loại URL có vấn đề theo nơi nó được tạo ra trước khi sửa bất cứ thứ gì. Câu trả lời đó quyết định bạn có thể phát hành bản sửa hôm nay không, nhà cung cấp có phải phát hành một bản không, hay phụ thuộc phải rời khỏi trang. Đọc nó ở cột Initiator trong bảng Network, vì đánh dấu trên màn hình thường được lắp ráp lúc chạy.
| URL đến từ đâu | Ai có thể sửa nó | Bước đầu tiên |
|---|---|---|
| Được mã hóa cứng trong mẫu hoặc phần bạn triển khai | Bạn | Thay bằng dạng https:// rồi xóa bộ nhớ đệm |
| Được trình quản lý thẻ hoặc gói nhà cung cấp chèn vào | Nhà cung cấp, với phiếu của bạn | Gửi URL chính xác, loại yêu cầu và dòng console |
| Chỉ phục vụ trên cổng 80 mà không có trình lắng nghe TLS | Chủ sở hữu máy chủ | Yêu cầu TLS, đặt thứ bạn kiểm soát phía trước, hoặc bỏ nó |
Khi máy chủ đã trả lời trên 443 và chỉ tham chiếu nói http, việc sửa là cục bộ: đổi tham chiếu, xóa bộ nhớ đệm trang và xác nhận hàng chuyển thành https. Một máy chủ chỉ lắng nghe trên cổng 80 không thể được làm cho tuân thủ bằng cách sửa, nên tài nguyên chuyển đi, được đặt thứ bạn kiểm soát phía trước, hoặc biến mất. URL do trình quản lý thẻ chèn vào vẫn xuất hiện kể cả khi mẫu của bạn sạch, và trường hợp đó thuộc về một phiếu có URL chính xác và dòng console đính kèm. Bảo nhân viên cho phép nội dung không an toàn không phải một trong các lựa chọn này, vì nó tắt kiểm tra cho mọi trang mà hồ sơ trình duyệt đó ghé thăm.
Sửa tham chiếu thay vì cài đặt trình duyệt
Tải lại luồng đang lỗi với nhật ký mạng được giữ lại và lọc bảng theo máy chủ bạn nghi ngờ. Bảng điều khiển nêu URL và chỉ thị, điều này quyết định yêu cầu bị từ chối hay được nâng cấp trước khi bạn chạm vào mẫu.
curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.jsHai biện pháp kiểm soát hỗ trợ đáng biết, và không cái nào thay thế việc sửa. Một tiêu đề Content-Security-Policy với upgrade-insecure-requests khiến trình duyệt viết lại URL tài nguyên con http trước khi chúng rời trang, bắt được những tham chiếu cũ mà bạn chưa tìm ra. Yêu cầu đã viết lại vẫn thất bại khi máy chủ đích không phục vụ HTTPS, nên tiêu đề chỉ đổi URL mà trình duyệt thử. HSTS áp dụng theo từng máy chủ, nghĩa là một chính sách trên miền của bạn không làm gì cho CDN bên thứ ba chưa bao giờ gửi tiêu đề đó. Sau khi sửa mẫu, xóa bộ nhớ đệm trang và tìm tên máy chủ cũ trong HTML đã hiển thị, vì cùng URL cũng có thể đến qua một phần, chuỗi dịch hoặc trường cơ sở dữ liệu.
Theo dõi cả chuyển hướng, vì một chuỗi bắt đầu bằng https:// có thể hạ cánh ở vị trí http:// và trình duyệt xét bước nhảy cuối. Dạng -L của lệnh thứ hai ở trên in ra URL hiệu lực đó cho bạn. Nếu bước nhảy cuối là http thuần, tham chiếu vẫn sai dù liên kết bạn sửa trông ổn.
Xác nhận trang bằng bảng điều khiển và bảng mạng
Tải lại với bộ nhớ đệm đã tắt và đi qua luồng một lần nữa, gồm cả các nút tải nội dung theo yêu cầu. Lần tải đầu tiên che các widget lười, ô bản đồ và script trình phát chỉ xuất hiện sau khi nhấp. Bảng điều khiển không nên có mục nội dung hỗn hợp và mọi hàng bạn chạm vào nên hiển thị https. Chụp lại bảng điều khiển và hàng yêu cầu trước khi đóng phiếu, vì trạng thái đó khó dựng lại sau lần triển khai kế tiếp.
Khi tài nguyên thuộc về người khác, gửi bốn thứ: URL chính xác, loại yêu cầu, văn bản bảng điều khiển và trang nơi nó xuất hiện. Che các mã định danh phiên trong mọi thứ bạn dán vào phiếu. Một báo cáo chỉ nói hình ảnh bị hỏng không cho chủ sở hữu thứ gì để tìm.
Đường hầm vẫn làm việc của nó trong khi bản sửa nằm ở tham chiếu đã tạo ra yêu cầu. Sau khi triển khai, tìm tên máy chủ thêm một lần nữa trong mẫu và gói nhà cung cấp, và chỉ đóng vụ việc khi không còn mục nội dung hỗn hợp bị chặn nào trong bảng điều khiển.