HTTPS
Kỹ thuật > Các giới hạn

Mã hóa SSL (Secure Sockets Layer) và TLS (Transport Layer Security) có thể được cấu hình ở hai chế độ: đơn giản và tương hỗ . Trong chế độ đơn giản, xác thực chỉ được thực hiện bởi máy chủ. Phiên bản tương hỗ yêu cầu người dùng cài đặt chứng chỉ máy khách cá nhân trong trình duyệt web để xác thực người dùng. Trong cả hai trường hợp, mức độ bảo vệ phụ thuộc vào tính đúng đắn của việc triển khai phần mềm và các thuật toán mã hóa sử dụng.
SSL/TLS không ngăn chặn việc lập chỉ mục trang web bởi trình thu thập thông tin và trong một số trường hợp, URI của tài nguyên được mã hóa có thể được suy ra bằng cách chỉ biết kích thước yêu cầu / phản hồi bị chặn. Điều này cho phép kẻ tấn công có quyền truy cập vào bản rõ (nội dung tĩnh có sẵn công khai) và văn bản được mã hóa (phiên bản được mã hóa của nội dung tĩnh), cho phép tấn công bằng mật mã.
Vì TLS hoạt động ở cấp độ giao thức thấp hơn HTTP và không có kiến thức về các giao thức cấp độ cao hơn, máy chủ TLS chỉ có thể hiển thị đúng một chứng chỉ cho một tổ hợp địa chỉ và cổng cụ thể. Trước đây, điều này có nghĩa là không khả thi khi sử dụng dịch vụ lưu trữ ảo dựa trên tên với HTTPS. Có một giải pháp được gọi là Chỉ báo tên máy chủ (SNI), sẽ gửi tên máy chủ đến máy chủ trước khi mã hóa kết nối, mặc dù nhiều trình duyệt cũ không hỗ trợ tiện ích mở rộng này. Hỗ trợ cho SNI có sẵn kể từ Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 và Internet Explorer 7 trên Windows Vista.
Theo quan điểm kiến trúc hệ thống:
Kết nối SSL/TLS được máy tính đầu tiên khởi tạo kết nối TLS quản lý. Nếu vì bất kỳ lý do nào (định tuyến, tối ưu hóa lưu lượng, v.v.), máy chủ này không phải là máy chủ ứng dụng và nó phải giải mã dữ liệu, thì phải tìm ra các giải pháp để truyền thông tin xác thực người dùng hoặc chứng chỉ tới máy chủ ứng dụng, cần phải biết ai sẽ được kết nối.
Đối với SSL/TLS có xác thực lẫn nhau, phiên SSL/TLS được máy chủ đầu tiên khởi tạo kết nối quản lý. Trong các tình huống mã hóa phải được phổ biến dọc theo các máy chủ chuỗi, việc quản lý session timeOut trở nên cực kỳ khó thực hiện.
Bảo mật là tối đa với SSL/TLS tương hỗ, nhưng ở phía máy khách, không có cách nào để kết thúc đúng cách kết nối SSL/TLS và ngắt kết nối người dùng ngoại trừ bằng cách đợi phiên máy chủ hết hạn hoặc bằng cách đóng tất cả các ứng dụng máy khách liên quan.
Một kiểu tấn công man-in-the-middle tinh vi được gọi là tước đi SSL đã được trình bày tại Hội nghị Blackhat năm 2009. Kiểu tấn công này đánh bại sự bảo mật do HTTPS cung cấp bằng cách thay đổi liên kết https: thành liên kết http: :, lợi dụng thực tế là ít người dùng Internet thực sự nhập "https" vào giao diện trình duyệt của họ: họ truy cập vào một trang web an toàn bằng cách nhấp vào một liên kết và do đó bị đánh lừa rằng họ đang sử dụng HTTPS trong khi thực tế là họ đang sử dụng HTTP. Sau đó kẻ tấn công giao tiếp với khách hàng. Điều này đã thúc đẩy sự phát triển của một biện pháp đối phó trong HTTP được gọi là HTTP Strict Transport Security.
HTTPS đã được chứng minh là dễ bị tấn công bởi một loạt các cuộc tấn công phân tích lưu lượng. Các cuộc tấn công phân tích lưu lượng là một loại tấn công kênh phụ dựa trên các biến thể về thời gian và kích thước của lưu lượng truy cập để suy ra các thuộc tính về chính lưu lượng được mã hóa. Có thể phân tích lưu lượng vì mã hóa SSL / TLS thay đổi nội dung của lưu lượng, nhưng có tác động tối thiểu đến quy mô và thời gian của lưu lượng. Vào tháng 5 năm 2010, một bài báo nghiên cứu của các nhà nghiên cứu từ Microsoft Research và Đại học Indiana đã phát hiện ra rằng dữ liệu người dùng nhạy cảm chi tiết có thể được suy ra từ các kênh phụ như kích thước gói. Các nhà nghiên cứu phát hiện ra rằng, mặc dù có được bảo vệ HTTPS trong một số ứng dụng web hàng đầu, cao cấp trong lĩnh vực chăm sóc sức khỏe, thuế, đầu tư và tìm kiếm trên web, kẻ nghe trộm có thể suy ra bệnh/thuốc /phẫu thuật/ thu nhập gia đình và bí mật đầu tư  của người dùng. Mặc dù công trình này đã chứng minh tính dễ bị tổn thương của HTTPS đối với phân tích lưu lượng, nhưng cách tiếp cận mà các tác giả trình bày yêu cầu phân tích thủ công và tập trung đặc biệt vào các ứng dụng web được HTTPS bảo vệ.
Thực tế là hầu hết các trang web hiện đại, bao gồm Google, Yahoo !, và Amazon, sử dụng HTTPS gây ra sự cố cho nhiều người dùng khi cố gắng truy cập các điểm phát Wi-Fi công cộng, vì trang đăng nhập điểm phát Wi-Fi không tải được nếu người dùng cố gắng mở tài nguyên HTTPS. Một số trang web, chẳng hạn như neverssl.com và nonhttps.com, đảm bảo rằng chúng sẽ luôn có thể truy cập được bằng HTTP.