Có bất kỳ lý do để không thực thi HTTPS trên một trang web?

Một trang web tôi thường xuyên cuối cùng đã quyết định kích hoạt TLS cho máy chủ của họ, chỉ không bắt buộc nó như nhiều trang web ngoài kia làm. Người bảo trì tuyên bố rằng TLS phải là tùy chọn. Tại sao?

Trên trang web của riêng tôi, tôi đã thiết lập TLS và HSTS bắt buộc với thời gian dài và các bộ mật mã yếu hơn bị vô hiệu hóa. Quyền truy cập Plaintext được đảm bảo được bảo vệ bằng HTTP 301 cho phiên bản được bảo vệ bởi TLS. Điều này có ảnh hưởng tiêu cực đến trang web của tôi không?

Có một số lý do tốt để sử dụng TLS

(và chỉ có một vài lý do ngoài lề để không làm như vậy).

• Nếu trang web có bất kỳ xác thực nào, sử dụng HTTP phơi bày để đánh cắp phiên và mật khẩu.

• Ngay cả trên các trang web tĩnh, chỉ đơn thuần là thông tin, sử dụng TLS đảm bảo không ai bị giả mạo dữ liệu.

• Kể từ Google I / O 2014 , Google đã thực hiện một số bước để khuyến khích tất cả các trang web sử dụng HTTPS:

  • Google đã và đang giúp các quản trị web định cấu hình máy chủ của họ an toàn hơn, nhưng cũng sử dụng HTTPS làm tín hiệu xếp hạng .
  • Gần đây, Google Chrome đã bắt đầu đánh dấu các trang web HTTP là không an toàn , như là một phần của kế hoạch dài hạn để đánh dấu tất cả các trang web HTTP là không an toàn .
  • Bài giảng HTTPS của Google Chrome Developers phát biểu rõ ràng thái độ của họ.

• Blog bảo mật Mozilla cũng đã thông báo về việc không tán thành HTTP không bảo mật bằng cách cung cấp tất cả các tính năng mới cho các trang web bảo mật và dần dần loại bỏ quyền truy cập vào các tính năng của trình duyệt cho các trang web không bảo mật, đặc biệt là các tính năng gây rủi ro cho bảo mật và quyền riêng tư của người dùng .

Ngoài ra còn có một số lý do tốt để thực thi TLS

Nếu bạn đã có một chứng chỉ tin cậy rộng rãi, tại sao không luôn luôn sử dụng nó? Thực tế tất cả các trình duyệt hiện tại đều hỗ trợ TLS và đã cài đặt chứng chỉ gốc. Vấn đề tương thích duy nhất tôi thực sự thấy trong nhiều năm qua là các thiết bị Android và Thiếu thẩm quyền chứng chỉ trung gian vì Android chỉ tin tưởng trực tiếp các CA gốc. Điều này có thể dễ dàng được ngăn chặn bằng cách cấu hình máy chủ để gửi chuỗi chứng chỉ trở lại CA gốc.

Nếu nhà bảo trì của bạn vẫn muốn cho phép kết nối HTTP mà không cần trực tiếp 301 Moved Permanently, hãy nói rằng để đảm bảo quyền truy cập từ một số trình duyệt hoặc thiết bị di động thực sự cũ, không có cách nào để trình duyệt biết rằng bạn thậm chí đã cấu hình HTTPS . Hơn nữa, bạn không nên triển khai HTTP Strict Transport Security (HSTS) mà không có 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

Vấn đề của các trang web khác nhau được định cấu hình cho cả hai giao thức được Dự án Tor và Quỹ Frontier Foundation công nhận và được giải quyết bằng tiện ích mở rộng HTTPS ở mọi nơi :

Nhiều trang web trên web cung cấp một số hỗ trợ hạn chế cho mã hóa qua HTTPS, nhưng gây khó khăn khi sử dụng. Chẳng hạn, họ có thể mặc định là HTTP không được mã hóa hoặc điền vào các trang được mã hóa bằng các liên kết quay lại trang web không được mã hóa.

Nội dung hỗn hợp cũng là một vấn đề lớn do các cuộc tấn công XSS có thể xảy ra với các trang web HTTPS thông qua sửa đổi JavaScript hoặc CSS được tải thông qua kết nối HTTP không an toàn. Do đó, hiện nay tất cả các trình duyệt chính đều cảnh báo người dùng về các trang có nội dung hỗn hợp và từ chối tự động tải nó. Điều này khiến cho việc duy trì trang web không có 301chuyển hướng trên HTTP trở nên khó khăn : bạn phải đảm bảo rằng mọi trang HTTP chỉ tải bối cảnh HTTP (CSS, JS, hình ảnh, v.v.) và mỗi trang HTTPS chỉ tải nội dung HTTPS. Điều đó cực kỳ khó đạt được với cùng một nội dung trên cả hai.

Trong thời đại ngày nay, TLS + HSTS là những điểm đánh dấu rằng trang web của bạn được quản lý bởi các chuyên gia có thể tin cậy để biết họ đang làm gì. Đó là một tiêu chuẩn tối thiểu mới nổi về độ tin cậy, bằng chứng là Google cho biết họ sẽ cung cấp thứ hạng tích cực cho các trang web làm như vậy.

Ở đầu bên kia là khả năng tương thích tối đa. Vẫn còn những khách hàng lớn tuổi ngoài kia, đặc biệt là ở những nơi trên thế giới không phải là Hoa Kỳ, Châu Âu hay Trung Quốc. Plain HTTP sẽ luôn hoạt động (mặc dù, không phải lúc nào cũng hoạt động tốt ; đó là một câu chuyện khác).

TLS + HSTS: Tối ưu hóa cho xếp hạng công cụ tìm kiếm
Plain HTTP: Tối ưu hóa cho khả năng tương thích

Phụ thuộc vào những gì quan trọng hơn cho bạn.

Có một lý do chính đáng cho các trang web chỉ đọc đơn giản không sử dụng HTTPS.

• Bộ nhớ cache web không thể lưu trữ hình ảnh được vận chuyển qua HTTPS.
• Một số nơi trên thế giới có kết nối quốc tế tốc độ rất thấp, vì vậy phụ thuộc vào bộ nhớ cache.
• Lưu trữ hình ảnh từ một tên miền khác cần các kỹ năng mà bạn không thể mong đợi các nhà khai thác cho các trang web chỉ đọc nhỏ có.

Người bảo trì tuyên bố rằng TLS phải là tùy chọn. Tại sao?

Để thực sự biết câu trả lời cho câu hỏi này, bạn phải hỏi họ. Tuy nhiên, chúng ta có thể đoán một số.

Trong môi trường doanh nghiệp, CNTT thường cài đặt tường lửa kiểm tra lưu lượng đến và đi đối với phần mềm độc hại, hoạt động đáng ngờ giống như CnC, nội dung được coi là không phù hợp cho công việc (ví dụ: nội dung khiêu dâm), v.v. Điều này trở nên khó khăn hơn khi lưu lượng được mã hóa. Về cơ bản có ba phản ứng có thể xảy ra:

1. Hãy từ bỏ việc theo dõi lưu lượng này.
2. Cài đặt CA gốc trên máy của người dùng để bạn có thể thực hiện kiểm tra và giải mã MitM.
3. Bán buôn khối mã hóa lưu lượng.

Đối với một sysadmin có liên quan, không có tùy chọn nào trong số này là đặc biệt hấp dẫn. Có rất nhiều mối đe dọa tấn công mạng công ty và công việc của họ là bảo vệ công ty chống lại họ. Tuy nhiên, việc chặn rất nhiều trang web hoàn toàn làm tăng lượng người dùng và cài đặt CA gốc có thể cảm thấy hơi khó chịu, vì nó giới thiệu các cân nhắc về quyền riêng tư và bảo mật cho người dùng. Tôi nhớ đã nhìn thấy (xin lỗi, không thể tìm thấy chủ đề) một reddit thỉnh cầu sysadmin khi họ lần đầu tiên bật HSTS vì anh ta ở trong tình huống này chính xác và không muốn chặn tất cả các reddit đơn giản vì anh ta bị doanh nghiệp ép buộc để chặn các subreddits tập trung vào khiêu dâm.

Các bánh xe công nghệ tiếp tục phát triển, và bạn sẽ thấy nhiều người cho rằng loại bảo vệ này là lỗi thời và cần được loại bỏ. Nhưng vẫn còn nhiều người thực hành nó, và có lẽ đó là người mà người bảo trì bí ẩn của bạn quan tâm.

Tất cả xuất phát từ yêu cầu bảo mật của bạn, sự lựa chọn của người dùng và nguy cơ hạ cấp ngầm. Việc vô hiệu hóa phía máy chủ mật mã cũ phần lớn là cần thiết bởi vì các trình duyệt sẽ vui vẻ chuyển sang các thuật toán mã hóa hoàn toàn khủng khiếp phía máy khách dưới danh nghĩa trải nghiệm / tiện lợi của người dùng. Đảm bảo không có gì của bạn phụ thuộc vào kênh an toàn cho người dùng không thể đạt được bằng một phương pháp không an toàn, tất nhiên, cũng rất âm thanh.

Không cho phép tôi hạ cấp rõ ràng xuống HTTP không an toàn khi tôi cho rằng bài đăng trên blog của bạn về lý do tại sao bạn thích Python hơn Ruby (không nói bạn làm, chỉ là một ví dụ chung chung) không phải là điều tôi quan tâm đến những kẻ ma quái hay công chúng biết Tôi truy cập chỉ là cản trở tôi mà không có lý do chính đáng, với giả định rằng HTTPS sẽ là tầm thường đối với tôi.

Ngày nay, có những hệ thống nhúng không có khả năng sử dụng TLS ngoài hộp hoặc những hệ thống bị mắc kẹt trong các triển khai cũ (tôi nghĩ thật tệ khi điều này là như vậy, nhưng với tư cách là người sử dụng năng lượng của [chèn nhúng thiết bị ở đây], đôi khi tôi không thể thay đổi điều này).

Đây là một thử nghiệm thú vị: hãy thử tải xuống một phiên bản LibreSSL gần đây từ trang OpenBSD ngược dòng qua HTTPS với triển khai TLS / SSL đủ cũ. Bạn sẽ không thể. Tôi đã thử một ngày khác trên một thiết bị có bản dựng OpenSSL cũ hơn từ năm 2012 hoặc lâu hơn, vì tôi muốn nâng cấp hệ thống nhúng này thành các công cụ mới, an toàn hơn từ nguồn - Tôi không có sự sang trọng của gói dựng sẵn. Các thông báo lỗi khi tôi thử không chính xác trực quan, nhưng tôi cho rằng đó là do OpenSSL cũ của tôi không hỗ trợ đúng thứ.

Đây là một ví dụ trong đó động thái duy nhất - HTTPS thực sự có thể gây bất lợi cho mọi người: nếu bạn không có sự sang trọng của các gói dựng sẵn gần đây và muốn tự khắc phục sự cố bằng cách xây dựng từ nguồn, bạn đã bị khóa. Rất may, trong trường hợp LibreSSL, bạn có thể quay lại yêu cầu HTTP rõ ràng. Chắc chắn, điều này sẽ không cứu bạn khỏi kẻ tấn công đã viết lại lưu lượng truy cập của bạn, có khả năng thay thế các gói nguồn bằng các phiên bản bị xâm nhập và viết lại tất cả các tổng kiểm tra trong các phần thân HTTP mô tả các gói có sẵn để tải xuống trên các trang web bạn duyệt, nhưng nó vẫn hữu ích trong phần lớn trường hợp phổ biến hơn.

Hầu hết chúng ta không tải xuống một cách không bảo đảm khỏi việc sở hữu bởi một APT (Chủ đề liên tục nâng cao: biệt ngữ bảo mật cho các cơ quan tình báo quốc gia và các mối đe dọa mạng có nguồn lực rất tốt khác). Đôi khi tôi chỉ muốn wgetmột số tài liệu văn bản đơn giản hoặc một chương trình nhỏ có nguồn mà tôi có thể nhanh chóng kiểm tra (ví dụ: các tiện ích / tập lệnh nhỏ của riêng tôi trên GitHub) vào một hộp không hỗ trợ các bộ mật mã gần đây nhất.

Cá nhân, tôi hỏi điều này: nội dung của bạn sao cho một người có thể quyết định một cách hợp pháp "Tôi ổn khi tôi tiếp cận với kiến ​​thức công cộng"? Có khả năng rủi ro thực sự đối với những người không có kỹ thuật vô tình hạ cấp xuống HTTP cho nội dung của bạn không? Cân nhắc các yêu cầu bảo mật của bạn, các yêu cầu bảo mật cho người dùng của bạn và nguy cơ hạ cấp ngầm đối với khả năng người dùng hiểu các rủi ro đưa ra lựa chọn sáng suốt trong từng trường hợp cụ thể không được bảo đảm. Hoàn toàn hợp pháp khi nói rằng đối với trang web của bạn, không có lý do chính đáng nào để không thi hành HTTPS - nhưng tôi nghĩ thật công bằng khi nói rằng vẫn còn những trường hợp sử dụng tốt cho HTTP đơn giản ngoài kia.

Có rất nhiều cuộc thảo luận ở đây về lý do tại sao tls là tốt - nhưng điều đó không bao giờ được hỏi như trong bài viết gốc.

Maxthon hỏi 2 câu hỏi:

1) tại sao có một trang web ngẫu nhiên, chưa được đặt tên đã quyết định duy trì cả sự hiện diện của http và https

2) Có tác động tiêu cực đến Maxthon chỉ phục vụ 301 phản hồi cho các yêu cầu http

Đối với câu hỏi đầu tiên, chúng tôi không biết lý do tại sao các nhà cung cấp chọn giữ lại cả trang web http và https. Có thể có rất nhiều lý do. Ngoài các điểm về khả năng tương thích, bộ nhớ đệm phân tán và một số gợi ý về khả năng tiếp cận chính trị địa lý, cũng có một sự cân nhắc về tích hợp nội dung và tránh các thông điệp trình duyệt xấu về nội dung không an toàn. Như Alvaro đã chỉ ra, TLS chỉ là phần nổi của tảng băng liên quan đến an ninh.

Câu hỏi thứ hai, tuy nhiên là có thể trả lời. Việc hiển thị bất kỳ phần nào trên trang web của bạn thông qua http khi thực sự cần https để hoạt động an toàn cung cấp một vectơ có thể khai thác cho các cuộc tấn công. Tuy nhiên, sẽ rất hợp lý khi duy trì điều này để xác định nơi lưu lượng truy cập được chuyển hướng không chính xác đến cổng 80 trên trang web của bạn và khắc phục nguyên nhân. Tức là có cả tác động tiêu cực và cơ hội cho tác động tích cực, kết quả ròng phụ thuộc vào việc bạn có làm công việc quản trị viên hay không.

Sysadmin1138 nói rằng https tác động đến thứ hạng seo. Mặc dù Google đã tuyên bố rằng nó có tác động đến thứ hạng, nhưng các nghiên cứu đáng tin cậy duy nhất tôi thấy cho thấy sự khác biệt là nhỏ. Điều này không được giúp đỡ bởi những người nên biết rõ hơn khi tuyên bố rằng, vì các trang web được xếp hạng hàng đầu có nhiều khả năng có sự hiện diện của https, do đó sự hiện diện của https sẽ cải thiện thứ hạng.

Trước đây, tôi đã phải sử dụng HTTP thay vì HTTPS vì tôi muốn <embed>các trang từ nơi khác được cung cấp qua HTTP và chúng sẽ không hoạt động theo cách khác.

Đây không phải là tốt lý do, vì nó có nghĩa là bạn đã xấu / chia / khách hàng không an toàn, nhưng nếu có quy trình tự động truy cập vào các nguồn tài nguyên thông qua hiện http://url, nó có thể là một số trong số họ thậm chí không hỗ trợ https (ví dụ busybox wget, mà doesn Không có hỗ trợ TLS trong nội bộ và chỉ thêm nó gần đây thông qua quy trình con openssl) và sẽ bị hỏng nếu chúng được chuyển hướng đến url https mà chúng không thể theo dõi.

Tôi sẽ cố gắng giải quyết khả năng này bằng cách viết quy tắc chuyển hướng để loại trừ các chuỗi Tác nhân người dùng chưa biết (hoặc đã biết) được chuyển hướng và cho phép họ truy cập nội dung qua http nếu họ muốn, để các trình duyệt thực tế có thể hưởng lợi từ bắt buộc https / hsts.

Có rất ít tốt lý do cho việc sử dụng HTTP thay vì HTTPS trên một trang web. Nếu trang web của bạn xử lý các giao dịch dưới bất kỳ hình thức nào hoặc lưu trữ bất kỳ loại dữ liệu nhạy cảm hoặc dữ liệu cá nhân nào, bạn phải tuyệt đối sử dụng HTTPS nếu bạn muốn bảo mật dữ liệu. Lý do chính đáng duy nhất tôi thấy khi không thi hành HTTPS là nếu trang web của bạn phụ thuộc vào bộ đệm vì HTTPS không hoạt động với bộ đệm. Tuy nhiên, thường đáng để hy sinh một chút hiệu suất để đảm bảo an toàn cho trang web của bạn. Cũng có thể khách hàng của bạn có thể không hỗ trợ HTTPS, nhưng thực sự, trong năm 2017, họ nên làm vậy.