Tại sao không sử dụng HTTPS cho mọi thứ?

Nếu tôi đang thiết lập máy chủ và có (các) chứng chỉ SSL, tại sao tôi không sử dụng HTTPS cho toàn bộ trang web thay vì chỉ để mua / đăng nhập? Tôi nghĩ sẽ tốt hơn nếu chỉ mã hóa toàn bộ trang web và bảo vệ người dùng hoàn toàn. Nó sẽ ngăn chặn các vấn đề như quyết định những gì phải được bảo mật bởi vì mọi thứ sẽ được, và nó không thực sự gây bất tiện cho người dùng.

Nếu tôi đã sử dụng HTTPS cho một phần của trang web, tại sao tôi không muốn sử dụng nó cho toàn bộ trang web?

Đây là một câu hỏi liên quan: Tại sao https chỉ được sử dụng để đăng nhập? , nhưng câu trả lời không thỏa đáng. Các câu trả lời cho rằng bạn không thể áp dụng https cho toàn bộ trang web.

Tôi có thể nghĩ ra một vài lý do.

• Một số trình duyệt có thể không hỗ trợ SSL.
• SSL có thể làm giảm hiệu suất phần nào. Nếu người dùng đang tải xuống các tệp lớn, công khai, có thể có một gánh nặng hệ thống để mã hóa chúng mỗi lần.

Ngoài các lý do khác (đặc biệt là liên quan đến hiệu suất), bạn chỉ có thể lưu trữ một tên miền cho mỗi địa chỉ IP * khi sử dụng HTTPS.

Một máy chủ có thể hỗ trợ nhiều tên miền trong HTTP vì tiêu đề HTTP của Máy chủ cho phép máy chủ biết tên miền nào sẽ phản hồi.

Với HTTPS, máy chủ phải cung cấp chứng chỉ của nó cho máy khách trong quá trình bắt tay TLS ban đầu (trước khi HTTP bắt đầu). Điều này có nghĩa là tiêu đề Máy chủ chưa được gửi đi nên không có cách nào để máy chủ biết tên miền nào đang được yêu cầu và chứng chỉ nào (www.foo.com hoặc www.bar.com) để phản hồi.

* Chú thích: Về mặt kỹ thuật, bạn có thể lưu trữ nhiều tên miền nếu bạn lưu trữ chúng trên các cổng khác nhau, nhưng đó thường không phải là một tùy chọn. Bạn cũng có thể lưu trữ nhiều tên miền nếu chứng chỉ SSL của bạn có thẻ đại diện. Ví dụ: bạn có thể lưu trữ cả foo.example.com và bar.example.com với chứng chỉ * .example.com

SSL / TLS không được sử dụng gần như đủ thường xuyên. HTTPS phải được sử dụng cho toàn bộ phiên , không có lúc nào ID phiên có thể được gửi qua HTTP. Nếu bạn chỉ sử dụng https để đăng nhập thì bạn đã vi phạm rõ ràng Top 10 của OWASP cho năm 2010 "A3: Xác thực bị hỏng và Quản lý phiên".

Tại sao không gửi tất cả các bài đăng thư trong một phong bì mờ chống giả mạo bằng Thư đăng ký? Một người nào đó từ Bưu điện sẽ luôn có quyền giám hộ cá nhân đối với nó, vì vậy bạn có thể khá chắc chắn rằng không ai rình mò thư của bạn. Rõ ràng, câu trả lời là trong khi một số thư đáng giá, thì hầu hết thư không có. Tôi không quan tâm nếu có ai đọc "Vui mừng bạn đã ra tù!" bưu thiếp cho chú Joe.

Mã hóa không miễn phí và không phải lúc nào cũng giúp.

Nếu một phiên (chẳng hạn như mua sắm, ngân hàng, v.v.) sẽ kết thúc bằng cách sử dụng HTTPS, không có lý do chính đáng nào để không thực hiện toàn bộ HTTPS sớm nhất có thể.

Ý kiến ​​của tôi là HTTPS chỉ nên được sử dụng khi không thể tránh khỏi cần thiết, bởi vì yêu cầu hoặc phản hồi cần được bảo vệ khỏi việc rình mò trung gian. Ví dụ, hãy xem Yahoo! trang chủ. Mặc dù bạn đã đăng nhập, hầu hết các tương tác của bạn sẽ qua HTTP. Bạn xác thực qua HTTPS và nhận cookie chứng minh danh tính của bạn, vì vậy bạn không cần HTTPS để đọc các câu chuyện tin tức.

Lý do lớn nhất, ngoài tải hệ thống, là nó phá vỡ lưu trữ ảo dựa trên tên. Với SSL, đó là một trang web - một địa chỉ IP. Điều này là khá tốn kém, cũng như khó quản lý hơn.

Đối với các liên kết có độ trễ cao, bắt tay TLS ban đầu yêu cầu các chuyến đi khứ hồi bổ sung để xác thực chuỗi chứng chỉ (bao gồm gửi bất kỳ chứng chỉ trung gian nào), đồng ý về các bộ mật mã và thiết lập một phiên. Khi một phiên được thiết lập, các yêu cầu tiếp theo có thể sử dụng bộ đệm ẩn phiên để giảm số lượng chuyến đi khứ hồi nhưng ngay cả trong trường hợp tốt nhất này vẫn có nhiều chuyến đi khứ hồi hơn so với kết nối HTTP thông thường. Ngay cả khi các hoạt động mã hóa là các chuyến đi khứ hồi miễn phí thì không và có thể khá đáng chú ý đối với các liên kết mạng chậm hơn, đặc biệt là nếu trang web không tận dụng đường ống http. Đối với người dùng băng thông rộng trong một phân đoạn được kết nối tốt của mạng thì đây không phải là vấn đề. Nếu bạn kinh doanh quốc tế, yêu cầu https có thể dễ dàng gây ra sự chậm trễ đáng chú ý.

Có những cân nhắc bổ sung như bảo trì máy chủ trạng thái phiên đòi hỏi nhiều bộ nhớ hơn và tất nhiên là hoạt động mã hóa dữ liệu. Bất kỳ trang web nhỏ nào trên thực tế không cần phải lo lắng về khả năng máy chủ được cung cấp so với chi phí phần cứng ngày nay. Bất kỳ trang web lớn nào cũng có thể dễ dàng đủ khả năng giảm tải CPU / w AES hoặc thẻ bổ trợ để cung cấp chức năng tương tự.

Tất cả những vấn đề này đang ngày càng trở thành một vấn đề không phải là vấn đề khi thời gian trôi qua và khả năng của phần cứng và mạng được cải thiện. Trong hầu hết các trường hợp tôi nghi ngờ có bất kỳ sự khác biệt hữu hình ngày hôm nay.

Có thể có những cân nhắc về hoạt động như hạn chế quản trị đối với lưu lượng https (nghĩ rằng các bộ lọc nội dung trung gian..et al) có thể là một số quy định của công ty hoặc chính phủ. Một số môi trường doanh nghiệp yêu cầu giải mã dữ liệu theo chu vi để ngăn chặn rò rỉ thông tin ... can thiệp vào điểm truy cập và các hệ thống truy cập dựa trên web tương tự không có khả năng tiêm tin nhắn trong các giao dịch https. Vào cuối ngày, theo quan điểm của tôi, lý do không đi https theo mặc định có thể khá nhỏ.

https đói nhiều tài nguyên hơn so với http thông thường.

Nó đòi hỏi nhiều hơn từ cả máy chủ và máy khách.

Nếu toàn bộ phiên được mã hóa thì bạn sẽ không thể sử dụng bộ đệm cho các tài nguyên tĩnh như hình ảnh và js ở cấp proxy, ví dụ như ISP.

Bạn nên sử dụng HTTPS ở mọi nơi, nhưng bạn sẽ mất những điều sau:

1. Bạn chắc chắn không nên sử dụng Nén SSL hoặc Nén HTTP qua SSL, do các cuộc tấn công BREACH và CRIME. Vì vậy, không nén nếu phản hồi của bạn chứa định danh phiên hoặc csrf. Bạn có thể giảm thiểu điều này bằng cách đặt tài nguyên tĩnh (hình ảnh, js, css) của mình vào miền không có cookie và sử dụng nén ở đó. Bạn cũng có thể sử dụng khai thác HTML.

2. Một chứng chỉ SSL, một địa chỉ IP, trừ khi sử dụng SNI, không hoạt động trên tất cả các trình duyệt (android cũ, blackberry 6, v.v.).

3. Bạn không nên lưu trữ bất kỳ nội dung bên ngoài nào trên các trang của bạn không qua SSL.

4. Bạn mất tiêu đề Người giới thiệu HTTP bên ngoài khi trình duyệt chuyển đến trang HTTP, điều này có thể hoặc không phải là vấn đề đối với bạn.

Chà, lý do rõ ràng là hiệu năng: tất cả dữ liệu sẽ phải được mã hóa bởi máy chủ trước khi truyền và sau đó được khách hàng giải mã khi nhận, điều này thật lãng phí thời gian nếu không có dữ liệu nhạy cảm. Nó cũng có thể ảnh hưởng đến bao nhiêu trang web của bạn được lưu trữ.

Nó cũng có khả năng gây nhầm lẫn cho người dùng cuối nếu tất cả các địa chỉ sử dụng https://thay vì quen thuộc http://. Ngoài ra, xem câu trả lời này:

Tại sao không luôn luôn sử dụng https khi bao gồm tệp js?

https yêu cầu máy chủ mã hóa và giải mã các yêu cầu và phản hồi của khách hàng. Tác động hiệu suất sẽ tăng lên nếu máy chủ phục vụ nhiều khách hàng. Đó là lý do tại sao hầu hết các triển khai https hiện tại chỉ giới hạn ở xác thực mật khẩu. Nhưng với sức mạnh tính toán ngày càng tăng, điều này có thể thay đổi, sau khi tất cả Gmail đang sử dụng SSL cho toàn bộ trang web.

Ngoài phản hồi của WhirlWind, bạn nên xem xét chi phí và khả năng áp dụng của chứng chỉ SSL, các vấn đề truy cập (có thể, mặc dù không thể, rằng khách hàng có thể không thể giao tiếp qua cổng SSL), v.v.

Sử dụng SSL không phải là một bảo mật an toàn. Loại bảo vệ này cần được xây dựng trong kiến ​​trúc của ứng dụng, thay vì cố gắng dựa vào một số viên đạn ma thuật.

Tôi được cho biết rằng trong một dự án tại công ty chúng tôi, họ thấy rằng băng thông được chiếm bởi các tin nhắn SSL nhiều hơn đáng kể so với các tin nhắn đơn giản. Tôi tin rằng ai đó đã nói với tôi rằng đó là một dữ liệu đáng kinh ngạc gấp 12 lần. Tôi chưa tự mình xác minh điều này và nghe có vẻ rất cao, nhưng nếu có một loại tiêu đề nào đó được thêm vào mỗi trang và hầu hết các trang có một lượng nhỏ nội dung, điều đó có thể không quá xa.

Điều đó nói rằng, rắc rối của việc qua lại giữa http và https và theo dõi những trang nào có vẻ như quá nhiều nỗ lực đối với tôi. Tôi chỉ một lần cố gắng xây dựng một trang web trộn lẫn chúng và cuối cùng chúng tôi đã từ bỏ kế hoạch khi chúng tôi gặp phải những thứ phức tạp như cửa sổ bật lên được tạo bởi Javascript có giao thức sai gắn với chúng và loại đó. Chúng tôi cuối cùng chỉ làm cho toàn bộ trang https trở nên ít rắc rối hơn. Tôi đoán trong những trường hợp đơn giản là bạn chỉ cần có màn hình đăng nhập và màn hình thanh toán cần được bảo vệ và chúng là những trang đơn giản, sẽ không phải là vấn đề lớn để trộn lẫn.

Tôi sẽ không lo lắng nhiều về gánh nặng của khách hàng để giải mã. Thông thường, khách hàng sẽ mất nhiều thời gian hơn để chờ dữ liệu đi qua dây hơn là xử lý nó. Cho đến khi người dùng thường xuyên có kết nối internet gigabit / giây, khả năng xử lý của khách hàng có thể không liên quan. Sức mạnh CPU được máy chủ yêu cầu để mã hóa các trang là một vấn đề khác. Cũng có thể có vấn đề về việc không thể theo kịp hàng trăm hoặc hàng ngàn người dùng.

Một điểm nhỏ khác (có thể ai đó có thể xác minh), Nếu người dùng nhập dữ liệu vào một mục biểu mẫu như hộp văn bản và sau đó vì lý do nào đó làm mới trang hoặc máy chủ gặp sự cố trong một giây, dữ liệu người dùng đã nhập sẽ bị mất khi sử dụng HTTPS nhưng được bảo tồn bằng HTTP.

Lưu ý: Tôi không chắc đây có phải là trình duyệt cụ thể không nhưng chắc chắn nó sẽ xảy ra với trình duyệt Firefox của tôi.

windows Server 2012 với IIS 8.0 hiện cung cấp SNI, đó là Chỉ định tên máy chủ cho phép nhiều ứng dụng web SSL trong IIS được lưu trữ trên một Địa chỉ IP.