Điểm:2

Trong TLS, máy khách có biết khóa chung của máy chủ trước khi bắt đầu trao đổi dữ liệu không?

lá cờ cn

Tôi đang đọc về cuộc tấn công logjam. Tôi đã được hỏi liệu cuộc tấn công có thể được ngăn chặn bằng cách kiểm tra tính toàn vẹn của máy chủ xin chào thông điệp.

Câu trả lời của tôi sẽ là không vì người trung gian vẫn không thể gửi bản gốc máy chủ xin chào tin nhắn và gửi của riêng mình.

Theo nghiên cứu của tôi, có vẻ như khách hàng chỉ nắm giữ khóa công khai của máy chủ trong quá trình máy chủ xin chào thông báo bao gồm khóa công khai của máy chủ.

Nếu đúng như vậy, câu trả lời của tôi phải đúng.

Có cách nào để khách hàng biết khóa công khai của máy chủ trước máy chủ xin chào thông điệp?

dave_thompson_085 avatar
lá cờ cn
Khóa công khai của máy chủ nào? Cái được sử dụng để xác thực hoặc cái được sử dụng để trao đổi khóa luôn khác trong 1.3 và thường nhưng không phải lúc nào cũng khác trong các giao thức trước đó? _Only_ khóa kx tạm thời trong 1.3 nằm trong ServerHello và không thể sử dụng khóa đó để xác minh tính toàn vẹn của bất kỳ thứ gì. Nhưng Logjam sẽ không áp dụng cho 1.3 vì nó không còn cho phép các nhóm FFDH quá nhỏ hoặc không được xác thực và có khả năng bị lỗi cho kx.
Jack avatar
lá cờ cn
@dave_thompson_085 như đã thấy ở đây: https://cryptologie.net/upload/logjam.png tin nhắn ServerHello gửi certS, sign(skS,[p512, g, g^b]). Tôi đang cố gắng tìm hiểu xem liệu trong thời điểm này, khách hàng có thể xác minh danh tính của máy chủ hay không, cuộc tấn công logjam có thể bị ngăn chặn không?
dave_thompson_085 avatar
lá cờ cn
Sơ đồ đó chỉ hiển thị các mục dữ liệu cụ thể có liên quan đến cuộc tấn công, không phải ở bất kỳ đâu gần tất cả các giao thức và chắc chắn không phải là các thông báo chứa chúng. Xem RFC 2246 et seq. Mặc dù như Maarten đã nói, mục quan trọng đối với _verify_ là bộ mật mã được chọn và _that_ thực sự nằm trong ServerHello.
Điểm:1
lá cờ in

Cuộc tấn công, mà chúng tôi gọi là Logjam, được mô tả trong Hình 2 và dựa vào một lỗ hổng trong cách TLS soạn DHE và DHE_EXPORT. Khi một máy chủ chọn DHE_EXPORT cho một bắt tay, nó tiến hành bằng cách phát hành một chữ ký Máy chủKeyExchange tin nhắn chứa 512-bit $p_{512}$nhưng cấu trúc của nó tin nhắn giống hệt với tin nhắn được gửi trong DHE tiêu chuẩn bộ mật mã. Điều quan trọng là phần đã ký của máy chủ thông báo không bao gồm bất kỳ dấu hiệu nào của ciphersuite cụ thể mà máy chủ đã chọn. Với điều kiện khách hàng cung cấp DHE, kẻ tấn công tích cực có thể viết lại ứng dụng khách Khách hàngXin chào đến cung cấp một tương ứng DHE_EXPORT bộ mật mã được chấp nhận bởi máy chủ và xóa các bộ mật mã khác có thể được chọn thay thế. Kẻ tấn công viết lại máy chủXin chào đáp lại thay thế đã chọn DHE_EXPORT ciphersuite với một kết hợp non-export ciphersuite và chuyển tiếp Máy chủKeyExchange tin nhắn cho khách hàng như là. Khách hàng sẽ giải thích các tuple cấp xuất khẩu $(p_{512}, g, g^b)$ như các tham số DHE hợp lệ được chọn bởi máy chủ và tiến hành bắt tay. Các máy khách và máy chủ có bảng điểm bắt tay khác nhau tại thời điểm này sân khấu, nhưng kẻ tấn công có thể tính toán $b$ gần với thực tế thời gian sau đó có thể lấy được bí mật chính và các khóa kết nối để hoàn thành việc bắt tay với khách hàng, và sau đó tự do đọc và ghi dữ liệu ứng dụng giả làm máy chủ.

Và câu hỏi của bạn đọc:

Tôi đang đọc về cuộc tấn công logjam. Tôi đã được hỏi liệu có thể ngăn chặn cuộc tấn công bằng cách kiểm tra tính toàn vẹn của thông báo Xin chào Máy chủ hay không.

Và tôi đoán rằng câu trả lời là Vâng, nhưng chỉ khi nó sẽ ký/xác minh bộ mật mã đang được cung cấp trong máy chủXin chàovà có vẻ như ít nhất TLS lên đến 1,2 không làm được như vậy. Nói cách khác, bạn phải thay đổi giao thức TLS để bao gồm các bộ mật mã được cung cấp trong quá trình tạo/xác minh chữ ký, khiến giao thức này không tương thích với bất kỳ phần mềm TLS nào khác.

Vì vậy, hiện tại có vẻ như chỉ đơn giản là không cho phép bạn thực hiện để thực hiện DHE_EXPORT (hoặc DH tạm thời 1024 bit) là con đường chuyển tiếp cho TLS lên tới 1.2.

Jack avatar
lá cờ cn
Xin chào xin lỗi nhưng tại sao bạn lại nói là có? Ngoài ra, câu hỏi sẽ hoàn toàn ở giai đoạn ServerHello (xác minh danh tính ở đó)
Maarten Bodewes avatar
lá cờ in
Ý tôi là **về mặt lý thuyết** bạn cũng có thể ký bộ mật mã trong `ServerHello`, nhưng điều đó có nghĩa là thay đổi toàn bộ giao thức. Nếu bạn chỉ đang **sử dụng** giao thức thì đó là một lời khuyên **không**.
dave_thompson_085 avatar
lá cờ cn
Về mặt kỹ thuật, các tiêu chuẩn dành cho 1.1 và 1.2 (RFC 4346 và 5246) đã cấm tất cả các bộ xuất (DHE, staticDH, DHanon, plainRSA và (!) Kerberos, hãy nhớ điều đó chứ?) vì vậy _nên_ chỉ là sự cố cho tới 1.0, nhưng trong thực hành, tốt, ...

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.