Buộc Chrome bỏ qua "khóa công khai Diffie-Hellman yếu đuối


17

Với bản cập nhật của Chrome lên v45, nó sẽ chặn quyền truy cập vào các trang có khóa công khai Diffie-Hellman yếu. Tôi hiểu rằng đây là do Logjam. Tôi hiểu rằng việc chuyển từ https sang http là một "giải pháp" trong một số trường hợp.

Tuy nhiên, tôi không thể chuyển từ https sang http vì tôi tự động chuyển hướng sang https bằng phần mềm dựa trên web mà chúng tôi sử dụng trên mạng nội bộ của mình.

Rõ ràng, giải pháp sẽ là bảo mật thay đổi các máy chủ mạng nội bộ khác nhau để bảo mật khỏi logjam, tôi hiểu điều đó, nhưng đó không phải là một lựa chọn ngay lúc này và tôi không thể thực hiện thêm bất kỳ công việc nào cho đến khi nó được sửa. Bởi vì đó là một mạng nội bộ và chỉ đơn giản là kết nối tất cả đòi hỏi một người phải ở đây, nên rủi ro là rất nhỏ.

Có cách nào để tôi có thể tiếp tục truy cập các trang thông qua giao thức https, với các khóa công khai yếu kém Diffie-Hellman trong phiên bản Chrome 45 không?


Per: productforums.google.com/forum/#!topic/chrom/xAMNtyxfoYM dường như có thể vô hiệu hóa các bộ mật mã riêng lẻ để khắc phục sự cố. Bên ngoài điều hiển nhiên (giảm bảo mật của bạn làm tăng rủi ro của bạn trên các mạng bên ngoài), có bất kỳ nhược điểm nào khi sử dụng điều này trên mạng nội bộ không? Và thêm thông tin về: fehlis.blogspot.com/2013/12/ Mã code.google.com/p/chromium/issues/detail?id=58833
Raine Dragon

Câu trả lời:


8

Khắc phục sự cố để khắc phục sự cố này (Mac OSX)

  • Chạy phần này trong dòng lệnh để khắc phục sự cố trong khi khởi chạy Chrome

Trình duyệt Chrome:

open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Hoàng yến

open /Applications/Google\ Chrome\ Canary.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Dành cho Firefox

  • Chuyển đến about: config
  • Tìm kiếm security.ssl3.dhe_rsa_aes_128_shasecurity.ssl3.dhe_rsa_aes_256_sha
  • Đặt cả hai để false.

LƯU Ý: Khắc phục vĩnh viễn sẽ là cập nhật khóa DH với độ dài> 1024


5

Thật vậy, dường như các trình duyệt đã thực hiện nghiêm túc vấn đề Diffie-Hellman với các khóa thấp hơn 1024, điều này là một tin tuyệt vời , nhưng mặt khác, nó đã tạo ra rất nhiều người dùng Chrome tức giận .

Khắc phục sự cố này (và nhiều vấn đề khác liên quan đến bảo mật) là trách nhiệm của sysadins, vì vậy theo tôi hiểu, quyết định chặn bất kỳ trang web nào cung cấp khóa Diffie-Hellman yếu 512 bit hoặc thấp hơn là thước đo áp lực hướng đến những người quản lý bảo mật trên các trang web từ xa, với "nhược điểm" của người dùng phải chịu các hiệu ứng.

Hiện tại có thể liệt kê một số Coder Suites khi khởi chạy trình duyệt Google Chrome bằng cách chạy nó với --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013tham số, dường như vô hiệu hóa các lỗ hổng liên quan đến lỗ hổng LogJam và cho phép người dùng tham gia các trang web, nhưng tôi khẳng định rằng đó phải là trách nhiệm của sysadmins để khắc phục sự cố với các khóa Diffie-Hellmann của họ.


Cảm ơn nKn, đã làm việc như một cơ duyên với Cisco Finesse khi Chrome được cập nhật lên phiên bản 45 ... và tôi không thể truy cập chương trình ngay bây giờ.
Christopher Chipps

0

Một trong những điều bạn hỏi là liệu có bất kỳ nhược điểm nào khi sử dụng các cách giải quyết được liệt kê (hoặc sử dụng các cách khác không được liệt kê) trong thiết lập mạng nội bộ hay không. Câu trả lời ngắn gọn là miễn là các máy chủ liên quan đang sử dụng khóa yếu, các máy chủ liên quan sẽ dễ bị bất kỳ hệ thống nào sử dụng tấn công logjam và tùy thuộc vào bản chất của máy chủ, máy chủ sau đó có thể là máy chủ bị xâm nhập có thể truyền bá vấn đề cho các khách hàng khác truy cập vào máy chủ.

Hai tình huống không thể xảy ra là một máy tính xách tay đã bị lây nhiễm khỏi mạng nội bộ truy cập vào máy chủ nội bộ khi chúng kết nối lại với mạng nội bộ hoặc trình duyệt được định cấu hình để bỏ qua sự cố (như được đề xuất ở trên và ở nơi khác) hiện đang được sử dụng để truy cập internet và tình cờ kết nối với một máy chủ bị xâm nhập là điểm khởi đầu để tấn công các máy chủ mạng nội bộ của bạn.

Vì cá nhân tôi không quen thuộc với tất cả các vấn đề mà lỗ hổng logjam đưa ra, tôi không thể nói nếu một trong hai tình huống đó có khả năng đặc biệt xảy ra. Kinh nghiệm của riêng tôi là các sysadins có máy chủ phải đối mặt với Internet có xu hướng vượt xa các vấn đề như họ có thể. Điều đó nói rằng kinh nghiệm của tôi cũng là các quản trị viên máy chủ mạng nội bộ có xu hướng làm những việc như làm cho các trang web đẹp trước khi giải quyết các vấn đề bảo mật máy chủ.


0

Đối mặt với cùng một vấn đề. Nếu bạn là anh chàng phía máy chủ, chỉ cần thêm các dòng sau trong trình kết nối 443 trong tomcat của server.xml

sslProtocols = "TLSv1, TLSv1.1, TLSv1.2" mật mã = ​​"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA"

Điều này sẽ giúp bạn giải quyết vấn đề khóa SSL này.

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.