Lợi ích của việc buộc một trang web tải qua SSL (HTTPS) là gì?


55

Giả sử tôi có một trang web chỉ có nội dung lớn; không đăng nhập hoặc đăng xuất, không có tên người dùng, không địa chỉ email, không có khu vực an toàn, không có gì bí mật trên trang web, nada. Mọi người chỉ cần đến trang web và đi từ trang này sang trang khác và xem nội dung.

Bên cạnh một cú va chạm nhẹ trong SEO từ Google ( rất nhẹ, từ những gì tôi đã đọc), có bất kỳ lợi ích nào khi buộc trang web tải thông qua HTTPS không?


1
Tôi không tin đây là bản sao của Force Sử dụng SSL trên Trang web bây giờ? . Mặc dù một số câu trả lời cuối cùng có thể giống nhau, nhưng câu hỏi đó đang xin lời khuyên về việc có nên sử dụng SSL hay không trong khi câu hỏi này thì không. Nếu bất cứ điều gì, câu hỏi khác nên được đóng lại để được dựa trên ý kiến.
Stephen Ostermiller

4
Hãy lật lại điều này: lợi ích của việc KHÔNG sử dụng SSL là gì? Không có bất cứ điều gì tôi biết. Ồ chắc chắn, việc thực hiện sẽ là một lần và mất (so với mọi thứ khác) không có thời gian. Vì vậy, nếu một cách tiếp cận không có nhược điểm và một số nhược điểm, thì cách tiếp cận khác không có nhược điểm và (theo bạn) không có nhược điểm, vậy thì ... tại sao lại gắn bó với phương pháp sau?
VLAZ

3
@Vld - hiệu suất. Ngày nay, chúng tôi thường cố gắng tối ưu hóa thời gian tải ban đầu của trang web thành các số liệu hiệu suất dưới giây, với mục tiêu là 1/2 giây. Trên kết nối internet hơi chậm (độ trễ gói khoảng 100ms), bắt tay SSL có thể dễ dàng mất 300ms, điều này có thể đẩy bạn vượt qua mục tiêu hiệu suất. Đối với người dùng di động thì điều tồi tệ hơn: mạng di động có độ trễ gói dài hơn và thời gian xử lý để xác minh chứng nhận có thể dễ dàng là vài trăm ms trên điện thoại chậm hơn.
Jules

6
Các nhà mạng di động luôn can thiệp vào lưu lượng HTTP không được mã hóa, cho dù đó là để nén hình ảnh (quá mức), tiêm Javascript xấu hay các tiêu đề kiểm soát bộ đệm gây khó chịu hơn. HTTPS sẽ ngăn chặn tất cả những điều vô nghĩa đó.
André Borie

2
@Josef Không đúng. HTTP / 2 cũng hoạt động trên các kết nối không được mã hóa. Không có trình duyệt nào có thể làm điều đó, nhưng đó là giới hạn trình duyệt, không phải HTTP / 2. Nói rằng "HTTP / 2 chỉ hoạt động trên TLS" giống như nói rằng "công nghệ X không hoạt động vì Internet Explorer không triển khai nó". Hãy nhìn nơi nó đưa chúng ta.
Đặc vụ_L

Câu trả lời:


84

HTTPS không chỉ cung cấp bí mật (trong đó bạn nghi ngờ về giá trị, mặc dù vẫn có lý do chính đáng cho nó) mà còn cả tính xác thực , luôn luôn có giá trị. Không có nó, một điểm truy cập / bộ định tuyến / ISP / vv độc hại. có thể viết lại bất kỳ phần nào của trang web của bạn trước khi hiển thị nó cho người dùng. Điều này có thể bao gồm:

  • tiêm quảng cáo cho đối thủ của bạn
  • tiêm quảng cáo hoặc các vật dụng gây phiền nhiễu làm cho trang web của bạn trông xấu và làm tổn hại đến danh tiếng của bạn
  • tiêm khai thác để thực hiện tải phần mềm độc hại theo ổ đĩa vào máy tính của khách truy cập, người sau đó (đúng!) đổ lỗi cho bạn vì điều đó xảy ra
  • thay thế phần mềm tải xuống từ trang web của bạn bằng phần mềm độc hại đi kèm
  • giảm chất lượng hình ảnh của bạn
  • xóa các phần của trang web của bạn mà họ không muốn bạn nhìn thấy, ví dụ: những thứ cạnh tranh với các dịch vụ của họ hoặc mô tả chúng trong một ánh sáng xấu
  • Vân vân.

Không bảo vệ người dùng của bạn khỏi những điều này là vô trách nhiệm.


27
@Mike Không hẳn. Có rất nhiều phần mềm sẵn có để làm điều này, và tất cả đều xử lý giải nén và giải nén tốt.
ceejayoz

3
@Mike Không hẳn. Một proxy viết lại đầy đủ có thể giải mã tất cả lưu lượng truy cập và tiêm bất cứ thứ gì mới mà nó muốn một lần nữa.
Nayuki

10
FYI nhất nếu không phải tất cả các ví dụ của tôi đã thực sự được nhìn thấy trong tự nhiên.
R ..

2
@DavidMulder bình luận đầu tiên của bạn cho biết " de tập trung hóa [...] không phải là một điều tốt"
jiggunjer

3
Chúng ta có thể vui lòng không biến những bình luận về câu trả lời này thành một câu nói ngớ ngẩn ngoài chủ đề về những vấn đề không liên quan không?
R ..

25

"không có gì bí mật trên trang web"

... Theo bạn . Có một lý do hoàn toàn tốt đẹp ai đó muốn kết nối an toàn. Nó (một phần) tạo sự riêng tư:

Quản trị viên của tôi có thể thấy rằng tôi đang duyệt một số trang web hình ảnh trên điện thoại của mình qua url, nhưng anh ta không thể biết được tôi đang xem những bức ảnh của những chú mèo dễ thương hay khiêu dâm khó tính. Tôi muốn nói rằng đó là quyền riêng tư khá tốt. "Một nội dung" và "nội dung" có thể tạo ra tất cả sự khác biệt trên thế giới. - Đặc vụ_L

Bạn có thể nghĩ rằng nó không đáng kể, hoặc có thể bây giờ nó không phải là vấn đề lớn nhưng có thể ở một thời điểm khác. Tôi là một người tin tưởng vững chắc rằng không ai ngoài tôi và trang web nên biết chính xác những gì tôi đang làm.

Nó tạo ra niềm tin. Có ổ khóa là một dấu hiệu của bảo mật và nó có thể biểu thị một số mức độ kỹ năng liên quan đến trang web, và do đó, các sản phẩm của bạn.

Nó làm cho bạn ít mục tiêu hơn cho các cuộc tấn công MitM. An ninh gia tăng.

Với các sáng kiến ​​như Let Encrypt , giúp việc này trở nên dễ dàng và miễn phí hơn rất nhiều , không có nhiều nhược điểm. Sức mạnh CPU chiếm bởi SSL là không đáng kể những ngày này.


11
Thật không may, SSL không ngăn CNTT công ty hoặc ISP của bạn hoặc mọi người trên wifi quán cà phê công cộng với bạn biết bạn đang truy cập trang web nào. Việc tra cứu DNS vẫn được thực hiện rõ ràng . Mặc dù họ không thể xem nội dung, cũng không phải URL chính xác, thậm chí bạn không sử dụng trình duyệt web, nhưng họ có thể thấy rằng bạn đang truy cập vào trang web dương vật (tất nhiên, đây là một trang dành cho những người đam mê bút, nhưng có thể bị hiểu sai). Sử dụng proxy VPN hoặc SOCKS5 sẽ bảo vệ các truy vấn DNS của bạn.
Schwern

3
@Martijn: Với Chỉ định Tên Máy chủ (mà tất cả các trình duyệt hiện đại hỗ trợ), tên máy chủ của trang web sẽ được gửi rõ ràng như một phần của bắt tay HTTPS. Đây không chỉ là vấn đề của các cuộc tấn công sidechannel và không thể được giảm nhẹ bằng ví dụ DNSsec.
Kevin

3
@Schwern Tôi chưa bao giờ hiểu lập luận rằng HTTPS không bảo vệ tên máy chủ vì việc tra cứu DNS và SNI và chứng chỉ của máy chủ rõ ràng. Tất nhiên điều đó đúng như đã nêu, nhưng HTTP văn bản đơn giản không có nghĩa là tốt hơn về vấn đề này!
một CVn

5
@Schwern Quản trị viên của tôi có thể thấy rằng tôi đang duyệt tumblr trên điện thoại của mình, nhưng anh ta không thể biết được tôi đang xem những bức ảnh của những chú mèo dễ thương hay khiêu dâm khó tính. Tôi muốn nói rằng đó là quyền riêng tư khá tốt. "Một nội dung" và "nội dung" có thể tạo ra tất cả sự khác biệt trên thế giới.
Đặc vụ_L

2
@Agent_L Không, thậm chí đó không phải là lời khuyên tốt. Nếu bạn truy cập https://penisland.tumblr.com/trình duyệt của mình sẽ thực hiện yêu cầu DNS penisland.tumblr.com, trừ khi bạn bảo vệ các truy vấn DNS của mình, quản trị viên mạng có thể thấy. Sau đó, trình duyệt của bạn phải lấy hình ảnh, Javascript, CSS và quảng cáo từ nhiều miền khác nhau tạo ra nhiều yêu cầu DNS hơn. Họ có thể từ bất kỳ tên miền. Một vài tên miền Tumblr khiêu dâm mà tôi đã thử không có gì rõ ràng, Tumblr có xu hướng lưu trữ hình ảnh và video trong nhà, nhưng bạn không thể dựa vào đó để bảo mật.
Schwern 11/07/2016

12

Bạn nhận được hỗ trợ HTTP / 2 , tiêu chuẩn web mới được thiết kế để cải thiện đáng kể tốc độ tải trang web .

Vì các nhà sản xuất trình duyệt đã chọn chỉ hỗ trợ HTTP / 2 qua HTTPS, cho phép HTTPS (trên máy chủ hỗ trợ HTTP / 2) là cách duy nhất để nâng cấp tốc độ này.


1
Điều này là khá lớn và cần phải được thổi phồng nhiều hơn. Nó tạo ra một trường hợp kinh doanh để tải HTTPS mà hầu hết các nhà quản lý có thể nhận được phía sau.
Dewi Morgan

10

(Các phần được lấy từ câu trả lời của tôi cho một câu hỏi tương tự.)


HTTPS có thể đạt được hai điều:

  • Xác thực . Đảm bảo rằng khách truy cập đang liên lạc với chủ sở hữu tên miền thực.
  • Mã hóa . Đảm bảo rằng chỉ chủ sở hữu tên miền này và khách truy cập có thể đọc thông tin liên lạc của họ.

Có lẽ mọi người đều đồng ý rằng HTTPS nên bắt buộc khi truyền bí mật (như mật khẩu, dữ liệu ngân hàng, v.v.), nhưng ngay cả khi trang web của bạn không xử lý các bí mật đó, vẫn có một số trường hợp khác và tại sao việc sử dụng HTTPS có thể có lợi.

Kẻ tấn công không thể can thiệp vào nội dung được yêu cầu.

Khi sử dụng HTTP, những kẻ nghe trộm có thể thao túng nội dung mà khách truy cập của bạn nhìn thấy trên trang web của bạn. Ví dụ:

  • Bao gồm phần mềm độc hại trong phần mềm bạn cung cấp để tải xuống (hoặc nếu bạn không cung cấp bất kỳ phần mềm tải xuống nào, những kẻ tấn công bắt đầu làm như vậy).
  • Kiểm duyệt một số nội dung của bạn. Thay đổi ý kiến ​​của bạn.
  • Tiêm quảng cáo.
  • Thay thế dữ liệu của tài khoản đóng góp của bạn bằng tài khoản của riêng họ.

HTTPS có thể ngăn chặn điều này.

Kẻ tấn công không thể đọc nội dung được yêu cầu.

Khi sử dụng HTTP, những kẻ nghe trộm có thể tìm hiểu những trang / nội dung nào trên máy chủ của bạn mà khách truy cập của bạn truy cập. Mặc dù nội dung có thể là công khai, nhưng kiến ​​thức mà một người cụ thể sử dụng có thể có vấn đề:

  • Nó mở ra một vector tấn công cho kỹ thuật xã hội .
  • Nó xâm phạm quyền riêng tư.
  • Nó có thể dẫn đến sự giám sát và trừng phạt (phải chịu tù đày, tra tấn, tử hình).

Điều này, tất nhiên, phụ thuộc vào bản chất của nội dung của bạn, nhưng những gì dường như là nội dung vô hại đối với bạn có thể được các bên khác diễn giải khác nhau.

Tốt hơn là an toàn hơn xin lỗi. HTTPS có thể ngăn chặn điều này.


1
Thật vậy, HTTPS có thể ngăn chặn nó. Trong một số tình huống, nó có thể không. Xem Lenovo Superfish cho một ví dụ khá gần đây.
một CVn

@ MichaelKjorling: Vâng, tôi biết điều này (đó là lý do tại sao tôi chắc chắn sử dụng "có thể";)), nhưng đó là vấn đề xuất phát từ hành vi của khách truy cập, không phải là vấn đề với chính HTTPS hoặc cách quản trị trang web sử dụng đúng? Khách truy cập nên quan tâm đến việc tin cậy CA nào (và khách truy cập nên quan tâm đến việc cài đặt phần mềm nào, đặc biệt là nếu phần mềm đó có quyền sử dụng danh sách các CA đáng tin cậy).
unor

Thật; Tôi không tranh luận về quan điểm của bạn, chỉ thêm vào đó!
một CVn

6

Nó ngăn chặn người đàn ông trong các cuộc tấn công ở giữa khiến bạn nghĩ rằng bạn đang truy cập trang web của mình nhưng trình bày một trang thực sự từ một trang khác và có thể cố gắng lấy thông tin từ bạn. Vì dữ liệu được mã hóa, nó cũng khiến kẻ tấn công thao túng trang khó khăn hơn khi bạn nhìn thấy.

Bởi vì bạn cần chứng chỉ SSL, điều đó xác minh bạn là chủ sở hữu của trang web ở mức tối thiểu đưa ra ít nhất một số xác minh bạn là ai.


3

Các công ty tiếp thị như Hitwise trả tiền cho ISP để thu thập dữ liệu về trang web của bạn khi bạn không sử dụng SSL. Dữ liệu về trang web của bạn được thu thập mà bạn có thể không biết đối thủ của mình biết:

  • nhân khẩu học của người dùng
  • thống kê khách truy cập
  • trang phổ biến
  • từ khóa công cụ tìm kiếm (mặc dù với "không được cung cấp", điều này ít xảy ra trong những ngày này)

3

Và, chỉ cần thêm một điều nữa vào tất cả các câu trả lời, tôi sẽ chỉ nói về độ trễ. Bởi vì, dường như không ai viết ở đây về điều này.

Có độ trễ HTTP từ máy khách đến máy chủ thấp là rất quan trọng để tạo các trang web phản hồi nhanh, tải nhanh.

Chỉ riêng TCP / IP đã bắt tay 3 chiều (thiết lập kết nối ban đầu cho HTTP đơn giản qua TCP yêu cầu 3 gói). Khi SSL / TLS được sử dụng, thiết lập kết nối có liên quan nhiều hơn, có nghĩa là độ trễ cho các kết nối HTTPS mới không thể tránh khỏi cao hơn HTTP bản rõ.

Vấn đề với HTTP là nó không an toàn. Vì vậy, nếu bạn có dữ liệu nhạy cảm, bạn cần một số hình thức bảo mật. Khi bạn nhập một cái gì đó vào trình duyệt web của bạn bắt đầu bằng, https https, bạn đang yêu cầu trình duyệt của mình sử dụng lớp mã hóa để bảo vệ lưu lượng. Điều này cung cấp sự bảo vệ hợp lý chống lại kẻ nghe trộm, nhưng vấn đề là nó sẽ chậm hơn. Vì chúng tôi muốn mã hóa lưu lượng truy cập của mình, sẽ có một số tính toán liên quan, làm tăng thêm thời gian. Điều này có nghĩa là nếu bạn không thiết kế hệ thống của mình một cách chính xác, trang web của bạn sẽ xuất hiện chậm chạp đối với người dùng.

Để kết luận:

Tôi có một trang web chỉ có nội dung lớn; không đăng nhập hoặc đăng xuất, không có tên người dùng, không địa chỉ email, không có khu vực an toàn, không có gì bí mật trên trang web, nada. Mọi người chỉ cần đến trang web và đi từ trang này sang trang khác và xem nội dung.

Nếu đây là trường hợp, tôi sẽ không sử dụng SSL. Tôi muốn có trang của tôi khi bạn nhấp vào nó mà nó sẽ mở trong một giây. Đó là từ trải nghiệm người dùng. Bạn làm như bạn muốn, tôi chỉ không đặt chứng chỉ cho mọi thứ tôi làm. Trong trường hợp cụ thể này, tôi sẽ không sử dụng nó.


IMO, đây chỉ là một câu trả lời đúng như người nhận được tất cả các phiếu bầu.
Michael Yaeger

youtube.com/watch?v=e6DUrH56g14 đề cập đến một số kỹ thuật để giảm thiểu tác động hiệu suất ngay cả khi bạn (hoặc một phần lớn khách hàng của bạn) không thể thực hiện HTTP / 2 vì một số lý do.
một CVn

1

Bên cạnh những lợi ích được đề cập bởi những người khác, có một lý do sẽ khiến bạn chuyển sang SSL trừ khi bạn không quan tâm đến khách truy cập sử dụng Chrome - phiên bản mới của Chrome (bắt đầu từ cuối năm theo như tôi nhớ) sẽ hiển thị cảnh báo (sẽ loại bỏ người dùng khỏi trang web của bạn) theo mặc định cho tất cả các trang web không sử dụng HTTPS.

//BIÊN TẬP:

Dưới đây là các liên kết đến hai bài viết chi tiết hơn, mặc dù tôi dường như không thể tìm thấy bài viết mà tôi đã đọc khi họ dự định giới thiệu chính thức tính năng này:

https://othersboard.vice.com/read/google-will-ton-shame-all-websites-that-are-unencrypted-chrom-https

http://www.pandasecurity.com/mediacenter/security/websites-that-arent-USE-https/


Đây không phải là một trích dẫn hoàn hảo cho khiếu nại được đưa ra trong câu trả lời, nhưng luôn có Đánh dấu HTTP là Không bảo mật .
một CVn

1

Câu trả lời đơn giản là không có lý do chính đáng để không . Trước đây, có những tranh luận về việc chỉ sử dụng SSL khi thực sự cần thiết (ví dụ: trên các trang web thương mại điện tử thu thập chi tiết thanh toán).

Những điều này phần lớn liên quan đến quy trình cài đặt chứng chỉ SSL, chi phí, tải bổ sung trên máy chủ web và giới hạn mạng - tại thời điểm mọi người không có băng thông rộng, v.v. Không có lý do nào thực sự áp dụng trong năm 2016.

Về mặt SEO, chúng tôi biết rằng mục tiêu của hầu hết các công cụ tìm kiếm là cung cấp kết quả tốt nhất cho người dùng của họ và điều này có thể được thực hiện bằng cách cung cấp cho họ kết nối an toàn đến trang web họ đang duyệt. Về mặt này, các công cụ tìm kiếm không quan tâm liệu có dữ liệu "nhạy cảm" trên trang web (được trình bày hoặc thu thập); đơn giản là nếu trang web được phục vụ qua HTTPS, mọi rủi ro tiềm ẩn về xác thực và mã hóa sẽ được giảm thiểu đáng kể, vì vậy trang web sẽ được coi là "tốt hơn" so với trang web tương đương không có HTTPS.

Về cơ bản, nó rất đơn giản và dễ thực hiện, nó chỉ được coi là thực tiễn tốt nhất hiện nay. Là một nhà phát triển web, tôi chỉ xem xét việc cài đặt chứng chỉ SSL và sau đó buộc tất cả các yêu cầu qua HTTPS (rất dễ sử dụng .htaccess hoặc tương đương) là một phần tiêu chuẩn của bất kỳ trang web hoặc ứng dụng web nào tôi xây dựng.


1

Ngoài các câu trả lời khác, các trình duyệt nên (như trong RFC 2119) gửi User-Agenttiêu đề. Nó cung cấp đủ thông tin về nền tảng mà người dùng đang sử dụng nếu anh ta gửi thực tế User-Agent. Nếu Eve có thể nghe lén yêu cầu của Alice và Alice gửi thực tế User-Agent, thì Eve sẽ biết Alice sử dụng nền tảng nào mà không cần Alice thực hiện kết nối với máy chủ của Eve. Sẽ dễ dàng hơn để hack vào máy tính của Alice với kiến ​​thức như vậy.


Điều này giống như nói rằng nếu Eve có thể nhìn thấy số VIN của xe Alice thông qua kính chắn gió của xe hơi, thì Eve sẽ dễ dàng đột nhập vào xe của Alice hơn vì số VIN cho phép cô tìm ra thương hiệu và mẫu xe mà Alice sở hữu. Chắc chắn, đó là một khả năng, nhưng có rất nhiều cách để có được nhiều thông tin giống nhau mà không cần MITM'ing, theo những cách mà hầu như không đăng ký như bất kỳ thứ gì ngoài tiếng ồn nền Internet cho một nút lá trên mạng. Ví dụ: Eve (hoặc có lẽ Mallory) có thể gửi email cho Alice một liên kết đến một trang web dưới sự kiểm soát của họ. Mọi người thích nhấp vào liên kết.
một CVn

1

Bạn có hai tùy chọn để bảo mật tên miền chính của mình (mysite.com) và tên miền phụ của nó (play.mysite.com và test.mysite.com). SSL không chỉ dành cho thương mại điện tử, các trang web thanh toán nơi giao dịch tài chính hoặc thông tin đăng nhập được chia sẻ trên trang web. Nó cũng quan trọng như nhau đối với trang web dựa trên nội dung. Những kẻ tấn công luôn tìm kiếm trang web HTTP đơn giản hoặc kẽ hở trong trang web. SSL không chỉ cung cấp bảo mật mà còn xác thực trang web của bạn. Lợi ích chính của việc có SSL trên trang web dựa trên nội dung là

  • Bạn có thể tránh được cuộc tấn công trung gian có thể làm thay đổi nội dung của trang web.

  • Ngoài ra, trang web của bạn sẽ có tính xác thực thông báo cho khách truy cập rằng thông tin của họ sẽ được bảo mật nếu họ chia sẻ với trang web.

  • Họ được đảm bảo về tính xác thực của trang web.

  • Hơn nữa, trang web của bạn sẽ không bị tiêm quảng cáo độc hại, khai thác, các vật dụng không mong muốn, thay thế phần mềm và gây hại cho các trang web khi bạn có SSL trên trang web của mình.

  • Chứng chỉ SSL cung cấp con dấu trang tĩnh có thể được đặt trên bất kỳ trang web nào để đảm bảo và khách hàng có thể nhấp vào con dấu để biết chi tiết về chứng chỉ SSL đã cài đặt.


1

Các câu trả lời khác nói về lợi ích của HTTPS. Người dùng có bị buộc phải sử dụng HTTPS không? Vì hai lý do:

  • Nếu bạn cung cấp cho người dùng tùy chọn không sử dụng HTTPS, họ có thể sẽ không, đặc biệt là vì hầu hết các trình duyệt mặc định là http: // và không https: // khi nhập tên miền vào thanh địa chỉ.
  • Bằng cách triển khai cả phiên bản bảo mật và phiên bản không an toàn, bạn tăng bề mặt tấn công của kết nối. Bạn cho kẻ tấn công cơ hội thực hiện một cuộc tấn công hạ cấp ngay cả khi bạn nghĩ rằng bạn đang sử dụng phiên bản bảo mật.
  • Nếu bạn chuyển hướng mọi http: // URL tới https: // một, điều đó giúp quản trị viên của máy chủ và công cụ tìm kiếm dễ dàng hơn. Không ai phải lo lắng về việc http: // và https: // có nghĩa là tương đương hay có nghĩa là chỉ ra những thứ hoàn toàn khác nhau, bằng cách chuyển hướng cái này sang cái khác cho mọi người biết URL nào được sử dụng.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.