it-swarm-vi.com

Kết nối HTTPS có được thiết lập có nghĩa là một đường dây thực sự an toàn không?

Từ quan điểm của ai đó cung cấp ứng dụng web, khi ai đó kết nối với TLS (https) với dịch vụ của chúng tôi và gửi dữ liệu xác thực chính xác, có an toàn để truyền tất cả dữ liệu nhạy cảm qua dòng này không, hoặc có thể vẫn còn nghe lén không?

Câu hỏi này là Câu hỏi bảo mật CNTT trong tuần.
[.__.] Đọc ngày 29 tháng 7 năm 2011 mục blog để biết thêm chi tiết hoặc gửi câu hỏi của riêng bạn Câu hỏi trong tuần.

112
Peter Smit

Điều quan trọng là phải hiểu những gì SSL làm và không làm, đặc biệt vì đây là một nguồn hiểu lầm rất phổ biến.

  • Nó mã hóa kênh
  • Nó áp dụng kiểm tra tính toàn vẹn
  • Nó cung cấp xác thực

Vì vậy, câu trả lời nhanh nên là: "có, nó đủ an toàn để truyền dữ liệu nhạy cảm". Tuy nhiên, mọi thứ không đơn giản.

  • Các phiên bản mới nhất của SSL - phiên bản 3 hoặc tốt hơn nữa: TLS, thậm chí TLS 1.2, chắc chắn tốt hơn các phiên bản trước. Ví dụ. SSL 2 tương đối dễ dàng với MITM (Người đàn ông ở giữa). Vì vậy, đầu tiên nó phụ thuộc vào phiên bản giao thức.
  • Cả mã hóa kênh và kiểm tra tính toàn vẹn đều có thể định cấu hình trong giao thức, tức là bạn có thể chọn sử dụng thuật toán nào (bộ mật mã). Rõ ràng, nếu bạn đang sử dụng RSA1024/SHA512 thì tốt hơn nhiều ... Tuy nhiên, SSL thậm chí còn hỗ trợ chế độ mã hóa NULL - tức là không mã hóa gì cả, chỉ gói các yêu cầu lên đường hầm qua giao thức SSL. Tức là, không bảo vệ. (Đây là cấu hình cả ở máy khách và máy chủ, bộ mật mã được chọn là bộ khớp đầu tiên theo thứ tự được cấu hình).
  • Xác thực trong SSL có hai chế độ: chỉ xác thực máy chủ và xác thực lẫn nhau (chứng chỉ ứng dụng khách). Trong cả hai trường hợp, bảo mật được đảm bảo bởi các chứng chỉ mật mã chắc chắn đủ mạnh, tuy nhiên tính hợp lệ của xác thực thực tế chỉ tốt như kiểm tra tính hợp lệ của bạn: Bạn còn bận tâm kiểm tra chứng chỉ không? Bạn có đảm bảo tính hợp lệ của nó? Chuỗi tin cậy? Ai đã ban hành nó? Vân vân.
  • Xác thực lại điểm cuối cùng này dễ dàng hơn rất nhiều trong web ứng dụng, trong đó máy khách có thể dễ dàng xem chứng chỉ máy chủ, biểu tượng khóa có thể dễ dàng xem được, v.v. Với Web Dịch vụ, bạn thường cần phải rõ ràng hơn trong việc kiểm tra tính hợp lệ của nó (tùy thuộc vào sự lựa chọn của bạn về nền tảng). Lưu ý rằng điểm này đã tăng gấp ba ứng dụng di động - ngay cả khi nhà phát triển ứng dụng nhớ chỉ sử dụng TLS giữa điện thoại và máy chủ, nếu ứng dụng không xác minh rõ ràng chứng chỉ thì TLS bị hỏng.
  • Mặc dù có một số cuộc tấn công chủ yếu về mặt lý thuyết vào mật mã của SSL, từ PoV của tôi, nó vẫn đủ mạnh cho hầu hết tất cả các mục đích và sẽ tồn tại trong một thời gian dài.
  • Điều gì thực sự được thực hiện với dữ liệu ở đầu kia? Ví dụ. nếu siêu nhạy cảm, hoặc thậm chí dữ liệu thẻ tín dụng, bạn không muốn điều đó trong bộ nhớ cache hoặc lịch sử của trình duyệt, v.v.
  • Cookies (và do đó xác thực) có thể được chia sẻ giữa kênh SSL an toàn và kênh HTTP không an toàn - trừ khi được đánh dấu rõ ràng bằng thuộc tính "bảo mật".

Vì vậy, câu trả lời ngắn hơn? Có, SSL có thể đủ an toàn, nhưng (như với hầu hết mọi thứ), nó phụ thuộc vào cách bạn sử dụng nó. :)

94
AviD

Có một vài vấn đề ở đây, vấn đề chính là xác thực. Cả hai kết thúc cần chắc chắn rằng họ đang nói chuyện với đúng người hoặc tổ chức để ngăn chặn các cuộc tấn công trung gian. Cuối cùng, điều quan trọng là bạn phải sử dụng chứng chỉ SSL được trình duyệt của người dùng tin cậy. Bằng cách đó, trình duyệt của người dùng có thể chắc chắn rằng nó thực sự đang nói chuyện với đúng trang web. Khi kết nối được thiết lập, bạn có thể chắc chắn nói chuyện với người dùng đó mọi lúc và kết nối được mã hóa, tức là an toàn trước việc nghe lén.

Xác thực theo hướng khác (nghĩa là đảm bảo rằng bạn đang nói chuyện với người dùng thực) thường được xử lý bên ngoài giao thức SSL ở cấp ứng dụng bằng, ví dụ: tên người dùng/mật khẩu, openID hoặc một số dạng thông tin xác thực khác.

Lưu ý cuối cùng là nên đề cập rằng trong quá trình bắt tay SSL, máy khách và máy chủ bắt tay đồng ý với Bộ mật mã và máy khách có thể giả vờ chỉ thực hiện "mã hóa null", nghĩa là không mã hóa bất kỳ dữ liệu nào . Nếu máy chủ của bạn đồng ý với tùy chọn đó, kết nối sẽ sử dụng SSL, nhưng dữ liệu vẫn không được mã hóa. Đây không phải là một vấn đề trong thực tế vì việc triển khai máy chủ thường không cung cấp mật mã null dưới dạng tùy chọn.

23
Tronic

Ngoài những gì AviD liệt kê ra, SSL chỉ an toàn như cơ sở hạ tầng DNS hướng bạn đến máy chủ đó và bất kỳ proxy công ty nào trong đường dẫn liên lạc.

Nếu cơ sở hạ tầng DNS bị hack (nhiễm độc bộ đệm, v.v.) thì kẻ tấn công có thể khiến người dùng của bạn phải chịu nhiều cuộc tấn công.

Ngoài ra, nếu khách hàng đang trải qua phần mềm như Fiddler hoặc proxy công ty, phần mềm đó có thể giảm bớt cuộc hội thoại SSL của bạn.

Để giảm thiểu điều này, hãy xem "nhà phát hành" chứng chỉ SSL. Nếu kết nối SSL đi qua proxy, thì nhà phát hành sẽ là proxy. Nếu bạn đang kết nối trực tiếp, thì bạn sẽ thấy CA đáng tin cậy công khai có liên quan.

[Thêm thông tin]

Proxy HTTPS của công ty là thứ quản lý kết nối giữa trình duyệt web và Proxy (có địa chỉ IP xuất hiện trong nhật ký máy chủ web của bạn). Trong trường hợp đó, nội dung web (mật khẩu HTTPS cũng vậy) được giải mã và sau đó được mã hóa lại tại proxy công ty và được trình bày cho máy chủ của bạn.

Tùy thuộc vào người đang quản lý proxy và cách sử dụng nhật ký của nó, điều này có thể được chấp nhận hoặc điều xấu từ quan điểm của bạn.

Để biết thêm thông tin về cách thực hiện đánh chặn SSL, hãy xem liên kết :

Khi Proxy SSL chặn kết nối SSL, nó sẽ xuất trình chứng chỉ máy chủ được mô phỏng cho trình duyệt máy khách. Trình duyệt máy khách phát hành một cửa sổ bật lên bảo mật cho người dùng cuối vì trình duyệt không tin tưởng nhà phát hành được ProxySG sử dụng. Cửa sổ bật lên này không xảy ra nếu chứng chỉ nhà phát hành được sử dụng bởi SSL Proxy được nhập dưới dạng gốc đáng tin cậy trong kho chứng chỉ của trình duyệt máy khách.

ProxySG làm cho tất cả các chứng chỉ được cấu hình có sẵn để tải xuống thông qua bảng điều khiển quản lý. Bạn có thể yêu cầu người dùng cuối tải xuống chứng chỉ nhà phát hành thông qua Internet Explorer hoặc Firefox và cài đặt nó làm CA đáng tin cậy trong trình duyệt họ chọn. Điều này giúp loại bỏ cửa sổ bật lên chứng chỉ cho chứng chỉ mô phỏng ...

Một số công ty giải quyết vấn đề bật lên chứng chỉ được đề cập ở trên bằng cách triển khai chứng chỉ gốc (của Proxy) cho mỗi máy trạm thông qua GPO. Mặc dù điều này sẽ chỉ ảnh hưởng đến phần mềm sử dụng kho Chứng chỉ Microsoft. Phần mềm như Firefox và Chrome cần được cập nhật khác nhau.

20
goodguys_activate

Vì SSL phụ thuộc vào Cơ quan cấp chứng chỉ (CA) và về cơ bản, bất kỳ tổ chức nào cũng có thể trở thành CA, các cuộc tấn công trung gian với chứng chỉ giả có chữ ký CA luôn luôn có thể xảy ra. Vì vậy, trong khi SSL vẫn là một cải tiến lớn so với việc không mã hóa chút nào, bảo mật của nó bị đánh giá quá cao do hệ thống CA bị hỏng. Về mặt đó, chứng chỉ tự ký sẽ an toàn như mọi chứng chỉ có chữ ký CA, nhưng các trình duyệt đánh dấu những điều đó là đáng ngờ.

11
Jörn Zaefferer

SSL rất an toàn, mặc dù ai đó có thể đánh cắp cookie phiên của ai đó nếu bạn chạy BẤT K page trang nào trên một dòng không được mã hóa. Nếu bạn có thể tôi sẽ làm cho trang web toàn SSL. Hoặc có thể có cookie chỉ gửi cho các kết nối được mã hóa và có các trang công khai không bảo mật không dành riêng cho người dùng đó.

10
James T

Vẫn có khả năng xảy ra một cuộc tấn công trung gian, trong trường hợp của bạn sẽ là người dùng kết nối với bên thứ ba tự xưng là trang web của bạn và sau đó chuyển tiếp yêu cầu. Tất nhiên, một người dùng thông thái sẽ nhận thấy việc thiếu kết nối SSL hoặc chứng chỉ sai nhưng hầu hết người dùng không được bật và bị lừa bởi favicon ổ khóa.

Đây thực sự không phải là một vấn đề với SSL, chỉ là điều cần chú ý. Bạn có thể cho rằng không ai có thể nghe lén kết nối SSL giữa trang web của bạn và nguồn kết nối. Tuy nhiên, bạn không thể chắc chắn rằng nguồn kết nối thực sự là người dùng.

9
Magnus

Vì SSL bảo vệ quá trình truyền, không có dữ liệu nào có thể bị nghe lén (vì chứng chỉ được tin cậy).

Rõ ràng vấn đề nằm ở nơi bạn (và bao nhiêu) bạn đang sử dụng SSL trong ứng dụng web của mình: ví dụ: bạn chỉ yêu cầu kết nối SSL để xác thực người dùng của bạn (để gửi cho họ cặp mật mã/người dùng đến máy chủ của bạn) , sau đó khi bạn gửi lại cookie, bạn nên biết rằng nó có thể dễ dàng bị chặn (như nếu người dùng của bạn đang sử dụng kết nối không dây không được bảo vệ).

Bộ phim truyền hình FireSheep gần đây là tất cả về điều này.

9
gbr

Không Phân tích lưu lượng truy cập vẫn có thể nói với ai đó rất nhiều.

Phân tích lưu lượng truy cập là quá trình chặn và kiểm tra tin nhắn để suy luận thông tin từ các mẫu trong giao tiếp. Nó có thể được thực hiện ngay cả khi các tin nhắn được mã hóa và không thể được giải mã. Nói chung, số lượng tin nhắn được quan sát, hoặc thậm chí bị chặn và lưu trữ càng nhiều thì càng có thể được suy ra từ lưu lượng truy cập.


TLS thường được triển khai để giữ bí mật - kẻ tấn công không nên đạt được mức độ tin cậy cao về nội dung truyền thông.

Giả định,

  1. kẻ tấn công biết giao thức của bạn,
  2. kẻ tấn công biết ai đang liên lạc với ai
  3. kẻ tấn công không thể giải mã tin nhắn.
  4. bạn không làm lu mờ lưu lượng truy cập thực sự của mình trong rất nhiều lưu lượng vô nghĩa (chaff)

Kẻ tấn công có thể biết khi nào bạn thức và khi nào bạn ngủ bất kể giao thức nào, và có thể có thể nói nhiều hơn tùy thuộc vào bản chất của giao thức bạn đang sử dụng.


Nếu giao thức của bạn rất đơn giản:

  1. Bạn gửi tin nhắn "bắn nukes vào ..." khi bạn muốn bắn nukes
  2. Bạn không gửi tin nhắn khi bạn không muốn bắn bất kỳ hạt nhân nào.

Một kẻ nghe trộm không thể giải mã dữ liệu của bạn có thể xác định bằng sự hiện diện của một tin nhắn mà bạn muốn bắn hạt nhân, mặc dù có thể không phải là của ai.


Nếu giao thức của bạn phức tạp hơn:

  1. Bạn yêu cầu một cuốn sách.
  2. Tôi gửi cho bạn nội dung.

Kẻ tấn công có thể không biết ai đang đọc "Chiến tranh và Hòa bình" so với "Atlas Shrugged" nhưng có thể phân biệt, hoàn toàn dựa trên kích thước tin nhắn, cho dù họ đang đọc một trong số trước so với 55 của Kafka tiểu thuyết trang "Sự biến thái".

7
Mike Samuel

SSL thực hiện hai nhiệm vụ cơ bản: xác thực và mã hóa.

Xác thực được thực hiện bằng phương tiện của cơ quan cấp chứng chỉ (CA). Các trình duyệt đi kèm với một danh sách các chứng chỉ SSL cho các khóa ký của CA. CA ký chứng chỉ mô tả khóa chung của một thực thể. Ví dụ: nếu tôi sở hữu Google.com, tôi sẽ chứng minh điều đó với Verisign và họ sẽ ký chứng chỉ của tôi trong một khoảng thời gian. Các vấn đề nảy sinh với CA ký một chứng nhận mà họ không nên ký. Điều này có thể xảy ra khi ai đó giả vờ sở hữu một tên miền khác, có được chứng chỉ ký tự đại diện quá rộng hoặc chỉ đơn giản XKCD CA ban hành một cái gì đó bất chính (chính phủ, có lẽ?). Chúng tôi đã thấy các trường hợp của tất cả các điều trên xảy ra, nhưng nó khá hiếm.

Nếu một chứng chỉ cho một trang web được ký hợp lệ và không có chứng nhận giả trong chuỗi tin cậy của bạn, thì khi bạn kết nối với một trang web, bạn có thể (với mục đích thảo luận) hãy chắc chắn rằng chứng chỉ phù hợp. Trong trường hợp bình thường, kết nối đó được mã hóa. Điều đó ngăn cản bất cứ ai đọc dữ liệu của bạn.

Chứng chỉ SSL rất phức tạp và một số cuộc tấn công tồn tại đối với việc triển khai SSL. Những gì SSL có thể làm một cách hiệu quả là ngăn tôi xem lưu lượng truy cập của bạn tại Starbucks địa phương khi bạn kiểm tra email của mình trên GMail. Điều không thể làm là ngăn tôi sử dụng một cuộc tấn công MITM nơi tôi chuyển tiếp mọi thứ cho bạn mà không có SSL và khách hàng của bạn không thiết lập để làm phiền bạn về thực tế chưa bao giờ bắt đầu một phiên mã hóa.

6
Jeff Ferland

Không tính các câu trả lời khác nhau của người khác về các vấn đề tiềm năng khác, giả sử bạn đang sử dụng SSL 3.0 và mã hóa mạnh, thì nó sẽ được bảo mật.

Sử dụng các giao thức ssl cũ hơn (2.0) hoặc sử dụng khóa mã hóa yếu có thể mở ra cho bạn các lỗ hổng.

4
Doozer Blake

SSL thường tăng cường bảo mật bằng cách cung cấp:

  1. Xác thực máy chủ (người dùng biết họ đang nói chuyện với trang web 'chính xác')
  2. Tính toàn vẹn dữ liệu (người dùng và máy chủ biết rằng lưu lượng truy cập không bị sửa đổi trên đường)
  3. (tùy chọn, nhưng thông thường) Quyền riêng tư dữ liệu (người dùng và máy chủ biết rằng lưu lượng truy cập không bị chặn trên đường)
  4. (tùy chọn, nhưng hiếm) Xác thực ứng dụng khách, nếu máy khách cũng có chứng chỉ

Về cơ bản chỉ có hai loại chứng chỉ SSL, chứng chỉ máy chủ (luôn có liên quan) và chứng chỉ ứng dụng khách (là tùy chọn).

Đây chỉ là một bản phác thảo, và có rất nhiều if, ands và buts. Trong kịch bản điển hình nhất, SSL dựa trên trình duyệt, lược đồ có thể bị phá vỡ trong nhiều trường hợp mà không phá vỡ mật mã hoặc giao thức, nhưng chỉ cần dựa vào người dùng để thực hiện sai (ví dụ: bỏ qua các cảnh báo của trình duyệt và kết nối bằng mọi cách). Các cuộc tấn công lừa đảo cũng có thể hoạt động bằng cách gửi người dùng đến một trang web được bảo vệ SSL giả, được tạo thành giống với trang thật trong tất cả các khía cạnh trừ URL.

Phải nói rằng SSL và TLS anh em họ của nó vẫn rất hữu ích vì ít nhất chúng cho phép liên lạc an toàn, mặc dù không thể đánh lừa được.

4
frankodwyer

@Vladimir đúng là http://en.wikipedia.org/wiki/Forward_secrecy là mong muốn, nhưng có các chi tiết sai. Máy chủ đã chọn ciphersuite này trong số đó được cung cấp bởi trình duyệt. "được mã hóa bằng RC4_128 với SHA1 để xác thực tin nhắn" sử dụng mã hóa RC4 128 bit và kiểm tra tính toàn vẹn của HMAC-SHA-1. (Tên Ciphersuite trong SSL/TLS cho đến gần đây nói SHA nhưng chúng có nghĩa là SHA-1 và thực tế là HMAC-SHA-1.) "ECDHE_ECDSA là cơ chế trao đổi khóa" không áp dụng cho các tin nhắn cá nhân , đó là một phần (hầu hết) của cái bắt tay xảy ra một lần vào đầu phiên: ECDHE sử dụng biến thể Elliptic Curve của Diffie-Hellman trong chế độ Ephemeral (cộng với một số bước bổ sung không quan trọng ở đây) để tạo phiên khóa được sử dụng để mã hóa và HMAC; và trao đổi khóa ECDHE (chỉ) được ký bởi biến thể Elliptic Curve của Thuật toán Chữ ký số. (Bạn không bao giờ có thể mã hóa bất cứ điều gì trực tiếp bằng DH hoặc ECDH, họ chỉ thực hiện khóa hoặc thỏa thuận bí mật nhỏ khác.)

2
dave_thompson_085

Khi bạn không sử dụng SSL, tất cả các giao tiếp có thể dễ dàng bị chặn - điều duy nhất người ta cần làm là khởi chạy gói sniffer (tức là Wireshark).
[.__.] SSL ngăn chặn điều đó, tất cả các gói được mã hóa nên không có cách nào để biết bạn đang gửi cái gì. Về cơ bản, nó được sử dụng để bảo vệ mật khẩu và nội dung riêng tư khỏi bị chặn. Bạn rõ ràng không muốn người khác đọc email riêng tư của bạn, phải không?
[.__.] Đối với tìm kiếm của Google, họ chỉ đơn giản làm điều đó để che giấu những gì mọi người đang yêu cầu. Điều này là do một số chính phủ quá tò mò về nó.

Làm thế nào SSL tăng bảo mật? Nó không tự nó. Sự kết hợp giữa mã hóa (khóa SSL) và PKI (Cơ sở hạ tầng khóa công khai) - chủ yếu là Chứng chỉ. OK, câu hỏi là làm thế nào. Một mặt, nó bảo vệ kênh liên lạc của bạn (xem bên trên), mặt khác nó đảm bảo rằng bạn đang nói chuyện với doanh nghiệp hợp pháp - xác thực máy chủ. Vì vậy, kênh là an toàn và đáng tin cậy.

Có khá nhiều Chứng chỉ SSL, vì có khá nhiều Dịch vụ PKI . Về cơ bản dịch vụ khác nhau cần loại Chứng chỉ SSL khác nhau. Vì vậy, có Chứng chỉ để ký mã, mã hóa e-mail và ký, những chứng chỉ liên quan đến xác thực máy chủ, v.v.

2
Paweł Dyda

Khi ai đó kết nối với SSL (https) với dịch vụ của chúng tôi và gửi dữ liệu xác thực chính xác, việc truyền tất cả dữ liệu nhạy cảm qua dòng này có an toàn không, hoặc có thể vẫn còn nghe lén không?

Liên kết yếu trong chuỗi này gần như chắc chắn không phải là SSL mà là người dùng, thường có thể bị lừa kết nối với một trang trung gian giả thông qua giả mạo web/giả mạo siêu liên kết hoặc bằng cách xuất trình chứng chỉ không hợp lệ và từ chối cảnh báo trình duyệt và tiến hành kết nối nào.

Tuy nhiên, dù sao thì hệ thống mà bạn mô tả là cách tốt nhất, bạn không thể làm gì khác (ngoài việc giáo dục người dùng của bạn thực hiện nghiêm túc các cảnh báo SSL nếu bạn có thể).

2
frankodwyer

Câu trả lời ngắn gọn là không. Câu trả lời dài hơn: một tập hợp các câu trả lời ở trên cộng với: Nếu chúng tôi giải quyết xác thực, do đó, người trung gian, rằng với kết nối SSL truyền thống, ai đó đang lắng nghe lưu lượng truy cập vẫn có thể giải mã nó sau nếu họ lấy được khóa bí mật của máy chủ (nghĩ của NSA và Thư bảo mật quốc gia). Có một tùy chọn trong giao thức TLS để sử dụng giao thức Diffie-Helman để đảm bảo liên kết một cách bảo mật. Xem hình ảnh sau đây khi tôi truy cập gmail.com bằng Chrome. connection security

Nhìn vào văn bản RC4_128 với SHA1 để xác thực tin nhắn ECDHE_ECDSA. Điều này đọc:

  1. Máy chủ cung cấp kênh SSL RC4_128b với SHA digest
  2. Bên trong đường hầm này, mỗi thông điệp được mã hóa với các đường cong Ecliptic trong đó khóa được lấy bằng hàm Diffie-Helman và được ký bằng mật mã Ecliptic Curves bằng Thuật toán Chữ ký số

Nói cách khác, ngay cả khi ai đó có khóa riêng của máy chủ SSL, các tin nhắn đã được mã hóa bằng các khóa tạm thời bị loại bỏ khỏi bộ nhớ ngay sau khi sử dụng. Chúc may mắn NSA!

2
Vladimir Jirasek

Nó có an toàn cho người dùng, hay nó an toàn cho bạn? Giả sử một cuộc tấn công giữa chừng. Kẻ tấn công quản lý để nắm bắt lưu lượng truy cập của người dùng, giả vờ là bạn với người dùng và giả vờ là người dùng cho bạn. Kiểu tấn công đó thường sẽ thất bại, vì chứng chỉ được cấp cho người dùng sẽ không đúng. Ví dụ, kẻ tấn công cung cấp cho người dùng chứng chỉ tự ký cho trang web của bạn. Tuy nhiên, nếu người dùng hành động ngu ngốc, họ có thể chấp nhận chứng chỉ tự ký đó. Vì vậy, bây giờ kẻ tấn công có thể đọc và sửa đổi tất cả lưu lượng giữa người dùng và bạn, và theo như tôi biết thì không có cách nào để bạn phát hiện ra điều này.

Vì vậy, nếu việc rình mò và sửa đổi lưu lượng làm tổn thương người dùng, đó thực sự là lỗi của họ và vấn đề của chính họ. Và dù sao bạn cũng không thể ngăn chặn hoàn toàn, vì MITM có thể loại bỏ bạn hoàn toàn và chỉ nói chuyện với người dùng giả vờ là bạn. Nhưng nếu việc rình mò và sửa đổi lưu lượng làm tổn thương bạn, thì bạn phải tin tưởng người dùng không được ngu ngốc, hoặc xác thực người dùng tốt hơn (người dùng sẽ cần chứng chỉ và bạn có thể kiểm tra xem MITM có thể không giả mạo).

2
gnasher729

Ngay cả các phiên bản HTTPS hiện đại nhất sử dụng TLS cũng có thể dễ dàng bị chặn bởi MitM (ví dụ: thiết bị Juniper được định cấu hình cho mục đích) nếu khách hàng tin tưởng CA. Trong trường hợp cụ thể, nó không an toàn.

1
user3260912

Tôi nghĩ mọi người ở đây không hiểu câu hỏi:

Nếu bạn có một dòng không an toàn và bạn thực hiện Kết nối SSH/SSL thành công qua dòng này, bây giờ anh ta hỏi liệu có an toàn để đưa ra giả định rằng dòng đó là "an toàn" và dữ liệu không được mã hóa có thể được chuyển qua ALONGSIDE với Kết nối được mã hóa ( ví dụ, trong tầm nhìn rõ ràng, không nằm trong Kết nối SSL/SSH được mã hóa).

Tôi sẽ nói không. Trong trường hợp này, có thể có một kẻ nghe trộm thụ động, đơn giản là bỏ qua dữ liệu được mã hóa và lưu dữ liệu không được mã hóa.

NHƯNG bạn có thể chắc chắn rằng không có kẻ nghe trộm hoạt động (MITM), điều đó có nghĩa là bạn có thể thiết lập một cách an toàn một kết nối SSL/SSH không được xác thực với cùng một nguồn/đích như dòng được xác thực. Điều này cung cấp không có kẻ nghe trộm chọn lọc mà MITM kết nối nhất định, nhưng NHƯNG, kẻ nghe trộm không thể biết bạn có xác thực Kết nối hay không, vì vậy anh ta không thể biết Kết nối nào với MITM để trốn tránh phát hiện. MITMer sẽ, nếu anh ấy MITM, MITM tất cả các kết nối và hy vọng mọi người nhấp qua tất cả các hộp thoại xác thực một cách đơn giản.

Do đó: Nếu bạn kết nối được xác thực với dịch vụ SSL từ giả sử 123.123.123.123 đến 24.24.24.24, bạn cũng có thể kết nối an toàn máy khách SSH từ 123.123.123.123 đến 24.24.24.24 mà không cần xác thực hai dấu vân tay SSH, miễn là bạn có thể tin tưởng mọi thứ phía sau các bộ định tuyến hoặc tường lửa khác NAT.

Nhưng ngay cả khi điều đó có nghĩa là an toàn, thì có IS một rủi ro nhỏ mà kẻ nghe trộm chỉ đơn giản là Kết nối MITM ngẫu nhiên và hy vọng không bị phát hiện, vì vậy bạn đã có Kết nối được xác thực với IP mục tiêu, tại sao không sử dụng Kết nối được xác thực đó để xác minh lẫn nhau dấu vân tay SSH? Thật đơn giản như đăng dấu vân tay SSH chính xác trên trang web được bảo mật SSL!

1
sebastian nielsen