TLS and SSH rely on basically the same math for their connections. The connection is initiated with asymmetric encryption, and part of that is exchanging (encrypted, of course) a symmetric session key for faster encryption of the main session traffic.
The main difference comes in how that initial asymmetric key is determined to be the one that legitimately belongs to the server, rather than an attacker who is trying to intercept communications.
To verify its keys, TLS has the whole Certification Authority structure, where some public keys are shared in advance, and essentially used to verify that the host key offered by the server is legitimate. Those keys shared in advance are the trusted roots, and the signing process results in a server certificate saying, “This certificate for ‘foo.example.com’ is approved by ‘Trusted Root XYZ’.” A browser receiving the ‘foo.example.com’ certificate can check, using its stored copy of Trusted Root XYZ’s public key, that the approval is actually valid.
Certificates also have an expiration time built into them, to force key rollover, and potentially limit the amount of time a stolen certificate can be used while still validating correctly. Although the cynical will add that it also forces you to buy a re-key every so often, so the CA can make more money.
SSH, in contrast, doesn’t have any authentication of the host key. This explains everything about “known hosts” (or, for you PuTTY fans, “caching the key in the Registry”): since the key isn’t self-authenticated by signatures from pre-shared authorities, SSH has to ask you if you think the host key is valid when it sees an unknown host. (You are theoretically supposed to check the weird hex string with the server admin, but in practice, I doubt anyone does.) Likewise, SSH doesn’t have a built-in expectation of key rollover, so if that host key changes, the client must display an even scarier warning that you may actually be under attack.
After all, since it can’t verify keys to begin with, it can’t determine whether the new key is evil, or legitimately changed. TLS relies on the CA to not issue certificates to fraudsters, so it accepts any valid certificate with the expected name on it, and doesn’t keep track of keys over time.
It should be clear now why TLS is used for all kinds of things on the Internet, and SSH is only used for SSH: for the latter, typical use is to log into a manageable number of servers, with a username and password set up in advance, and the exchange of the host key fingerprint for the initial connection can theoretically be included in that setup. Random Web sites and email servers on the Internet, though, don’t need authentication set up in advance, so they are better served by the CA signature system: anyone that knows the CA used by the site can connect with confidence.
You can fix the insecure precursors of SSH by building them with TLS support, but one bonus of having separate protocols is that if you break all of your TLS-based servers when updating your certificate, your SSH server still works.
No comments:
Post a Comment