SSL và hiểu lầm trung gian

Tôi đã đọc rất nhiều tài liệu liên quan đến vấn đề này nhưng tôi vẫn không thể tổng hợp tất cả các phần lại với nhau, vì vậy tôi muốn hỏi một vài câu hỏi.

1. Trước hết, tôi sẽ mô tả ngắn gọn thủ tục xác thực khi tôi hiểu, vì tôi có thể nhầm lẫn về vấn đề đó: Máy khách bắt đầu một kết nối, mà máy chủ phản hồi bằng sự kết hợp của khóa công khai, một số siêu dữ liệu và chữ ký số của một cơ quan đáng tin cậy. Sau đó, khách hàng sẽ đưa ra quyết định nếu cô ấy tin tưởng máy chủ, mã hóa một số khóa phiên ngẫu nhiên bằng khóa công khai và gửi lại. Khóa phiên này chỉ có thể được giải mã với khóa riêng được lưu trữ trên máy chủ. Máy chủ thực hiện điều này và sau đó phiên HTTPS bắt đầu.

2. Vì vậy, nếu tôi đúng ở trên, câu hỏi đặt ra là làm thế nào mà cuộc tấn công kẻ trung gian lại có thể xảy ra trong tình huống như vậy? Ý tôi là, ngay cả khi ai đó chặn phản hồi của máy chủ (ví dụ: www.server.com) bằng khóa công khai và có một số cách để khiến tôi nghĩ rằng anh ta là www.server.com, anh ta vẫn không thể giải mã khóa phiên của tôi không có khóa riêng.

3. Nói về xác thực lẫn nhau, có phải là tất cả về độ tin cậy của máy chủ về danh tính khách hàng không? Ý tôi là, khách hàng đã có thể chắc chắn rằng cô ấy đang giao tiếp với đúng máy chủ, nhưng bây giờ máy chủ muốn tìm xem khách hàng là ai, phải không?

4. Và câu hỏi cuối cùng là về giải pháp thay thế cho xác thực lẫn nhau. Nếu tôi đóng vai trò khách hàng trong tình huống được mô tả, điều gì sẽ xảy ra nếu tôi gửi thông tin đăng nhập / mật khẩu trong tiêu đề HTTP sau khi phiên SSL được thiết lập? Theo tôi thấy, thông tin này không thể bị chặn vì kết nối đã được bảo mật và máy chủ có thể dựa vào đó để nhận dạng của tôi. Liệu tôi có sai? Nhược điểm của cách tiếp cận như vậy so với xác thực lẫn nhau là gì (chỉ các vấn đề bảo mật là quan trọng, không phải sự phức tạp khi thực hiện)?

Các cuộc tấn công man-in-the-middle trên SSL chỉ thực sự có thể xảy ra nếu một trong những điều kiện tiên quyết của SSL bị phá vỡ, đây là một số ví dụ;

• Khóa máy chủ đã bị đánh cắp - có nghĩa là kẻ tấn công có thể là máy chủ và không có cách nào để máy khách biết.

• Máy khách tin tưởng một CA không đáng tin cậy (hoặc một CA đã bị đánh cắp khóa gốc) - bất kỳ ai nắm giữ khóa CA đáng tin cậy đều có thể tạo ra một chứng chỉ giả mạo là máy chủ và máy khách sẽ tin tưởng nó. Với số lượng CA có sẵn trong các trình duyệt ngày nay, đây có thể là một vấn đề thực sự. Điều này có nghĩa là chứng chỉ máy chủ dường như sẽ thay đổi thành một chứng chỉ hợp lệ khác, đây là điều mà hầu hết các máy khách sẽ ẩn với bạn.

• Máy khách không bận tâm đến việc xác thực chứng chỉ một cách chính xác dựa trên danh sách CA đáng tin cậy của nó - bất kỳ ai cũng có thể tạo CA. Nếu không có xác thực, "Xe và Giấy chứng nhận của Ben" sẽ có vẻ hợp lệ như Verisign.

• Máy khách đã bị tấn công và một CA giả đã được đưa vào cơ quan quản lý gốc đáng tin cậy của anh ta - cho phép kẻ tấn công tạo ra bất kỳ chứng chỉ nào mà anh ta thích và khách hàng sẽ tin tưởng nó. Phần mềm độc hại có xu hướng làm điều này để chuyển hướng bạn đến các trang web ngân hàng giả mạo.

Đặc biệt # 2 là khá khó chịu, ngay cả khi bạn trả tiền cho một chứng chỉ có độ tin cậy cao, trang web của bạn sẽ không bị khóa với chứng chỉ đó theo bất kỳ cách nào, bạn phải tin tưởng tất cả CA trong trình duyệt của khách hàng vì bất kỳ CA nào trong số họ đều có thể tạo chứng chỉ giả cho trang web của bạn cũng hợp lệ. Nó cũng không yêu cầu quyền truy cập vào máy chủ hoặc máy khách.

Trước hết, tôi sẽ mô tả ngắn gọn thủ tục xác thực khi tôi hiểu về nó, có thể tôi nhầm ở bước đó. Vì vậy, một máy khách bắt đầu một kết nối và một máy chủ phản hồi nó bằng sự kết hợp của khóa công khai, một số siêu dữ liệu và chữ ký số của một cơ quan đáng tin cậy.

Máy chủ phản hồi bằng chuỗi chứng chỉ X.509 và chữ ký điện tử được ký bằng khóa riêng của chính nó.

Sau đó, khách hàng sẽ đưa ra quyết định nếu cô ấy tin tưởng máy chủ

Chính xác.

mã hóa một số khóa phiên ngẫu nhiên bằng khóa công khai và gửi lại.

Không. Máy khách và máy chủ tham gia vào một quá trình tạo khóa phiên lẫn nhau, theo đó, bản thân khóa phiên không bao giờ được truyền.

Khóa phiên này chỉ có thể được giải mã với khóa riêng được lưu trữ trên máy chủ.

Không.

Máy chủ thực hiện điều này

Không.

và sau đó phiên HTTPS bắt đầu.

Phiên TLS / SSL bắt đầu, nhưng có nhiều bước trước tiên.

Vì vậy, nếu tôi nói đúng ở trên, câu hỏi đặt ra là làm thế nào mà cuộc tấn công kẻ trung gian lại có thể xảy ra trong tình huống như vậy?

Bằng cách giả làm máy chủ và hoạt động như điểm cuối SSL. Khách hàng sẽ phải bỏ qua bất kỳ bước ủy quyền nào. Đáng buồn thay, bước ủy quyền duy nhất trong hầu hết các phiên HTTPS là kiểm tra tên máy chủ.

Ý tôi là ngay cả khi ai đó chặn phản hồi của máy chủ (ví dụ: www.server.com) bằng khóa công khai và sau đó bằng một số phương tiện để tôi nghĩ rằng anh ta là www.server.com, anh ta vẫn không thể giải mã khóa phiên của tôi không có khóa riêng.

Xem ở trên. Không có khóa phiên để giải mã. Bản thân kết nối SSL là an toàn, người bạn đang nói chuyện có thể không an toàn.

Nói về xác thực lẫn nhau, có phải là tất cả về độ tin cậy của máy chủ về danh tính khách hàng không? Ý tôi là, khách hàng đã có thể chắc chắn rằng cô ấy đang giao tiếp với đúng máy chủ, nhưng bây giờ máy chủ muốn tìm ra ai là khách hàng, phải không?

Chính xác.

Và câu hỏi cuối cùng là về giải pháp thay thế cho xác thực lẫn nhau. Nếu tôi đóng vai trò khách hàng trong tình huống được mô tả, điều gì sẽ xảy ra nếu tôi gửi thông tin đăng nhập / mật khẩu trong tiêu đề HTTP sau khi phiên SSL được thiết lập? Như tôi thấy, thông tin này không thể bị chặn vì kết nối đã được bảo mật và máy chủ có thể dựa vào đó để nhận dạng của tôi. Liệu tôi có sai?

Không.

Nhược điểm của cách tiếp cận như vậy so với xác thực lẫn nhau (chỉ các vấn đề bảo mật là quan trọng chứ không phải sự phức tạp khi triển khai)?

Nó chỉ an toàn như tên người dùng / mật khẩu, dễ bị rò rỉ hơn rất nhiều so với khóa riêng tư.

Bất kỳ ai trên con đường giữa máy khách và máy chủ đều có thể ngăn chặn một cuộc tấn công ở giữa trên https. Nếu bạn cho rằng điều này là không chắc hoặc hiếm, hãy xem xét rằng có những sản phẩm thương mại giải mã, quét và mã hóa lại một cách có hệ thống tất cả lưu lượng ssl qua cổng internet. Chúng hoạt động bằng cách gửi cho khách hàng một chứng chỉ ssl được tạo nhanh chóng với các chi tiết được sao chép từ chứng chỉ ssl "thực" nhưng được ký bằng một chuỗi chứng chỉ khác. Nếu chuỗi này kết thúc với bất kỳ CA đáng tin cậy nào của trình duyệt, MITM này sẽ ẩn đối với người dùng. Các sản phẩm này chủ yếu được bán cho các công ty để "bảo mật" mạng công ty (cảnh sát) và phải được sử dụng với sự hiểu biết và đồng ý của người dùng. Về mặt kỹ thuật, không có gì ngăn cản ISP hoặc bất kỳ nhà cung cấp mạng nào khác sử dụng chúng. (Sẽ an toàn nếu giả sử NSA có ít nhất một khóa ký CA gốc đáng tin cậy ).

Nếu bạn đang phân phối một trang, bạn có thể bao gồm tiêu đề HTTP cho biết khóa công khai mà trang sẽ được ký bằng. Điều này có thể giúp cảnh báo người dùng với MITM về kết nối "an toàn" của họ, nhưng đó là một kỹ thuật sử dụng tin cậy. Nếu Bob chưa có bản ghi về ghim khóa công khai "thực", Mallory chỉ cần ghi lại tiêu đề pkp trong tài liệu. Danh sách các trang web sử dụng công nghệ này (HPKP) rất ngắn. Nó bao gồm google và dropbox, tín dụng của họ. Thông thường, một cổng chặn https sẽ chạy qua các trang từ một số trang web đáng tin cậy lớn sử dụng HPKP. Nếu bạn gặp lỗi HPKP mà bạn không mong đợi, hãy cảnh giác.

Về mật khẩu, mọi thứ trên kết nối https đều được bảo mật bằng https, ngoại trừ tên miền, cần phải rõ ràng để có thể định tuyến yêu cầu. Nói chung, bạn không nên đặt mật khẩu trong chuỗi truy vấn, nơi chúng có thể lưu lại trong nhật ký, dấu trang, v.v. Nhưng chuỗi truy vấn sẽ không hiển thị trừ khi https bị xâm phạm.

1. Chính xác
2. Không đúng như vậy. Trong kiểu tấn công đó, máy chủ ngay lập tức nhận được yêu cầu của bạn và thay mặt bạn gửi yêu cầu đó đến đích. và sau đó trả lời bạn với kết quả. Trên thực tế, đó là máy chủ man-in-the-middle giúp kết nối an toàn với bạn chứ không phải máy chủ thực tế mà bạn muốn kết nối. đó là lý do tại sao bạn PHẢI luôn kiểm tra chứng nhận là hợp lệ và đáng tin cậy.
3. có thể đúng
4. Nếu bạn chắc chắn rằng kết nối an toàn là đáng tin cậy thì bạn sẽ an toàn để gửi tên người dùng / mật khẩu.

Tất cả mọi thứ bạn đã nói đều đúng ngoại trừ phần về khóa phiên. Mục đích của CA là đánh bại một cuộc tấn công man-in-the-middle - mọi thứ khác đều do chính SSL thực hiện. Xác thực máy khách là một giải pháp thay thế cho lược đồ tên người dùng và mật khẩu.