11

SSL operations require the use of a trusted third party -- the certificate authority to verify a public key presented by a server to a client.

SSH on the other hand relies on the client having the server's public key by some other means (e.g., by accessing it physically from the server and saving it at the client).

Why do these protocols have such a difference in operation mechanisms? I mean they could both use the third party approach which to me seems more user-friendly and possibly more secure.

Improve this question
7
  • 3
    @MikeOunsworth: that does not seem to be a duplicate.
    – Lie Ryan
    Commented Jun 12, 2016 at 5:21
  • 4
    @LieRyan Did you click the link? Your answer below provides a good intuition on why it might make sense for this to be the case, but the linked answer provides the definitive answer from the OpenSSH devs. "Why doesn't SSH use certificates?" ... "Because the devs thought it introduced too much attack surface. Oh by the way, it can use certificates if you configure it right." The answer doesn't get more canonical than that!
    – Mike Ounsworth
    Commented Jun 12, 2016 at 5:45
  • @MikeOunsworth The answer may also be useful here, but it's just a side note there. Your quote is twisting the words, because the question was about the configuration, not about the reason. We should not close questions based on answers, it makes the decision much more ambiguous.
    – Christian Strempfer
    Commented Jun 12, 2016 at 16:11
  • @ChristianStrempfer I respectfully disagree, the closed-as-dup auto text is: "This question already has an answer here:" -- it has nothing to do with whether the questions match.
    – Mike Ounsworth
    Commented Jun 12, 2016 at 16:20
  • @MikeOunsworth: You're cherry picking. The close reason is "This question has been asked before and already has an answer.", therefore the text "This question already has an answer here" assumes the close reason was applied correctly.
    – Christian Strempfer
    Commented Jun 12, 2016 at 17:45

2 Answers 2

Reset to default
16

Because they're used differently. TLS/SSL x509 certificates as commonly used in HTTPS is used to connect to public systems, i.e. systems that are accessed by a large number of people, most of whom had no prior out-of-band connection with the owner of the system.

SSH, on the other hand, are primarily used to access private systems by a small number of server administrators who have had prior access to the system to setup the server keys or other forms of out-of-band access to the system to verify the server key fingerprint.

Note that the SSH model is insecure if you do not verify that the key fingerprint presented by the server matches what you expect before connecting. In TLS, the responsibility of checking the ownership of the key fingerprint is offloaded to certificate authorities (CA).

TLS can also be used with self signed certificate or with private CA, which works in similar trust model as SSH.

Improve this answer
1
  • 1
    Adding a link to TOFU to complete your fine answer
    – Neil Smithline
    Commented Jun 12, 2016 at 1:49
2

For the purpose of authenticating a server to a connecting user, the difference in the implementation which you observed is not really a technical one. Particularly:

  • SSL does not require the use of a trusted third partyーyou can use SSL with self-signed certificates (which would be equivalent of how SSH keys authentication works).

  • SSH can use a server authentication method that does not rely on human verification (see Kerberos).

The difference is how, what for, and by whom the two protocols are used:

Current global SSL PKI infrastructure is aimed at huge number of technically non-savvy users for whom it provides a way to verify public services.

SSH in comparison has very limited usage and is not aimed at general public. The burden of establishing a central trust (even Kerberos for smaller organisations) is large in comparison to value gained.

Improve this answer
4
  • Kerberos is not a distributed trust and identify validation model the way PKI is. When used for authentication, it is aware of all users. PKI isn't like that
    – Neil Smithline
    Commented Jun 12, 2016 at 1:56
  • But the question is about server authentication in SSH and the need for key verification by human vs. relying on 3rd party, if I am not mistaken. Does Kerberos mitigate the requirement for human verification, or not?
    – techraf
    Commented Jun 12, 2016 at 1:58
  • It is the "equivalent of PKI" statement that sits wrong with me. It sounds like you are saying that it serves a similar role in automated validation of public keys. That seems right to me
    – Neil Smithline
    Commented Jun 12, 2016 at 2:04
  • That's why before the words you quoted I wrote "could be seen as" (two layers of uncertainty apart from "is"), but it seems it did not work the way I intended. Thanks, for feedback. I deleted it. Didn't bring any new value anyway.
    – techraf
    Commented Jun 12, 2016 at 2:06

Not the answer you're looking for? Browse other questions tagged .