3

Can HTTP be used with SSH ? If yes, why has it not been as popular as HTTP over SSL ?

  • 3
    The reverse question is equally interesting: why has SSH been more popular than telnet over SSL? – user253751 Nov 2 '15 at 6:17
  • 1
    IMHO ssh is something like telnet over SSL. SSH and HTTPS both use ssl as backend. – Silent-Bob Nov 2 '15 at 8:14
  • 1
    Is that accurate, @Silent-Bob? – voices Nov 2 '15 at 12:31
  • At least because it doesn't have PKI. – Smit Johnth Jul 18 '16 at 20:41
4

If we ignore all the cryptography involved in the Confidentiality and Integrity services that both of these services provide, the only main remaining difference between SSH and SSL are how they engage the concept of Authenticity. Authenticity is the process of confirming the other party of the communication is indeed who they say they are. Both protocols approach this differently.

SSL/TLS

SSL/TLS is primarily concerned with Server Authentication. The client in a SSL/TLS communication is rarely authenticated (at the SSL/TLS layer). For example, when you connect to your bank website over HTTPS, your browser receives a certificate from the bank which proves the bank's identity. BUT, you or your browser are never forced to provide a certificate to identify who the client is.

Your bank website will probably ask you for a username and password, but understand this is happening at the HTTP layer, and after the SSL/TLS negotiation has already completed. At the SSL/TLS layer, your Bank website has no idea who you are.

Additionally, in the traditional mode of operation for SSL/TLS is the concept of Chain of Trust. Namely, when you receive a certificate from a Server, you only trust it because some other entity vouches for the validity of said certificate. This "other entity" is known as a Certificate Authority (CA). If not for the CA, the Client has no way to really know whether the other party in the communication is who they say they are.

SSH

SSH, on the other hand, is more concerned about Client Authentication, but provides some measure of Server Authentication as well, but not the same way that SSL/TLS does.

When you connect to a server using SSH, the server requires the Client to provide a username and password (or an SSH Key) to identify whether the client has access to the particular server. This process is built into SSH itself.

Once connected, the Server gives you an RSA identity signature, which your client can store locally as a sort of fingerprint for said server, so that in the future when the Client is connecting to the Server, he can validate the signature to ensure he is definitely connecting to the same Server he originally connected to.

Notice the difference, however. In SSH, you can connect to a server, and then ensure future connections are connected to the same server. But the real identity of that server is never truly proved. No third party entity vouched for the Server's identity. In fact, you only know you are connected to the right Server because of your own prior knowledge of what should be on the Server. Which is to say, when you SSH to a server, you know before hand that you should expect to see a certain set of files or software on the server.


In comparison, both of these models are best suited for the purposes that each provide.

SSL/TLS is best suited for a world where the Client can be anyone, but the Server's identity must be validated. In the World Wide Web, this is ideal, because you want anyone to be able to access your Web Server, and you want that "anyone" to feel safe in knowing that they are indeed connecting to the Server they mean to.

SSH is best suited for a world where the Server is known a priori, and the Client must be validated before providing access to the resource. From then on, all that matters to the Client is that they are always connecting to the same server they initially connected to.

This article is written from the perspective of the typical deployments of SSH and SSL/TLS. There are extensions to either protocol which allow for additional features, but they are rarely implemented. Namely, there is a method of SSL/TLS that also requires Client Authentication, known as Mutual Authentication. There is also a method of SSH that provides Certificate Authority validation.

| improve this answer | |
  • ... and ssh can be configured to not require a username and/or password. – Ricky Beam Nov 2 '15 at 22:41
  • @RickyBeam, Hrmm, I mentioned Key based (password-less) SSH in my response. Are you saying there is a method of SSH that requires no passwords and no SSH Keys? If so, can you provide a reference, I am unaware of that mode. – Eddie Nov 2 '15 at 23:08
  • 1
    Yes. Turn off PAM and tell it to run something other than login. While the client will supply a username, you can ignore it. – Ricky Beam Nov 2 '15 at 23:36
2

The purpose of TLS/SSL is to provide security (via key exchange, encryption, and digital signature) between two applications. As such, it is quite agnostic concerning the protocol used by these two applications to communicate. It is intended as a security layer to support pre-existing protocols.

On the other hand, SSH was conceived as a complete protocol to connect securely to a shell on a remote server and replace insecure protocols such as telnet, rlogin, rsh.

Although there are protocols (such as SCP) that run over SSH, TLS/SSL is more flexible, complete, and lightweight to be used as a security layer than SSH. It is also worth noting that HTTPS (i.e. HTTP over TLS/SSL) was invented in 1994, well one year before SSH.

| improve this answer | |

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