What is the difference between SSL vs SSH? Which is more secure?
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 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, 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. 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*.
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.
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.
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.
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.
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.
@NicholasWilson "_SSH's design makes it acceptable in situations/security communities where SSL simply is not trusted_" such as...
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 :-)
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.
@NicholasWilson, Wow, so you are saying that **SSH's security beats SSL**? What about user185's answer below which states the complete oposite?
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).
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.
@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.
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.
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.
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).