HTTPS hoạt động như thế nào?

Scrapeless Proxies hỗ trợ định tuyến các yêu cầu HTTPS thông qua các kết nối proxy được cấu hình bởi ứng dụng của bạn.

HTTPS là HTTP được truyền qua một lớp vận chuyển bảo mật, lớp này xác thực điểm cuối dự kiến và bảo vệ dữ liệu trong khi truyền. TLS cung cấp cơ chế mật mã được HTTPS sử dụng. Ứng dụng vẫn trao đổi các yêu cầu và phản hồi HTTP, nhưng một quan sát viên mạng thông thường không thể đọc hoặc sửa đổi nội dung được bảo vệ mà không bị phát hiện.

Sự bảo vệ đó có một ranh giới được xác định. Một dịch vụ kết thúc kết nối TLS có thể đọc thông điệp HTTP mà nó nhận được. Nếu một CDN kết thúc kết nối công khai và mở một kết nối khác đến máy chủ gốc, thì sẽ có các kết nối riêng biệt cần đánh giá. Chỉ báo kết nối an toàn của trình duyệt không mô tả mọi bước nhảy nội bộ phía sau điểm cuối công khai.

HTTPS bảo vệ những gì?

HTTPS bảo vệ tính bí mật và tính toàn vẹn của dữ liệu trong kết nối bảo mật và xác thực danh tính máy chủ mà phía khách mong đợi. Giao thức TLS định nghĩa quá trình bắt tay và trao đổi bản ghi được bảo vệ để thiết lập các thuộc tính đó.

Tính bí mật ngăn các trung gian thông thường đọc được các header và phần thân HTTP được bảo vệ. Tính toàn vẹn cho phép các bên phát hiện thay đổi đối với dữ liệu được bảo vệ. Xác thực giúp phía khách xác lập rằng bên kia được ủy quyền cho hostname đang được liên hệ, dựa trên chứng chỉ của nó và cấu hình tin cậy của phía khách.

HTTPS không chứng nhận rằng một doanh nghiệp là trung thực hoặc các tuyên bố trên một trang là đúng. Nó cũng không loại bỏ các vấn đề bảo mật bên trong ứng dụng tại điểm cuối. Một dịch vụ có thể chấp nhận một yêu cầu được truyền tải an toàn rồi xử lý sai dữ liệu sau khi giải mã. Hãy tách biệt bảo vệ lớp vận chuyển với mức độ tin cậy vào ứng dụng.

Điều gì xảy ra trước yêu cầu HTTP?

Một kết nối HTTPS mới thiết lập lớp vận chuyển bảo mật trước khi trao đổi HTTP được bảo vệ thông thường. Phía khách trước hết cần một đường đi mạng tới đích, thường sử dụng DNS để lấy địa chỉ. Sau đó nó đàm phán các tham số kết nối và xác thực bên kia thông qua TLS.

Một phiên bắt tay TLS giản lược bắt đầu bằng việc phía khách thông báo các tham số được hỗ trợ và thông tin chia sẻ khóa. Máy chủ chọn các thiết lập tương thích và cung cấp vật liệu xác thực theo yêu cầu của quá trình bắt tay. Cả hai phía dẫn xuất các khóa lưu lượng và kiểm tra lại quá trình trao đổi trước khi dùng các khóa đó để bảo vệ dữ liệu ứng dụng.

Đây là mô tả mang tính khái niệm hơn là một chuỗi gói tin cố định cho mọi kết nối. Khôi phục phiên và phiên bản giao thức được đàm phán sẽ làm thay đổi quá trình trao đổi. Các kết nối hiện có cũng có thể mang thêm các yêu cầu mà không cần lặp lại toàn bộ phiên bắt tay mới cho từng yêu cầu.

Khóa công khai của một chứng chỉ không đơn giản được dùng để mã hóa từng byte của một trang web. TLS hiện đại kết hợp xác thực và thỏa thuận khóa với bảo vệ lưu lượng đối xứng. Sự phân tách này cho phép kết nối xác thực bên kia và bảo vệ hiệu quả việc trao đổi dữ liệu tiếp theo.

Quy trình xác thực chứng chỉ hoạt động như thế nào?

Xác thực chứng chỉ kiểm tra xem danh tính được trình bày có chấp nhận được cho dịch vụ dự định hay không theo chính sách tin cậy của phía khách. Phía khách đánh giá chuỗi chứng chỉ, các ràng buộc về hiệu lực, và danh tính hostname. Một chứng chỉ cho một hostname khác sẽ không trở nên hợp lệ chỉ vì máy chủ có thể được truy cập tại cùng địa chỉ IP.

Các quy tắc về danh tính HTTPS và chứng chỉ kết nối origin được yêu cầu với điểm cuối bảo mật được kỳ vọng. Đây là lý do tại sao thay thế tên miền bằng một địa chỉ số có thể thất bại ngay cả khi địa chỉ đó trỏ tới đúng hạ tầng: kỳ vọng về danh tính của phía khách đã thay đổi.

Một chuỗi chứng chỉ thường nối chứng chỉ máy chủ thông qua các chứng chỉ trung gian tới một gốc tin cậy được phía khách công nhận. Kho lưu trữ tin cậy có thể khác nhau giữa các hệ điều hành, runtime và môi trường quản lý. Một kết nối hoạt động trong một trình duyệt có thể thất bại trong một container có cấu hình chứng chỉ khác.

Khi xác thực thất bại, hãy kiểm tra lại hostname, chuỗi, kho tin cậy và thời gian hệ thống. Tắt kiểm tra xác thực sẽ loại bỏ bước kiểm tra thiết lập danh tính của bên kia. Việc này không nên được coi là giải pháp thường xuyên cho một vấn đề kết nối trong bộ thu thập dữ liệu.

Những gì vẫn còn có thể thấy bên ngoài nội dung được mã hóa?

HTTPS không ẩn mọi thuộc tính của một kết nối mạng. Các trung gian mạng thường có thể quan sát địa chỉ đích và thời điểm hoặc khối lượng lưu lượng. Khả năng hiển thị tên miền phụ thuộc vào cách vận chuyển DNS và các tính năng TLS, nên không chính xác khi khẳng định rằng chỉ riêng HTTPS là ẩn được hostname được yêu cầu trong mọi môi trường.

Đường dẫn URL, chuỗi truy vấn và các header HTTP thông thường được bảo vệ bên trong kết nối TLS. Chúng vẫn hiển thị đối với điểm cuối giải mã yêu cầu. Nếu chuỗi truy vấn chứa thông tin nhạy cảm, nó vẫn có thể xuất hiện trong log của điểm cuối, lịch sử trình duyệt, hoặc hệ thống giám sát ứng dụng sau khi giải mã.

Hãy dùng đúng vị trí cho thông tin đăng nhập và ghi log một cách có chủ đích. Mã hóa trong khi truyền không khiến việc nhúng bí mật vào các URL tùy tiện hoặc sao chép toàn bộ header yêu cầu vào một báo cáo chẩn đoán trở nên an toàn. Vòng đời của dữ liệu tiếp tục sau khi quá trình truyền qua mạng kết thúc.

HTTPS đi qua một HTTP proxy như thế nào?

Một HTTP proxy thông thường có thể tạo một tunnel mà qua đó phía khách thiết lập TLS với đích. Phía khách yêu cầu proxy kết nối tới một host và port bằng phương thức CONNECT. Khi tunnel được thiết lập, lưu lượng được mã hóa có thể đi qua proxy mà proxy không kết thúc phiên TLS với đích.

Có hai câu hỏi riêng biệt: cách khách hàng kết nối với proxy, và cách nó bảo vệ lưu lượng đến đích. Một URL proxy dùng sơ đồ HTTP vẫn có thể truyền tải một đích HTTPS thông qua một đường hầm. Ngược lại, một kết nối được mã hóa tới proxy không tự động xác định cách mỗi chặng sau đó được bảo vệ như thế nào.

Một proxy kiểm tra (inspection proxy) thay đổi mô hình bằng cách chấm dứt và tạo lại các kết nối TLS. Việc triển khai như vậy phụ thuộc vào cấu hình tin cậy rõ ràng và có thể kiểm tra nội dung đã được giải mã. Đừng cho rằng tất cả proxy đều kiểm tra HTTPS, hoặc tất cả proxy đều không thể kiểm tra nó; hãy xác định kiến trúc nào thực sự đang được sử dụng.

Điều Gì Thay Đổi Khi Một CDN Chấm Dứt TLS?

Một CDN chấm dứt TLS là điểm cuối bảo mật cho kết nối của khách hàng và có thể sử dụng một kết nối riêng tới origin. CDN có thể xử lý yêu cầu HTTP đã giải mã, áp dụng các quy tắc định tuyến hoặc bộ nhớ đệm, và lấy nội dung từ origin khi cần thiết.

Kết nối tới origin có giao thức và thiết lập xác minh riêng. Một kết nối bảo mật từ khách hàng đến CDN không chứng minh rằng kết nối từ CDN đến origin sử dụng mức bảo vệ tương đương. Người vận hành website nên cấu hình và xác minh cả hai ranh giới theo yêu cầu của ứng dụng.

Kiến trúc này cũng ảnh hưởng đến những gì có thể quan sát. Chứng chỉ mà khách hàng thấy mô tả điểm cuối TLS công khai. Phản hồi HTTP có thể được phục vụ từ bộ nhớ đệm ở edge thay vì được tạo bởi origin tại thời điểm đó. Không quan sát nào trong số này, khi đứng một mình, thiết lập được vị trí hoặc trạng thái hiện tại của ứng dụng ở origin.

Các Phiên Bản HTTP Liên Quan Thế Nào Đến HTTPS?

Các phiên bản HTTP xác định hành vi truyền tải thông điệp, trong khi HTTPS mô tả nguồn gốc an toàn và các yêu cầu truyền tải. HTTP/1.1 và HTTP/2 thường được truyền qua TLS trên TCP. HTTP/3 sử dụng QUIC, tích hợp bảo mật dựa trên TLS vào lớp truyền tải của nó.

Phần ánh xạ HTTP/3 thay đổi cơ chế kết nối nhưng vẫn giữ các khái niệm HTTP như phương thức, mã trạng thái và trường. Một ứng dụng không nên giả định rằng mọi kết nối HTTPS đều tuân theo cùng một trình tự thiết lập TCP.

Thương lượng phụ thuộc vào khả năng của cả khách hàng và máy chủ cũng như đường truyền mạng sẵn có. Bật hỗ trợ trong một khách hàng không đảm bảo rằng một đích cụ thể sử dụng giao thức đó. Hãy ghi lại giao thức đã được thương lượng nếu nó quan trọng cho một cuộc điều tra về hiệu năng hoặc tương thích.

Vì Sao Chỉ Chuyển Hướng Không Thể Hiện Đầy Đủ Chính Sách HTTPS

Chuyển hướng HTTP sang HTTPS nâng cấp một yêu cầu sau khi khách hàng đã đến được điểm cuối HTTP, trong khi HSTS chỉ dẫn trình duyệt hỗ trợ sử dụng HTTPS theo chính sách đã lưu trữ của nó. Cơ chế HTTP Strict Transport Security giúp ngăn chặn các lần thử kết nối không an toàn sau đó cho các host được bao phủ.

Lần truy cập đầu tiên không có chính sách sẵn có có những đặc tính khác với một lần truy cập có chính sách đã lưu trữ hoặc được preload. Sự khác biệt này quan trọng khi giải thích vì sao chuyển hướng và chính sách HSTS mang tính bổ trợ. Không nên mô tả cái nào như bằng chứng rằng mọi tài nguyên nhúng hoặc dịch vụ nội bộ đều được cấu hình đúng.

Đối với một khách hàng API, hãy kiểm tra xem khách hàng đó thực sự triển khai những chính sách trình duyệt nào. Một thư viện Python không tự động chịu cùng trạng thái HSTS đã lưu trữ như một trình duyệt desktop. Hãy cấu hình trực tiếp URL HTTPS dự định và giữ việc xác minh chứng chỉ.

Cách Chẩn Đoán Lỗi HTTPS Theo Giai Đoạn

Hãy chẩn đoán một lỗi HTTPS bằng cách xác định giai đoạn bị lỗi: phân giải tên, kết nối, đường hầm proxy, xác minh TLS, hoặc trao đổi HTTP. Mỗi giai đoạn tạo ra bằng chứng khác nhau. Một mã trạng thái HTTP nhận được từ đích có nghĩa là kết nối đã tiến xa hơn so với lỗi xác minh chứng chỉ.

Đối với lưu lượng qua proxy, hãy phân biệt xác thực với proxy và xác thực với đích. Quy trình hiện tại Scrapeless proxy connection workflow giải thích cách lấy các thiết lập kênh đúng. Đừng gửi mật khẩu proxy tới đích như một thông tin xác thực của ứng dụng.

Phần thảo luận kiến trúc proxy SSL và TLS cung cấp bối cảnh liên quan cho hành vi đường hầm và chấm dứt. Khi đánh giá Scrapeless Proxy Solutions, hãy xác minh giao thức, mô hình tin cậy và hành vi phiên cần thiết cho khách hàng của bạn. Hãy xem lại giá của sản phẩm đã chọn tách biệt với cấu hình truyền tải của nó.

Cuối cùng, hãy kiểm tra biểu diễn được trả về. Một kết nối TLS hợp lệ và mã trạng thái HTTP thành công có thể trả về một trang đăng nhập hoặc một tài liệu ngoài dự kiến. Kiểm tra lớp truyền tải thiết lập cách các byte đến; kiểm tra nội dung thiết lập liệu những byte đó có đáp ứng nhiệm vụ thu thập hay không.

Kết Luận

HTTPS bảo vệ HTTP trong một kết nối an toàn đã được xác minh. Hãy hiểu nơi TLS chấm dứt, giữ việc xác minh chứng chỉ được bật, và chẩn đoán lỗi theo từng giai đoạn. Đối với các tuyến proxy và CDN, hãy ghi lại từng ranh giới kết nối để tuyên bố bảo mật khớp với kiến trúc thực tế.