No public keys are meant to be public, either yes key will be correct or not. This is why (to my knowledge) package managers like apt still check http endpoints instead of https ones.
>No public keys are meant to be public, either yes key will be correct or not.
Yeah but how do you know if the key is correct if you're getting it for the first time?
>This is why (to my knowledge) package managers like apt still check http endpoints instead of https ones.
Your distro ships with a public key that lets you verify package signatures. TLS is redundant because you already have that trust anchor which came with the distro. (I would suggest using TLS anyway though, to force an attacker to break 2 layers of security.)
OpenSSH has built-in support for retrieving a key fingerprint over DNSSec-secured DNS. It's disabled by default.
If you enable it, the first connection to a new host will say "matching host key fingerprint found in DNS" if DNSSec is operational AND the retrieved key matches.
It's a little baffling that anyone would set this up, as the thing it promises is key integrity backed by government-controlled PKI. The impulse is sound! It's a good thing to want! But you can accomplish the same thing, and get other benefits, without forklifting DNSSEC into your zone configuration, by using SSH's certificate system. SSH certificates aren't X.509; they're much simpler.
First, the DNSSec keys are TOFU so only the first connection is attack-able by someone in control of DNS zone root keys, and any other connections set off alarm bells.
Second, DNS lets you connect to someone else's host and get their public key without needing to find their (not your) CA.
Third, if you're not entering IP addresses by hand DNS forms some part of your systems trust no matter what you do. You're free to pin a domain's DNSSec KSK if you're very worried about someone in control of the whole Internet using that control to trick your first SSH connections.
I don't deny that, I was just pointing out that the threat model in question is someone in control of every DNS record somehow making a change that only affects new SSH connections. Because they control the record that says which KSK is okay for which domain, but presumably don't have your DNSSec private key.
The attack would be delicate to say the least .
Repeating, the purpose of DNS is for discovering sonething you don't administer. Like the SSH public key of a host, or the mailserver for a domain. CA certificates are for securing something you do administer.
Yes that's a great point. I wish distros would force all mirrors to be TLS. Security should be the default. If users want to use a fast insecure mirror, they can enable that option at their discretion.
In this case they're related because of supply chain attacks. If an attacker learns that you're using a small obscure package, they might be able to hack the developer's machine and insert a backdoor or bugdoor.
I suspect you could extend that line of logic to always combine privacy and security. Which, granted is not exactly wrong, but that's just security through obscurity and you really shouldn't rely on it.
(Of course, if it's free then you should strongly consider taking the obscurity, and privacy is a compelling argument all on its own. I just think blurring the line here is iffy.)
Yeah but how do you know if the key is correct if you're getting it for the first time?
>This is why (to my knowledge) package managers like apt still check http endpoints instead of https ones.
Your distro ships with a public key that lets you verify package signatures. TLS is redundant because you already have that trust anchor which came with the distro. (I would suggest using TLS anyway though, to force an attacker to break 2 layers of security.)