Có phải lỗi Heartbleed gần đây ảnh hưởng đến các khóa ssh tôi đã tạo và sử dụng để đẩy / kéo mã với Github, Heroku và các trang web tương tự khác không?
Tôi có cần thay thế các phím tôi đang sử dụng không?
Có phải lỗi Heartbleed gần đây ảnh hưởng đến các khóa ssh tôi đã tạo và sử dụng để đẩy / kéo mã với Github, Heroku và các trang web tương tự khác không?
Tôi có cần thay thế các phím tôi đang sử dụng không?
Câu trả lời:
Không, Heartbleed không thực sự ảnh hưởng đến các khóa SSH, vì vậy bạn có thể không cần thay thế các khóa SSH bạn đang sử dụng.
Đầu tiên, SSL và SSH là hai giao thức bảo mật khác nhau cho hai mục đích sử dụng khác nhau. Tương tự như vậy, OpenSSL và OpenSSH cũng là hai gói phần mềm hoàn toàn khác nhau, mặc dù có sự tương đồng trong tên của chúng.
Thứ hai, khai thác Heartbleed làm cho đồng đẳng OpenSSL TLS / DTLS dễ bị tổn thương trả lại bộ nhớ 64kB ngẫu nhiên, nhưng hầu như chắc chắn giới hạn bộ nhớ có thể truy cập vào quy trình sử dụng OpenSSL đó. Nếu quy trình sử dụng OpenSSL đó không có quyền truy cập vào khóa riêng SSH của bạn, thì nó không thể rò rỉ thông qua Heartbleed.
Ngoài ra, bạn thường chỉ đặt khóa công khai SSH của mình trên các máy chủ bạn sử dụng SSH để kết nối và như tên của nó, khóa công khai là khóa bạn có thể công khai. Nó không quan trọng ai biết điều đó. Trong thực tế, bạn muốn công chúng biết khóa công khai chính xác của bạn.
Cảm ơn @Bob đã chỉ ra rằng lỗ hổng này có thể ảnh hưởng đến các ứng dụng khách sử dụng các phiên bản OpenSSL dễ bị tổn thương làm thư viện TLS / DTLS phía máy khách của họ. Vì vậy, nếu, ví dụ, trình duyệt web hoặc máy khách VPN dựa trên SSL của bạn đã sử dụng phiên bản OpenSSL dễ bị tấn công và được kết nối với máy chủ độc hại, máy chủ độc hại đó có thể sử dụng Heartbleed để xem các đoạn ngẫu nhiên của bộ nhớ của phần mềm máy khách đó. Nếu ứng dụng khách đó vì một lý do nào đó có một bản sao khóa riêng SSH của bạn trong bộ nhớ, thì nó có thể bị rò rỉ qua Heartbleed.
Ngoài đỉnh đầu, tôi không nghĩ đến bất kỳ phần mềm nào ngoài SSH có thể có một bản sao khóa riêng SSH không được mã hóa của bạn trong bộ nhớ. Chà, điều đó giả định rằng bạn giữ các khóa riêng SSH được mã hóa trên đĩa. Nếu bạn không giữ khóa riêng SSH của mình được mã hóa trên đĩa, thì tôi cho rằng bạn có thể đã sử dụng một số chương trình truyền hoặc sao lưu tệp sử dụng OpenSSL TLS để sao chép hoặc sao lưu thư mục chính của bạn qua mạng (bao gồm cả ~/.ssh/id_rsakhóa riêng SSH hoặc khác của bạn ), sau đó nó có thể có một bản sao không được mã hóa của khóa riêng SSH của bạn trong bộ nhớ. Sau đó, một lần nữa, nếu bạn đang sao lưu khóa riêng SSH không được mã hóa của mình vào một máy chủ độc hại, có lẽ bạn đã có những lo lắng lớn hơn Heartbleed. :-)
"Thứ hai, việc khai thác Heartbleed khiến cho đồng đẳng OpenSSL TLS / DTLS dễ bị tổn thương trả lại bộ nhớ 64kB ngẫu nhiên, nhưng hầu như chắc chắn giới hạn bộ nhớ có thể truy cập vào quá trình sử dụng OpenSSL đó."
Nếu máy bị xâm nhập thì làm sao bạn có thể tin tưởng bất cứ thứ gì vào nó, kể cả ssh? từ heartbleed.com
"Những gì rò rỉ trong thực tế?
Chúng tôi đã thử nghiệm một số dịch vụ của chúng tôi từ quan điểm của kẻ tấn công. Chúng tôi tấn công mình từ bên ngoài, không để lại dấu vết. Không sử dụng bất kỳ thông tin hoặc thông tin đặc quyền nào, chúng tôi có thể tự đánh cắp các khóa bí mật được sử dụng cho chứng chỉ X.509, tên người dùng và mật khẩu, tin nhắn tức thời, email và tài liệu quan trọng và liên lạc kinh doanh. "
ai đó có thể đã đặt khóa riêng, không có cụm mật khẩu, trên máy chủ mà họ cho là không độc hại ... nhưng hóa ra là như vậy. b / c Lỗi SSL cho phép mật khẩu người dùng thoát ra, một người dùng đã 'sudo' ... có lẽ đó không phải là vấn đề .... nhưng ...
mọi người đôi khi làm những thứ điên rồ
http://blog.vutionsource.org/2010/08/28/mining-passwords-from-public-github-repose khu /