1

I'm looking for a way to authenticate clients/users at a web server with public/private key pairs and already read this question: Public key authentication or similar over HTTP/HTTPS? The answers are similiar to everything I found on the web. In short: "If you want public key authentication via HTTPS, use SSL client certificates".

However, I'm looking for a solution which is as simple and secure as SSH authentication with public/private keys. My problem with SSL client certificates is, that you need a CA and this makes a big difference from a security point of view, imho.

Here is why: If attackers steal your CA's private key, they are able to authenticate with any user, because they can sign their own client certificates. In the case of SSH, if attackers steal a user's private key, they can only authenticate as this single user.

So in conclusion I have to make sure that my CA is secured and the best way is to have a dedicated system / computer serving as CA. This means significantly higher effort and higher costs.

Considering security I think it's arguable which mechanism is better. But I think if public key authentication is sufficient for SSH access, it should also apply to web application authentication. Also notice, that I only want to use public/private key as an addition to my existing HTTP basic (user/password) authentication in order to increase security. Actually, my goal was to increase security by a second factor with minimal effort and without requiring the users to use token generators.

fishbone
  • 143
  • 6

1 Answers1

1

As the mutual authentication provided by the Transport Layer Security (TLS) still is the public key authentication for HTTPS (things hasn't changed since the other question was asked in 2011), there's no need for a SSH-like solution described here. Therefore, such a product/solution doesn't exists and you shouldn't develop your own. What applies to cryptography in general also applies to cryptographic authentication: you should not invent one by yourself, as it will be weak.

The problems you describe with implementing own CA aren't solved in the SSH public key authentication. If someone has access to the configuration, it's possible to add own keys and impersonate the user. Actually, CA based authentication is better, as it allows signing the certificates away from the application where they are used. The attack surface with a separated CA server (possibly completely offline) is considerably smaller. A client would leak the key (in both scenarios) a lot more likely than the CA would be compromised.

The costs aren't necessarily "significantly higher", as any old PC could work as an offline CA. Neither is it a matter of expensive software licenses, as e.g. GNU/Linux with OpenSSL CA is all you need.

Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
  • Never planned to invent an own solution, that's why I'm asking here. Yes I aggree of course that CA mechanism is better, but didn't want to discuss this here. That's why I said "If it's sufficient for SSH it should be for HTTP as well". You exactly mention the problems about public key auth I already had in my mind. But then I also should question this for SSH access. If someone has access to configuration then they simply could turn off CA auth or do what they want. I wonder why HTTP has a more secure mechansim than SSH, although intuitively I'd say that SSH needs better protection. – fishbone Jul 02 '20 at 09:07
  • SSH doesn't typically even have PKI that would authenticate the server. It's not a good example for the world supporting TLS, which already have better alternatives and is strongly based on PKI. – Esa Jokinen Jul 02 '20 at 09:15