it-swarm-vi.com

Việc truy cập các trang web HTTPS trên một điểm truy cập công cộng có an toàn không?

Người ta thường nói rằng các kết nối SSL/TLS của HTTPS được mã hóa và được bảo mật vì thông tin liên lạc giữa máy chủ và tôi được mã hóa (cũng cung cấp xác thực máy chủ), vì vậy nếu ai đó đánh hơi các gói của tôi, họ sẽ cần hàng trăm năm để giải mã nếu sử dụng brute lực trong lý thuyết.

Giả sử tôi đang sử dụng wifi công cộng và có một người dùng độc hại trên cùng một wifi, người đánh hơi mọi gói tin. Bây giờ, giả sử tôi đang cố gắng truy cập tài khoản gmail của mình bằng wifi này. Trình duyệt của tôi thực hiện bắt tay SSL/TLS với máy chủ và nhận các khóa để sử dụng để mã hóa và giải mã.

Nếu người dùng độc hại đó đánh hơi tất cả các gói đến và đi của tôi. Anh ta có thể tính toán các khóa tương tự và đọc lưu lượng được mã hóa của tôi không hoặc thậm chí gửi tin nhắn được mã hóa đến máy chủ dưới tên của tôi?

148
Calmarius

HTTPS an toàn trên các điểm nóng công cộng. Chỉ một khóa công khai và tin nhắn được mã hóa được truyền (và chúng cũng được ký bởi chứng chỉ gốc) trong quá trình thiết lập TLS , lớp bảo mật được HTTPS sử dụng. Máy khách sử dụng khóa chung để mã hóa một bí mật chính, sau đó máy chủ sẽ giải mã bằng khóa riêng của nó. Tất cả dữ liệu được mã hóa với chức năng sử dụng số bí mật chính và số giả ngẫu nhiên được tạo bởi mỗi bên.

Như vậy

  • dữ liệu được bảo mật bởi vì nó được ký bởi bí mật chính và các số giả ngẫu nhiên
  • bí mật chính và số giả ngẫu nhiên được bảo mật vì nó sử dụng mã hóa khóa riêng-công khai khi bắt tay TLS xảy ra
  • mã hóa khóa công khai là an toàn vì: [.__.]
    • các khóa riêng được giữ bí mật
    • mã hóa khóa công khai được thiết kế để trở nên vô dụng nếu không có khóa riêng
    • các khóa công khai được biết là hợp pháp vì chúng được ký bởi các chứng chỉ gốc, một trong hai
    • đi kèm với máy tính của bạn
    • hoặc được bạn ủy quyền cụ thể (chú ý đến các cảnh báo của trình duyệt!)

Do đó, các kết nối và dữ liệu HTTPS của bạn được an toàn miễn là:

  1. bạn tin tưởng các chứng chỉ đi kèm với máy tính của bạn,
  2. bạn cẩn thận chỉ ủy quyền các chứng chỉ mà bạn tin tưởng.
109
waiwai933

Câu trả lời ngắn gọn: nó phụ thuộc.

Bản thân SSL/TLS không dễ bị tổn thương hơn kết nối wifi công cộng, so với internet "thông thường". Nó được thiết kế để được sử dụng trong các kênh mở.

Tuy nhiên, có một vài khía cạnh khác để xem xét:

  • Thông thường người dùng không duyệt trực tiếp đến trang web HTTPS, họ bắt đầu tại trang HTTP và chuyển hướng từ đó. Ví dụ: bạn duyệt đến http://example.org/ và nhấp vào liên kết Email, điều này chuyển hướng bạn đến https://mail.example.org/. Vì trang HTTP gốc không được mã hóa, người dùng độc hại đó có thể sửa đổi lưu lượng truy cập của bạn, khiến liên kết Email KHÔNG chuyển hướng đến HTTPS, nhưng có thể ở một nơi khác. Ví dụ: nếu bạn đã nhấp vào liên kết Email trên trang chủ của example.org, bạn có nhận thấy rằng nó đã đưa bạn đến http://mail.exxxample.org/? (làm ví dụ). Bạn có thể, người khác có thể không.
  • Nếu người dùng chiếm quyền điều khiển kết nối của bạn, nhưng cung cấp chứng chỉ SSL giả của chính anh ta thay vì example.org - trình duyệt của bạn will hiển thị lỗi, chứng chỉ đó không hợp lệ. Tuy nhiên, hầu hết người dùng sẽ chỉ cần nhấp qua điều này, cho phép kẻ tấn công MITM đến trang web bảo mật của bạn, qua SSL.
  • Một khía cạnh khác cần xem xét, đừng cho rằng điểm nóng công cộng được cấu hình an toàn. Vì câu hỏi này cho thấy , các bộ định tuyến đã quá phổ biến và có thể gây ra nhiều thiệt hại không liên quan đến SSL của bạn.
48
AviD

Một phiên hoàn toàn trên HTTPS khá an toàn, vì tất cả các yêu cầu từ trình duyệt và các trang được truyền bởi máy chủ đều được mã hóa.

Tuy nhiên, khi được truy cập qua HTTPS, nhiều trang web sẽ chỉ thực hiện bước xác thực qua HTTPS và sau đó quay lại HTTP trong phần còn lại của phiên. Vì vậy, mật khẩu của bạn là an toàn, nhưng ID phiên được máy chủ sử dụng để nhận dạng bạn cho phiên đó được trình duyệt của bạn truyền đi rõ ràng. Điều này giúp giảm tải cho máy chủ web (vì mã hóa/giải mã tốn nhiều CPU) nhưng làm cho trang web kém an toàn hơn nhiều. Gmail an toàn vì nó sử dụng HTTPS cho cả phiên, nhưng Facebook và nhiều trang khác thì không.

Đây là cách các công cụ như Firesheep có thể chiếm quyền điều khiển tài khoản của người dùng khi kẻ tấn công đang chia sẻ mạng không dây không được mã hóa.

Bạn có thể tự bảo vệ mình khỏi cuộc tấn công này bằng cách sử dụng VPN để mã hóa tất cả dữ liệu phiên hoặc chỉ bằng cách sử dụng các mạng có mã hóa mạnh cho mỗi người dùng như WPA-PSK (WEP sử dụng cùng một khóa cho mọi người dùng, và vì vậy không cung cấp bảo vệ khỏi cuộc tấn công này).

22
Alex Howell

Vì các câu trả lời dường như ở khắp mọi nơi (có, không, có thể, nên như vậy), trước tiên tôi xin nhắc lại câu trả lời của @ waiwai933: nó an toàn.

Để cụ thể, bạn đã hỏi: "Nếu người dùng độc hại đó đánh hơi tất cả các gói đến và đi của tôi. Anh ta có thể tính các khóa giống nhau và đọc lưu lượng được mã hóa của tôi không hoặc thậm chí gửi tin nhắn được mã hóa đến máy chủ của tôi?" Câu trả lời là không và không. Với một chú thích.

Lý do anh ta không thể tính toán các khóa tương tự có vẻ nghịch lý, và trên thực tế là một bước đột phá lớn trong mật mã khi nó được xuất bản lần đầu bởi Diffie và Hellman. TLS sử dụng giao thức trao đổi khóa, giống như Diffie-Hellman nhưng tinh vi hơn để bảo vệ khỏi các cuộc tấn công trung gian. Giao thức cho phép hai người chưa bao giờ trao đổi thông tin trước khi tính toán một khóa bí mật mà không ai nhìn thấy tất cả các tin nhắn có thể tính toán.

Khi bạn có khóa bí mật chung, bạn có thể sử dụng nó để mã hóa lưu lượng truy cập của mình. Vì người dùng độc hại không biết khóa, anh ta không thể mã hóa lưu lượng trông giống như nó đến từ bạn.

Bây giờ những chú thích.

  • Chúng tôi giả định rằng giao thức SSL/TLS là chính xác. Với hầu hết các giao thức mã hóa liên quan, các lỗi được tìm thấy và sửa chữa theo thời gian. SSL/TLS đã có một lỗi gần đây (được đề cập trong một vài câu trả lời vì lý do không an toàn), tuy nhiên nó đã được xử lý tạm thời và hiện tại đã sửa (RFC 5746) và cách khắc phục các giai đoạn triển khai khác nhau. (Trong trường hợp của bạn, lỗi cho phép người dùng độc hại gửi các gói trong tên của bạn nhưng không đọc được lưu lượng truy cập của bạn.) Kẻ tấn công luôn biết cách phá vỡ TLS/SSL do lỗi không được công bố trong giao thức.
  • Một điểm rõ ràng nhưng đáng để nhắc lại: Người dùng độc hại có thể thấy yêu cầu của bạn và gửi phản hồi của chính anh ta bằng chứng chỉ của chính anh ta. Vì vậy, kiểm tra giấy chứng nhận.
  • Có lẽ một điểm rõ ràng khác: bạn chỉ có thể chắc chắn SSL/TLS sẽ được sử dụng cho các trang trong tương lai nếu trang hiện tại là HTTPS. Ví dụ: nếu bạn đang ở trang HTTP muốn đăng nhập và từ kinh nghiệm trong quá khứ, bạn biết rằng nhấp vào nút đăng nhập sẽ chuyển hướng bạn đến kết nối HTTPS, chức năng này có thể bị xóa bởi người dùng độc hại đang hoạt động trên mạng của bạn. Vì vậy, chỉ đăng nhập vào các trang đã là HTTPS (trừ khi bạn biết cách phát hiện nếu trang đăng nhập đã được sửa đổi).
13
PulpSpy

Nếu bạn lo lắng về việc duyệt web an toàn đến một số trang web qua mạng không an toàn, các bước tốt nhất bạn có thể thực hiện để đảm bảo an ninh là:

  • Đảm bảo rằng trang web sử dụng HTTPS, không phải HTTP.

  • Hãy chắc chắn rằng trang web có chứng chỉ hợp lệ. Đừng nhấp qua các cảnh báo. Không chấp nhận chứng chỉ không hợp lệ.

  • Sử dụng HTTPS ở mọi nơi hoặc Force-TLS để đảm bảo rằng bạn đang sử dụng kết nối HTTPS (tức là được mã hóa SSL) cho mọi thứ liên quan đến trang web đó.

2
D.W.

HTTPS có khả năng chống giải mã khá cao từ việc đánh hơi gói tin. Tuy nhiên, phía xác thực máy chủ phụ thuộc vào một phương pháp phân phối CA certs hơi yếu và CA không làm được gì nhiều trong việc xác minh danh tính. Vài năm trước, một chứng chỉ của Microsoft là được cấp cho một kẻ mạo danh . Xem Bruce Schneier's bài viết về chủ đề này - trong thực tế, đối với các trang web công cộng nói chung, chúng tôi không có gì tốt hơn.

2
RedGrittyBrick

Trong thực tế, cả SSL và TLS đều có vấn đề, nhưng chúng xoay quanh kiểu tấn công Man In the Middle. Để biết ví dụ về vấn đề đàm phán lại TLS MITM, hãy xem tại đây

Tất nhiên, cuộc tấn công này đòi hỏi kẻ tấn công phải ở giữa đường liên lạc, điều này hạn chế mối đe dọa một chút :-)

2
Rory Alsop

Hoàn toàn, trong thực tế. Việc mã hóa bắt đầu với những người ssl gốc (Verisign, Thawte, v.v.) và do đó, nó phù hợp với các dòng không an toàn. AFAIK TLS không có vấn đề gì với người đàn ông trong các cuộc tấn công ở giữa, những cái bắt tay yếu hơn/cũ hơn chỉ có vấn đề đó.

1
tobylane

Hầu hết đều quên khía cạnh người dùng và cách họ có thể sử dụng máy tính đó tại hotspot. Hầu hết mọi người sử dụng mật khẩu tương tự trên các trang web khác, có thể blog, ... vv. những thứ đó có thể không an toàn như gmail HTTPS/SSL mà bạn có thể đang kết nối. Vấn đề tôi thấy từ bảo mật, hầu hết mọi người sẽ xem các trang web khác hiển thị chương trình đánh hơi gói tin có đủ thông tin để nhận tại một số tài khoản của bạn. Tốt nhất là như đã đề cập nếu bạn đang sử dụng kết nối không dây không được mã hóa, hy vọng bạn có một vpn mà bạn có thể kết nối sau đó sẽ thêm lớp bảo mật bổ sung.

1
IrqJD

Kết nối khá an toàn khi có liên quan đến kết nối an toàn (ssl). Được cung cấp, nếu nó được sử dụng với nhận thức:

  • Không nên chuyển hướng từ HTTPS sang HTTP
  • Một số trang web cũng sử dụng HTTP cmd trên các trang HTTPS, không nên có bất kỳ thông tin nhạy cảm nào được truyền qua đó
  • Các máy chủ https được định cấu hình yếu và các trình duyệt lỗi thời vẫn có thể khai thác được ngay cả trên các ổ cắm an toàn
0
8zero2.ops