95
$\begingroup$

Most cryptographically protected protocols use TLS these days. This applies to mail protocols, HTTP and many others. The newly designed QUIC has also adopted TLS as its cryptography layer.

However, SSH is different: it has its own cryptography layer.

Why does SSH have a non-TLS cryptography layer? Are there any benefits for SSH to have its own cryptography layer?

About the only difference between SSH and other protocols is that SSH frequently sends messages having just one keystroke. Is the SSH cryptography layer more optimal in the case of extremely short messages?

Related although not the same: How does TLS differ from SSH from a strictly cryptographic perspective?

I think the certificate verification mechanism of SSH (automatically learning) could be supported with TLS. You just wouldn't have a root CA; you would accept each certificate separately and remember the acceptance.

Improve this question
$\endgroup$
3
  • $\begingroup$ Assuming you mean SSL rather than TLS, the inventor of SSH is on Twitter - he seems like anice guy, so you could try asking him: Tatu J Ylonen $\endgroup$
    – Cocowalla
    Jun 26, 2018 at 21:02
  • $\begingroup$ "cryptographically protected protocols" You mean, most connection oriented, client-server, full duplex octet stream protocols? $\endgroup$
    – curiousguy
    Jun 26, 2018 at 21:09
  • $\begingroup$ I think that this is a right idea and even we can ask otherwise: why TLS is not built upon SSH? Anyway, given that TLS is partially supported by Linix Kernel this makes a lot of sense to implement SSH over TLS $\endgroup$
    – Sergey Ponomarev
    May 2, 2019 at 9:37

2 Answers 2

Reset to default
80
$\begingroup$

SSH not using TLS is mostly historical; see for instance this answer (on security.SE). In practice, one could perfectly define a sort-of SSH that would use TLS for the data transport part; but, of course, it would not be compatible with existing SSH servers and clients. From a pure cryptographic point of view, SSH actually has some shortcomings with its encrypt-and-MAC encryption, and encrypted "length" field; this does not lead to really exploitable vulnerabilities due to the specific usage of SSH (attackers don't get to trigger thousands of new silent connections with partially chosen data, contrary to TLS, where such things can be done thanks to the magic of JavaScript), and recent AEAD integration mostly fixes them anyway.

Improve this answer
$\endgroup$
2
  • 19
    $\begingroup$ And, had SSH chosen SSL transport in 1995 (SSH is that old) it would have fallen long ago. It's essentially NIH choice turned away almost all plausible attacks for a very long time. There's really only been one protocol-incompatible change over the years due to crypto junk where SSL had at least 4. $\endgroup$
    – Joshua
    Jun 24, 2018 at 21:16
  • 3
    $\begingroup$ SSH's newer ETM modes, and its chacha20-poly1305 implementation which does encrypt the length fields solves some of that. $\endgroup$
    – forest - on strike ♦
    Jun 25, 2018 at 2:41
51
$\begingroup$

If by TLS, you mean specifically the series of protocols that is named "TLS", then the answer to why SSH wasn't designed to use them, is quite simple: they didn't exist when SSH was designed. TLS was released in 1999, SSH in 1995.

If you are referring to the whole family of protocols that is now known as TLS but used to be known as SSL, then the answer is similar: SSL 2.0 was released in 1995, the same year as SSH. It is thus likely that SSH had at least partly already been designed before SSL became known.

SSL 1.0 already existed in 1994, but it was never released as a protocol, because it was soon discovered that it was severely broken. This may also have weakened Ylonen's trust in SSL, so even if he knew about it and considered using it, this may have influenced him to roll his own.

Improve this answer
$\endgroup$
5
  • 3
    $\begingroup$ the fact that you generally need to get a TLS cert, rather than to just directly trust the keypair fingerprint is a huge downside to how TLS is usually deployed vs normal SSH usage. You could design an SSH with TLS impl to prompt to just trust the keypair like SSH does though. $\endgroup$
    – Rob
    Jun 25, 2018 at 19:57
  • 1
    $\begingroup$ @Rob Directly trusting the keypair is a weakness of SSH. If the key is not verified through a side channel, it opens the door to a MitM attack on the first connection. The attack would be detected if any subsequent connection is not compromised. $\endgroup$
    – StackOverthrow
    Jun 25, 2018 at 20:30
  • 7
    $\begingroup$ But SSH is used in an enterprise setting, where checking the fingerprints is viable. I'd argue that a huge trust store of stuff that you don't know at all is what the real issue is. (ie: The Turkish CA should be read as "Turkish Intelligence Agency" if you don't live in Turkey.). Browsers have way too many trusts. In non-browser environments and enterprises, it's pretty common to wipe away ALL trusts except those from the internal CA. $\endgroup$
    – Rob
    Jun 25, 2018 at 21:19
  • 2
    $\begingroup$ @Rob The security model for FTPS (FTP/TLS) on FileZilla Client isn't based on mandatory CA (unlike Web browsers), but on "ask the user about new public keys, then keep and trust" also known as trust-on-first-use ("TOFU"). $\endgroup$
    – curiousguy
    Jun 26, 2018 at 22:51
  • $\begingroup$ Interestingly, the third edition of Unix Power Tools says: "SSH uses Secure Sockets Layer (SSL), the same security mechanism that web browsers use." I assume that's an error in the book. $\endgroup$
    – Matthias Braun
    Sep 27, 2021 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.