Bug 688988
| Summary: | FR: Add local DNSSEC validation to OpenSSH | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kenny Root <kenny> | ||||
| Component: | openssh | Assignee: | Dmitry Belyavskiy <dbelyavs> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | cra, gl041188, mattias.ellert, pwouters, rs, tmraz, wjhns174 | ||||
| Target Milestone: | --- | Keywords: | FutureFeature | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-11-03 09:46:54 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Kenny Root
2011-03-18 18:10:04 UTC
was these patches sent to upstream? what upstream said to them? is there upstream bz# or mail thread about it? ping can you respond please? Sorry, I was waiting for the author to respond to an email. I've attached the upstream bugzilla URL to this ticket. I suggest to wait while upstream does not respond to their bugzilla. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. note that fedora is moving to having a dnssec validating resolver on localhost, so ssh whould not need to do anything specific I would not add these patches but instead trust the localhost resolver. Especially since we reconfigure the local resolver using dnssec-trigger/unbound (to move migrated into networkmanager). If you patch ssh, then it will not know about any locally configured trust anchors anyway, and it will not do any workarounds for getting a working dnssec capable upstream resolver, something that the current dnssec-trigger+unbound does do for us. Paul: I disagree with your notion that SSH doesn't need in-application validation. Yes, it's great that the local resolver SHOULD have DNSSEC support, but the reality is that an application can't trust that and has no signaling mechanism available to be sure that the response actually came from the local resolver. It may be that future versions of Fedora will come with a default local validating resolver, but in order for a security critical application (such as SSH querying for remote fingerprints) you can't trust that an administrator hasn't changed the packaging or DNS setup. And there is no way to tell, so IMHO: it's critical that doing in-application validation is better in general and critical for cases where you're making security decisions based on the results of a DNS lookup. Does ssh trust the AD bit even when the resolver is not localhost? I thought there was a check for that to prevent this exact scenario? If so, then protecting against a modified local dns server seems silly, as the attacker an then also just modify the local ssh client. But I know some of the ssh behaviour also depending on GLIBC settings, so I am not entirely sure what the current ssh client allows for giving it an AD bit it trusts. I thought it would treat "yes" as "ask" for VerifyHostKeyDNS if the resolver was not localhost, but I'd have to double check that with the current code. But I guess you're right in that it does not hurt in this case, if the only difference is ssh treating a response more insecure then it really is and giving the user the additional text in the prompt before accepting. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Created attachment 1797739 [details]
I believe i can fly
Looks like this bug had no real interest since 2012. If it is still relevant, please report the new one. |