Xác thực qua HTTPS có làm chậm ứng dụng của tôi không?


11

Tôi đang xây dựng một ứng dụng web và dịch vụ web RESTful.

Tôi đã đọc các bài viết khác nhau về cách tốt nhất để xác thực các yêu cầu cho dịch vụ web.

Tùy chọn tốt nhất đối với tôi dường như là sử dụng xác thực cơ bản HTTP. Khá nhiều bài báo tôi đã đọc nói rằng xác thực nên được mã hóa qua SSL hoặc tương đương.

Tôi không hoàn toàn chắc chắn những gì liên quan đến. Điều này có nghĩa là toàn bộ dịch vụ web của tôi sẽ phải ở trên một máy chủ an toàn? Điều này sẽ làm mọi thứ chậm lại?


Một suy nghĩ, khả năng lưu trữ dữ liệu được tải qua https. Tôi không chắc chắn 100% về việc nếu / điều này sẽ tác động như thế nào.

Tôi không chắc chắn tôi làm theo. Bạn đang nói bộ nhớ đệm là không thể?
Gaz_Edge

Có sự tương tác giữa ssl / https và máy chủ web có thể được ngoài ý muốn với REST - cxf.547215.n5.nabble.com/... - Tôi đã không delved quá xa vào REST trong một môi trường an toàn vì vậy đây không phải là một vấn đề cho tôi Nó nhiều hơn từ những suy nghĩ và gợi ý từ những ngày tôi là một quản trị viên apache.

Cảm ơn. Bạn nói rằng bạn đã không sử dụng REST trong một môi trường an toàn. Điều đó có nghĩa là bạn không sử dụng xác thực? Hoặc bạn đang làm nó theo một cách khác để http cơ bản.
Gaz_Edge

Nó không có xác thực, cơ bản hoặc dựa trên ip ... và hoàn toàn trong mạng nội bộ (không có gì phải đối mặt với bên ngoài).

Câu trả lời:


11

Trước hết, hãy cố gắng hiểu cách xác thực SSL (HTTPS) và HTTP.

Các phương thức xác thực HTTP thông thường (Digest, Basic và bất kỳ biểu mẫu + sơ đồ xác thực dựa trên cookie nào bạn có thể triển khai trên HTTP) đều không an toàn bởi vì chúng gửi thông tin xác thực ít nhiều bằng văn bản rõ ràng. Cho dù dữ liệu nằm trong các trường POST hoặc tiêu đề và liệu mã hóa base64 có được áp dụng hay không, không có vấn đề gì về vấn đề này, mật khẩu sẽ hiển thị rõ ràng cho bất kỳ ai có quyền truy cập vào lưu lượng mạng. Điều này có nghĩa là xác thực HTTP trên một kênh không đáng tin cậy là vô ích: tất cả những gì kẻ tấn công đọc được mật khẩu của bạn chỉ là một chút đánh hơi mạng.

SSL thực hiện một kênh liên lạc an toàn trên một kênh không an toàn vốn có. Điều này hoạt động, đại khái, như sau:

  1. Máy chủ gửi chứng chỉ đã ký
  2. Khách hàng xác nhận chứng chỉ dựa vào danh sách các khóa ký kết đã biết; Chữ ký chứng chỉ có thể được xâu chuỗi, để mỗi nút nói "nếu chữ ký ký tên tôi là tốt, thì tôi cũng vậy", nhưng cuối cùng, chuỗi cần giải quyết với một trong số ít các cơ quan đáng tin cậy được cấu hình sẵn trên máy khách.
  3. Khách hàng sử dụng khóa mã hóa công khai của máy chủ để gửi bí mật chung
  4. Máy chủ giải mã bí mật được chia sẻ bằng khóa riêng (vì chỉ máy chủ hợp pháp mới có khóa riêng, các máy chủ khác sẽ không thể giải mã được bí mật được chia sẻ)
  5. Khách hàng gửi dữ liệu yêu cầu thực tế, được mã hóa bằng bí mật được chia sẻ
  6. Máy chủ giải mã dữ liệu yêu cầu, sau đó gửi phản hồi được mã hóa
  7. Khách hàng giải mã phản hồi và trình bày nó cho người dùng.

Lưu ý một vài điểm quan trọng ở đây:

  • Chuỗi chứng chỉ cho phép khách hàng đảm bảo rằng máy chủ mà họ đang nói chuyện là máy chủ thực sự chứ không phải ai đó chặn yêu cầu của họ. Đây là lý do tại sao bạn nên mua chứng chỉ SSL thực và tại sao trình duyệt đưa ra những cảnh báo đáng sợ cho bạn khi bạn truy cập trang web sử dụng chứng chỉ không hợp lệ, hết hạn hoặc không chính xác: tất cả mã hóa trên thế giới không giúp ích gì nếu bạn nói chuyện với người sai.
  • Mã hóa công khai / riêng được sử dụng để trao đổi bí mật đảm bảo rằng giao tiếp thành công sẽ chỉ hoạt động giữa cặp máy khách và máy chủ cụ thể này: các gói mạng được đánh hơi sẽ được mã hóa và chúng sẽ yêu cầu khóa riêng của máy chủ để lấy dữ liệu.
  • Mã hóa đối xứng được sử dụng cho phần lớn yêu cầu, bởi vì nó có chi phí hoạt động thấp hơn nhiều so với mã hóa khóa riêng / công khai. Khóa (bí mật chung) được trao đổi bằng cách sử dụng mã hóa khóa riêng / công khai, bởi vì đó là cách duy nhất để làm điều đó một cách an toàn (ngoại trừ vận chuyển nó qua một kênh riêng, chẳng hạn như dịch vụ chuyển phát nhanh).

Vì vậy, rõ ràng, có một số chi phí liên quan, nhưng nó không tệ như bạn nghĩ - chủ yếu ở quy mô mà "ném thêm phần cứng vào nó" là phản ứng thích hợp, trừ khi bạn đang chuẩn bị cho lưu lượng truy cập cực lớn ( nghĩ rằng Google hoặc Facebook). Trong các trường hợp thông thường, nghĩa là, việc sử dụng ứng dụng web thông thường, chi phí SSL là không đáng kể và do đó, ngay khi bạn có bất kỳ dữ liệu bí mật nào, tốt nhất là chỉ chạy mọi thứ qua SSL, bao gồm cả tài nguyên. SSL cũng là cách khả thi duy nhất để đảm bảo lưu lượng HTTP; các phương pháp khác đơn giản là không được chuẩn hóa và do đó không được hỗ trợ rộng rãi và bạn hoàn toàn không muốn tự mình thực hiện những điều này, vì thành thật mà nói, thật quá dễ để hiểu sai.

TL; DR: Có, SSL + Xác thực cơ bản là một ý tưởng hay, vâng, bạn cần một máy chủ an toàn (và chứng chỉ hợp lệ ), vâng, nó sẽ làm mọi thứ chậm lại một chút, nhưng không, đây không phải là điều đáng lo ngại hiện nay.


12

HTTPS (SSL) không phải là xác thực người dùng FYI. Nó chỉ cung cấp mã hóa giữa 2 điểm cuối.

Nhưng vâng, có một chút chi phí nhỏ từ nó (mặc dù không đủ để đảm bảo một sự thay đổi trong kế hoạch / phần cứng). Xem tại đây:

/programming/548029/how-much-overhead-does-ssl-impose


7
+1 tốt hơn để quá an toàn hơn là không đủ an toàn với chi phí nhỏ
Earlz

2
Câu trả lời này rất sai lệch. SSL xác thực, nó thường không phải là xác thực người dùng . SSL xác thực rằng máy chủ mà bạn đang nói chuyện thực sự là người mà nó nói. (Công việc của CA là chỉ cấp chứng chỉ cho facebook.com cho Facebook.) Ngoài ra, SSL có thể xác thực người dùng bằng chứng chỉ ứng dụng khách.
josh3736

@brian: Tôi đồng tình với josh3736. SSL không cung cấp xác thực theo nghĩa mật mã của từ này. Nếu không có (ví dụ: máy chủ) xác thực, bạn sẽ mở cho con người trong các cuộc tấn công ở giữa. SSL có thể cung cấp xác thực ứng dụng khách (người dùng) an toàn bằng thẻ thông minh hoặc nếu nó đã xác thực máy chủ thì các phương tiện khác (ví dụ: tên người dùng / mật khẩu) có thể được sử dụng qua kênh bảo mật.
Guy Sirton

Thực sự, rõ ràng OP đã hỏi về xác thực người dùng và không lo lắng về việc khách hàng xác thực người mà họ đang nói chuyện với / người đàn ông trong các cuộc tấn công giữa. Tôi đã chỉnh sửa bài đăng của mình khi đối mặt với vấn đề nghiêm trọng;) đúng về mặt kỹ thuật là loại chính xác tốt nhất, sau đó
brian

6

Với xác thực cơ bản HTTP, tên người dùng và mật khẩu người dùng cung cấp được gửi với mọi yêu cầu đến máy chủ. Điều này có nghĩa là chúng ở dạng văn bản đơn giản ngay cả trong các khu vực của trang web của bạn không nhất thiết phải được bảo mật. Rõ ràng, bạn sẽ muốn SSL ở đây để giữ an toàn cho người dùng của bạn.

Về lý thuyết, bạn có thể sử dụng xác thực cookie và chỉ đặt SSL trên trang đăng nhập (nơi gửi tên người dùng và mật khẩu). Nếu cookie của bạn an toàn và an toàn trước các cuộc tấn công phát lại, thì kẻ tấn công sẽ không thể làm bất cứ điều gì với chúng ngay cả khi chúng đã xoay sở để có được một cuộc tấn công.


3

Xác thực cơ bản là đặt tên người dùng và mật khẩu trong tiêu đề của yêu cầu http. Nếu bạn không sử dụng SSL hoặc tương đương thì tên người dùng và mật khẩu đó sẽ được gửi bằng văn bản thuần túy và không đáng để ai lấy cắp.

Ngày nay, hầu hết các máy chủ web đều hỗ trợ HTTPS và mặc dù nó bổ sung thêm chi phí cho mọi cuộc gọi nhưng chi phí là tối thiểu.

Bạn có thể bảo mật một số điểm cuối chứ không phải các điểm cuối khác (nghĩa là có điểm cuối xác thực tạo mã thông báo có thể được sử dụng cho các cuộc gọi khác). Tôi thực sự muốn giới thiệu SSL cho toàn bộ dịch vụ mặc dù nó an toàn hơn nhiều. (nếu không có gì khác, nó dừng dữ liệu nhạy cảm bị chặn)


Vâng tôi nghĩ rằng đó có vẻ là ý tưởng tốt nhất. Ứng dụng web của tôi sẽ quản lý phiên người dùng, v.v. vì vậy có thể lưu mã thông báo ở đó. Nhưng ai đó vẫn có thể rình mò mã thông báo cho phiên đó phải không? Vẫn có thể là rủi ro đối với bảo mật dữ liệu
Gaz_Edge

Vâng nói chung. Có những điều bạn có thể làm để bảo mật cookie (tức là mã hóa chúng) nhưng cách đơn giản và hiệu quả hơn là bảo mật toàn bộ trang web. Trừ khi bạn có một trường hợp sử dụng cụ thể, tôi sẽ đề xuất giải pháp đơn giản nhất
Tom Squires

2

Jeff Atwood đã viết một blogpost ngắn gọn cách đây không lâu về việc liệu mã hóa đầy đủ có phải là hướng đi hay không. Ông mô tả một số ví dụ trong thế giới thực và cũng có một vài dòng về cân nhắc hiệu suất.

Ngoài ra, ông tham chiếu này bài viết về một trường hợp nghiên cứu Gmail, trích dẫn như sau:

Vào tháng 1 năm nay (2010), Gmail đã chuyển sang sử dụng HTTPS cho mọi thứ theo mặc định. Trước đây, nó đã được giới thiệu như một tùy chọn, nhưng bây giờ tất cả người dùng của chúng tôi đều sử dụng HTTPS để bảo mật email giữa trình duyệt của họ và Google mọi lúc. Để làm điều này, chúng tôi đã phải triển khai không có máy móc bổ sung và không có phần cứng đặc biệt. Trên các máy frontend sản xuất của chúng tôi, SSL / TLS chiếm ít hơn 1% tải CPU, ít hơn 10KB bộ nhớ cho mỗi kết nối và ít hơn 2% chi phí mạng. Nhiều người tin rằng SSL mất rất nhiều thời gian của CPU và chúng tôi hy vọng những con số trên (lần đầu tiên công khai) sẽ giúp xua tan điều đó.

Ông cũng đề cập đến một số cải tiến gần đây đối với bộ nhớ đệm trang phía máy khách thông qua HTTPS bởi trình duyệt .

Mặc dù vậy, ông chỉ ra rằng, có những hình phạt khác, hầu hết chúng không phải là hiệu suất mà là chi phí thực hiện:

  • Duy trì chất lượng phần mềm trong khi thêm độ phức tạp bổ sung cho các nhóm đã bận rộn,
  • Bộ nhớ cache proxy khó hơn nhiều để cấu hình đúng và cũng cần thay đổi mã,
  • Thật khó để có được bảo mật ngay cho một bản hòa trộn nội dung từ các nguồn khác nhau,
  • Các thiết bị di động cấp thấp có thể phải vật lộn với mã hóa.

Vui lòng mở rộng câu trả lời của bạn và bao gồm một số điểm nổi bật từ blog.
Walter

Điểm nổi bật từ bài viết trên blog được thêm vào.
Daniel Dinnyes

0

Xác thực cơ bản HTTP mà không có xử lý phiên của riêng bạn có thể sẽ khiến bạn mở các cuộc tấn công giả mạo yêu cầu Cross-site. Bạn có thể có thể sử dụng nó nếu bạn kết hợp với xử lý phiên của riêng bạn, nhưng bạn có thể gặp khó khăn khi cung cấp chức năng "đăng xuất" sạch.

Bất kể bạn sử dụng gì để xác thực, bạn sẽ cần sử dụng HTTPS để mã hóa kết nối (trừ khi ứng dụng web chỉ được truy cập trên mạng được bảo mật, được kiểm soát). Nó có thể làm mọi thứ chậm lại một chút (các cơ sở kết nối đắt tiền, nhưng trình duyệt có xu hướng giữ kết nối trong một thời gian), nhưng nếu bạn muốn có một ứng dụng an toàn, bạn sẽ không thể tránh được, vì vậy bạn không thực sự cần lo lắng về nó

Lưu ý: "Xác thực HTTPS" (mà bạn đã đề cập trong tiêu đề) là sai lệch - nó có thể đề cập đến xác thực chứng chỉ ứng dụng khách SSL, điều này ít liên quan đến văn bản câu hỏi của bạn và có các vấn đề và lợi ích riêng. Bạn có thể không muốn chạm vào điều đó.


0

Làm thế nào bạn sẽ thực hiện xác thực cơ bản?
Nếu đó là tên người dùng / mật khẩu được mã hóa cứng và bạn đang sử dụng chức năng tích hợp của máy chủ web để làm điều đó, nó có thể sẽ có tác động gần như bằng không. Nếu bạn đang làm những điều điên rồ trong cơ sở dữ liệu hoặc một cái gì đó tương tự, thì có thể có một tác động.

Giống như những người khác đã lưu ý ở đây, SSL và gửi các tiêu đề bổ sung về mặt kỹ thuật sẽ khiến mọi thứ chậm hơn nhưng nó sẽ không có ý nghĩa theo bất kỳ cách nào.

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.