What is the difference between SSL vs SSH? Which is more secure?

Question

What is the difference between SSH and SSL? Which one is more secure, if you can compare them together?
Which has more potential vulnerabilities?

This is not a real question. You are comparing apples and oranges. What might help is if you could explain why you want to know - as this might guide answers. eg are you looking to implement a secure access solution and are looking for the easiest to secure? — Rory Alsop, Jan 13 '11 at 10:04
@Rory I don't think so, as I know they both do a similar job (I'm not comparing apples and oranges), but maybe I am wrong so I become thankful if community show me my mistake. — Am1rr3zA, Jan 13 '11 at 10:07
@Am1rr3zA, it is not exactly right that they do a similar job. In practice, SSL and SSH are typically used for different purposes: SSH is most often used for remote log-in, SSL for encrypted web access. — D.W., Jan 19 '11 at 07:30
@D.W. It looks like they are used for the same thing sometimes, e.g. **SFTP** seems to be based on *SSH*, while **FTPS** is based on *SSL*. — Jonas, Jul 23 '11 at 01:16
If we divorce the meaningful use of these two protocols, yes the question is germane to it's intent. An analogy. Which is more secure? 1.)A deibold bank safe with magnetic failsafes? 2.)A 26 character password that changes daily and is 1024-bit encrypted? Most people would aruge the apples oranges debacle. IGNORE that one is to protect access to an electronic device and the other is physical and meant to protect cash. WHICH REQUIRES THE GREATER LEVEL OF EFFORT AND TIME TO ACCOMPLISH COMPROMISE. This is really what he is asking. If we answer with that mindset, it can be answered. — user30885, Sep 16 '13 at 14:59
In their own element each has a strength. So just look at it from a hack perspective. Which would you rather hack? Also, the question should be asked "Which is more secure for the purpose of...XYZ" Since he asked the question without providing the purpose that's where everyone got hung up. My example with the safe vs. logon shows two different purposes (which is where people were stating "Hey these two protocols and their security typically do not serve the same function in use" and that's absolutely correct. One may still possibly be "more secure" than the other. — user30885, Sep 16 '13 at 14:59

score 218 · Accepted Answer · answered Jan 13 '11 at 14:55

218

SSL and SSH both provide the cryptographic elements to build a tunnel for confidential data transport with checked integrity. For that part, they use similar techniques, and may suffer from the same kind of attacks, so they should provide similar security (i.e. good security) assuming they are both properly implemented. That both exist is a kind of NIH syndrome: the SSH developers should have reused SSL for the tunnel part (the SSL protocol is flexible enough to accommodate many variations, including not using certificates).

They differ on the things which are around the tunnel. SSL traditionally uses X.509 certificates for announcing server and client public keys; SSH has its own format. Also, SSH comes with a set of protocols for what goes inside the tunnel (multiplexing several transfers, performing password-based authentication within the tunnel, terminal management...) while there is no such thing in SSL, or, more accurately, when such things are used in SSL they are not considered to be part of SSL (for instance, when doing password-based HTTP authentication in a SSL tunnel, we say that it is part of "HTTPS", but it really works in a way similar to what happens with SSH).

Conceptually, you could take SSH and replace the tunnel part with the one from SSL. You could also take HTTPS and replace the SSL thing with SSH-with-data-transport and a hook to extract the server public key from its certificate. There is no scientific impossibility and, if done properly, security would remain the same. However, there is no widespread set of conventions or existing tools for that.

So we do not use SSL and SSH for the same things, but that's because of what tools historically came with the implementations of those protocols, not due to a security related difference. And whoever implements SSL or SSH would be well advised to look at what kind of attacks were tried on both protocols.

answered Jan 13 '11 at 14:55

Thomas Pornin

320,799
57
780
949

6

Good job. And in fact, since SSH is easier to set up than SSL, many people tunnel http (not https) inside SSH, e.g. to do remote system administration with a web GUI tool like ebox or webmin. – nealmcb Jan 17 '11 at 17:58
29

Just to point out, it's not quite true that the SSH guys "*should*" have used SSL: SSH was designed very specifically to have a small attack surface, and be very secure. SSHv2 has none of the problems and pitfalls in SSL/TLS, so going with a smaller thing that they understood well, with less complexity, they came out with something much better suited to their situation. It depends how paranoid you are: SSL isn't unusable, depending on the application, but SSH's design makes it acceptable in situations/security communities where SSL simply is not trusted. – Nicholas Wilson May 11 '12 at 18:01
5

@NicholasWilson "_SSH's design makes it acceptable in situations/security communities where SSL simply is not trusted_" such as... – curiousguy Jun 21 '12 at 15:49
9

SSL and SSH were developed in parallel (both being released in 1995), so whether SSH even _could_ have used SSL is not clear. Whether it _should_ have used the contemporary SSL 2.0 is very dubious too :-) – Feb 06 '13 at 18:27
6

Well, SSH 2.0 was a complete rewrite of the protocol and appeared some time around 1999, so that one could have reused SSL 3.0 or even TLS 1.0. But, of course, TLS _appears_ to be tied with X.509, which frightens developers away. – Thomas Pornin Feb 06 '13 at 18:53
@ThomasPornin, SSL came before SSH? – Pacerier Mar 21 '17 at 03:43
@NicholasWilson, Wow, so you are saying that **SSH's security beats SSL**? What about user185's answer below which states the complete oposite? – Pacerier Jun 17 '17 at 14:41
Yes, I do think that SSH's transport/encryption layer is preferable to SSL - for the reasons various people have given above (#1 excessive complexity of SSL due to vast number of patches to the protocol, to mitigate design flaws. Even up to TLS 1.1 there's tons of stuff which simply isn't best practices, and SSH 2.0 has fixed its problems offer the years while retaining a clear design. #2 X.509 gives a huge attach surface for TLS). – Nicholas Wilson Jun 17 '17 at 21:17
user185 sends to be comparing SSL to the SSH application protocol, which isn't really fair. SSH has a layered protocol model, only the bottom layer of which is comparable to SSL, and would beat it any day in size and simplicity of implementation. – Nicholas Wilson Jun 17 '17 at 21:19
@NicholasWilson: Thanks so much for this insight. I'm currently hunting for best practices to use to build a couple of evergreen cryptographically secure encapsulation systems in some long-term projects - one's a signed (plaintext) archive format, and the other is the encryption layer of a wire protocol for a messaging system. I've also long been wondering about constructing a lightning-fast replacement for SSH as a giant experiment. I wanted to mention these contexts in case you happened to know of some good starting points. – i336_ Aug 01 '17 at 14:27
TLS seems to be an extremely heavyweight system with a storied history and many layers of complexity in order to provide backward compatibility and interoperability. I fully expect I don't need all of it to create good security, but my difficulty is in identifying the cross-compatibility and "bureaucratic" bits while keeping the important parts of the machinery that contribute to the system's security. I guess what I'm saying is that TLS is recognized as "just use TLS and you'll be okay", but there are no collective ideas of what low-level components are also similarly good/safe/effective/etc. – i336_ Aug 01 '17 at 14:38
I guess my final question would be, considering the level of detail I'm trying to get at (and not afraid of getting at), what component parts of SSH are fundamentally better than TLS? Okay, so SSH doesn't have X.509. What other differences/pros/cons are there? -- Thanks so much for your time. – i336_ Aug 01 '17 at 14:42
1

Why not read the RFCs - and the OpenSSH source code is highly readable too. Some things to look out for: PRF definition, host authentication, MAC construction. Instead of constructing your own protocol, just use SSH. You can just grab the OpenSSH transport layer, and end up with calling code about the same complexity as using TLS from OpenSSL (but a simpler wire protocol). – Nicholas Wilson Aug 02 '17 at 14:00
Fascinating answer by @ThomasPornin, as usual. It would interesting to compare/contrast the key-based client authentication methods used by SSL and SSH respectively - i.e. client certificates used by SSL and public key authentication used by SSH. – mti2935 Jul 01 '20 at 12:31

score 94 · Answer 2 · edited Jan 16 '16 at 15:52

94

This isn't a reasonable comparison to make. SSL is a general method for protecting data transported over a network, whereas SSH is a network application for logging in and sharing data with a remote computer.

The transport layer protection in SSH is similar in capability to SSL, so which is "more secure" depends on what your specific threat model calls for and whether the implementations of each address the issues you're trying to deal with.

SSH then has a user authentication layer which SSL lacks (because it doesn't need it - SSL just needs to authenticate the two connecting interfaces which SSH can also do). In UTF-8 art:

      SSL              SSH
+-------------+ +-----------------+
| Nothing     | | RFC4254         | Connection multiplexing
+-------------+ +-----------------+
| Nothing     | | RFC4252         | User authentication
+-------------+ +-----------------+
| RFC5246     | | RFC4253         | Encrypted data transport
+-------------+ +-----------------+

Regarding the issue of which there are more potential attacks against, it seems clear that SSH has a larger attack surface. But that's just because SSH has a whole application built into it: the attack surface of SSL + whatever application you need to provide cannot be compared because we don't have enough information.

edited Jan 16 '16 at 15:52

Vilican

2,703
8
21
35

answered Jan 13 '11 at 09:58

8

-1 It is a reasonable comparison. You incorrectly make the assumption that OP is comparing SSL to the unix program [ssh(1)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/slogin.1). SSH is actually another protocol providing transport layer security, which happens to have special provisions for remote shells and remote execution. – jpillora Jan 11 '15 at 15:44
1

+1 @jpillora while I agree it does make sense to compare the two, the term SSH is not typically used to refer to the subset of the SSH protocol that handles transport layer security that would be directly comparable to SSL/TLS. It is almost exclusively used in reference to the application layer protocol which differs from SSL/TLS in the manner described in this answer. – freb May 04 '15 at 03:52
1

@freb the way they're referred in general does not change the truth of the matter. SSH is a protocol which is used as the transport layer for the ssh utility. The accepted and most voted answer reflects this fact. – jpillora May 04 '15 at 04:22
1

@jpillora I merely meant that I don't think the SSH transport layer protocol is what most people would mean given the phrasing of the question. However, given the answer that was accepted as correct, it must have been what OP was asking. – freb May 05 '15 at 00:20
1

@freb Right, most people do think that given the phrasing, which makes it even more important to correct this common misconception. – jpillora May 05 '15 at 01:05
[SSL/TLS](http://security.stackexchange.com/a/40038/29832) does have provisions that can be used to [authenticate the client](https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake). Keep in mind that SSL, per se, was deprecated [June 2015](https://tools.ietf.org/html/rfc7568), in favor of TLS.. – WarrenT Feb 09 '16 at 17:07
@WarrenT, I believe he's talking about authenticating the **user** (the login) whereas what you linked is talking about authenticating the interface. – Pacerier Mar 21 '17 at 03:49
"SSH then has a user authentication layer which SSL lacks" that's not true, you can authenticate the user with certificate or public keys in TLS – David 天宇 Wong Nov 03 '19 at 22:20

score 16 · Answer 3 · answered May 09 '13 at 16:03

16

From a strict cryptographic point of view, they both provide authenticated encryption, but in two different ways.

SSH uses the so-called Encrypt-and-MAC, that is the ciphered message is juxtaposed to a message authentication code (MAC) of the clear message to add integrity. This is not proven to be always fully secure (even if in practical cases it should be enough).

SSL uses MAC-then-Encrypt: a MAC is juxtaposed to the clear text, then they are both encrypted. This is not the best either, as with some block cipher modes parts of the MAC can be guessable and reveal something on the cipher. This led to vulnerabilities in TLS 1.0 (BEAST attack).

So they have both potential theoretical weaknesses. The strongest method is Encrypt-then-MAC (add a MAC of the ciphered message), which is implemented, e.g., in IPsec ESP.

answered May 09 '13 at 16:03

Halberdier

261
2
2

3

SSH's binary packet protocol is encrypt-and-MAC where for every plaintext message (m) it sends the ciphertext E(m)++MAC(m) (concatenate encrypted message with MAC), versus SSL which does E(m++MAC(m)). However, SSH is much more than just its binary packet protocol (key management, remote shell client/server, does file transfer, etc), while SSL (now called TLS) is just the transport layer protocol that is used in other protocols that add in the necessary functionality (e.g., HTTPS, FTPS, IMAPS etc.). Also see comparison of EtM, E&M, MtE at: http://crypto.stackexchange.com/questions/202 – dr jimbob May 09 '13 at 16:39
1

Fully agreed, there is much more than what I wrote; that's what I meant with my _incipit_ "from a strict cryptographic point of view". – Halberdier May 09 '13 at 20:55
BEAST is not related to MtE and is due to known-IV with CBC (in SSL3 and TLS1.0) -- which SSH2 also does and did not correct, although it got CTR as an alternative before both it and TLS got AEAD = GCM (TLS also CCM) (and both ChaCha/Poly) as a better alternative. The MtE+CBC padding-based attacks are POODLE and Lucky13. – dave_thompson_085 May 30 '18 at 01:46
I have a solution that makes MAC-then-Encrypt safe for any cipher that has output size = input size and no weak data input into the cipher core. – Joshua Jun 24 '18 at 21:19
this answer is outdated as this is not what TLS does today. – David 天宇 Wong Nov 03 '19 at 22:20

score 3 · Answer 4 · answered Jun 15 '15 at 21:25

I think there is one aspect of this comparison that was overlooked. user185 came close but didn't quite get there. I agree that these are apples and oranges and feel a better apples to apples comparison to be HTTPS and SSH. HTTPS and SSH utilize different layers of the OSI model and therefore encrypt the data at different times in the transmission. Then the real questions one should be asking would be along the lines of when is this data encrypted and unencrypted during the transmission. This will reveal your potential attack surfaces. With HTTPS, once the packet is received by a device in the destination network (Web Server, Border Router, load balancer, etc...)it is un-encrypted and spends the rest of its journey in plain text. Many would argue that this is not a big deal since the traffic is internal at this time, but if the payload contains sensitive data, it is being stored un-encrypted in the log files of every network device it passes through until it gets to its final destination. With SSH, typically, the destination device is specified and the transmission is encrypted until it reaches this device. There are ways of re-encrypting the HTTPS data but these are extra steps that most forget to take when implementing an HTTPS solution in their environment.

score 1 · Answer 5 · answered Jan 19 '15 at 15:17

1

ssh is like a key (private) and the lock (public)

ssl is like the door and the bricks.

ssl provides a secure link between the two computer servers. eg, Yours and the one your connecting to.

ssh is how the connecting computer can verify itself and gain access.

answered Jan 19 '15 at 15:17

datsusarachris

35
1

You do not explain the "door and bricks" comment at all. SSL also have public and private keys. SSL can also be used for client authentication. SSH also provides a secure link between the client and the server. – schroeder Jul 01 '20 at 10:06

score 0 · Answer 6 · answered Aug 04 '14 at 22:52

SSL is a protocol layer that is abstracted from the content being tunneled. SSH is a secure version of shell (SH), it was not designed to contain an abstract layer underneath it, it was designed specifically to carry shell traffic. So though crypto operations are used in both, and those crypto operations could even be the same, the purpose, and therefor overall design is quite different.

Keep in mind there are specific differences (as have been cited above), but most if not all of those differences are rooted in the purpose of the different protocols.

-1 You incorrectly make the assumption that OP is comparing SSL to the unix program [ssh(1)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/slogin.1). SSH is actually another protocol providing transport layer security, which happens to have special provisions for remote shells and remote execution. — jpillora, Jan 11 '15 at 15:47

score -1 · Answer 7 · edited May 29 '18 at 14:12

-1

If you really looking for SSH vs SSL(TLS) then the answer is SSH.

For one reason why SSH wins over SSL is the way it performs Authentication. Because of this reason when using FTP use SSH protocol (SFTP) rather then FTPS (FTP over SSL).

SSH is used in corporate networks for:

providing secure access for users and automated processes

interactive and automated file transfers

issuing remote commands

source: https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol

edited May 29 '18 at 14:12

schroeder

123,438
55
284
319

answered Jan 04 '18 at 15:23

Deep

99
2

1

"For one reason SSH wins over SSL is the way it performs Authentication" Do you have a source or explanation for this assertion? – AndrolGenhald Jan 04 '18 at 16:29
In SSH one have two options to connect the server. With key-based authentication option, one will first need to generate a SSH private key and public key beforehand. Which is not much of additional work. This is also consider best security practices. SSL has so many version the latest is TLS1.2. Which means it's not yet that secure, but in process to be getting better. – Deep Jan 07 '18 at 01:35
TLS has client-side certificates, too. You do not explain why SSH "wins". – schroeder May 29 '18 at 14:13
If you are going to copy/paste from somewhere, make sure that you cite your source. – schroeder May 29 '18 at 14:14
"SSL has so many versions" So, 6 versions is "so many"? OpenSSH is on version 7.7. "Which means it's not yet that secure, but in process to be getting better." Your logic makes no sense here. – schroeder May 29 '18 at 14:18
I can use TLS and a REST API to accomplish everything on your list, and in fact, that is the way many admin functions are now being handled. – schroeder May 29 '18 at 15:01

score -1 · Answer 8 · edited Jul 01 '20 at 10:07

The problem is two-fold, it's not just the strength and weakness of the encryption. But it's the ease and convenience of the delivery. So from business perspective SSL/TLS is is more convenient and easier because it just requires a browser and either a public or private Cert.

And SSH requires either the application or thin client installed to use it. That is more of a problem from a user Internet client perspective and support.

What is the difference between SSL vs SSH? Which is more secure?

8 Answers8

Linked