2

Pre-Shared Key (PSK) with simple symmetric encryption is a popular way of solving both client and server authentication when SSL cannot be used for some reason (for example, can't trust or deal with certificate management, or even SSL not supported on the server). And PSK has the advantage of not requiring a complex negotiation protocol. So how can a website use PSK for connection security?

It appears that browsers do not have built-in PSK. Going through an SSH tunnel may not be an option either (first, the SSH server fingerprint is harder to remember than a user-generated PSK password; second, SSH tunnels do not solve Chrome's unsettling warnings about plain HTTP; and third, the server might not support SSH).

So, is there some generic browser add-on that prompts for URL + PSK, and visits any (PSK-enabled) site using PSK encryption? "Browser add-on" could be pretty much anything. (For example, a script loaded via file:// that establishes a secure PSK connection inside a cross-site WebSocket, patches all resource-loading methods in JavaScript to PSK versions, and, finally, securely loads and executes the top javascript file.)

If not, please provide possible reasons why such a feature is not standardized.

personal_cloud
  • 389
  • 1
  • 8

3 Answers3

3

So, is there some generic browser add-on that prompts for URL + PSK, and visits any site using PSK encryption?

To achieve such end-to-end protection changes would need to be done to the way how client and server communicate with each other. In order to implement such changes on the communication protocol there would need to be changes both on the client and on the server side.

Therefore there cannot be a solution which end-to-end protects communication with arbitrary web sites, but which is client-side only (like browser add-on, proxy...).

If it is about accessing a site which is somehow already PSK enabled (I'm not aware of major web servers supporting such thing), then a local HTTP proxy could be implemented to provide such functionality. It would speak to the server with PSK and to the client with HTTPS, using certificates created dynamically by its own CA which has to be added as trusted to the browser so that the browser throws no warnings.

If not, please provide possible reasons why such a feature is not standardized.

Using PSK has the same problem as self-signed certificates: it does not scale. Like with self-signed certificates, pre-shared keys would require a mechanism to somehow distribute the shared keys using some trusted mechanism, before a trustable connection with the peer could be established. And a mechanism for revocation of shared keys too in case these got compromised would be required too.

Using PSK based authentication on scale is actually not simpler than certificate based authentication with trusted CA. There need to be some mechanism for handling the trust relationships (i.e. distributing shared keys on scale). PSK presumes such mechanism but does not define it, whereas certificate based authentication actually defines and implements it.

In addition PSK would either require a separate shared secret between each user and the website - which means many many secrets to maintain on the server site. Or it would require the secret to be shared between all users of the site, which could then not be called a secret anymore.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • Yes, I'm assuming you'd need new software on the server as well. Hopefully something that mostly wraps around existing HTTP servers. – personal_cloud Dec 03 '22 at 22:58
  • "PSK would either require a separate shared secret between each user and the website" which we already have (in the form of passwords). – personal_cloud Dec 05 '22 at 01:30
  • "Using PSK based authentication on scale is actually not simpler than certificate based authentication with trusted CA." Actually PSK can be extremely simple: set up the device on a secure network, then move the device (or the client) off the secure network and continue using it. Anything involving a CA is going to be more complex and not scale as well. The only way SSL can compete is with self-signed certificates. – personal_cloud Dec 05 '22 at 01:34
  • @personal_cloud: What you described is different to what I described. You described a single instance of a server with a single user - in which case the secret has only two be shared between two parties. I've explicitly said "on scale", i.e. many web sites and many users - in which the complexity of securely sharing the secrets rapidly impacts scale. – Steffen Ullrich Dec 05 '22 at 06:22
  • @personal_cloud: *""PSK would either require a separate shared secret between each user and the website" which we already have (in the form of passwords)."* - You again presume that there exists some mechanism of setting up the websites with a shared password. But how do these sites gets the password in the first place? How would this mechanism scale to millions of sites and millions of users? – Steffen Ullrich Dec 05 '22 at 07:29
  • "You described a single instance of a server with a single user". Right. And it scales because it does not rely on 3rd parties. If you have a million users each owning their own server, maybe sharing access to a few other users, we don't need 3rd parties. On the other hand with SSL (without self-signed certificates), once you get that big, you start getting things like rogue root CAs that you have to police. – personal_cloud Dec 06 '22 at 22:02
  • "But how do these sites gets the password in the first place?" The IoT device has to be initially configured over a secure connection anyway (e.g. so it can connect to your wireless network). – personal_cloud Dec 06 '22 at 22:03
  • "then a local HTTP proxy could be implemented to provide such functionality. It would speak to the server with PSK and to the client with HTTPS" Is that already a standard? If not, then wouldn't it be preferable for the browser to directly talk to the PSK server (for example, in the question I suggested this could be done over a cross-site websocket. The client script just needs to include the block cipher). – personal_cloud Dec 06 '22 at 22:11
  • 1
    @personal_cloud: *"__The IoT device__ has to be initially configured over a secure connection anyway (e.g. so it can connect to your wireless network)"* - thanks for coming up with a specific use case this late in the discussion. Note that you generically asked for "website" in your original question - not IoT device. So your use case seems to be limited to pre-configured devices with only a few users each, which is very different from using PSK to access an arbitrary website. – Steffen Ullrich Dec 07 '22 at 04:52
1

TLS is widely adopted because of all the known reasons:

  • well established protocol that has stood the test of time
  • uses asymmetric cryptography for key management and distribution
  • provides (server or mutual) authentication
  • provides forward secrecy
  • etc.

All those reasons, and more, are well known and understood. So, it's safe to say that due to the wide adoption of TLS on the web, (web) servers opt to support it over any other non-mainstream solution (the IoT world may change that - it remains to be seen).

Having said that, there's the solution to use TLS-PSK, which essentially uses ciphers with pre-shared keys (note that there's some differences between TLSv1.2 and v1.3). I'm not sure how common it is, though, so finding documentation on how to use it in your case may prove to be difficult.

Spyros
  • 1,451
  • 1
  • 14
  • TLS-PSK looks promising, as (according to the Wikipedia article you linked) it would support simple symmetric-key authentication. Unfortunately it also appears that browsers don't support it yet. – personal_cloud Dec 06 '22 at 22:15
  • @personal_cloud there are conceptually similar solutions, like [SRP](http://srp.stanford.edu/), [TLS-SRP](https://www.rfc-editor.org/rfc/rfc5054) and [OPAQUE](https://eprint.iacr.org/2018/163.pdf) that all fall under the [PAKE](https://en.wikipedia.org/wiki/Password-authenticated_key_agreement) protocol umbrella. However, I haven't found any documentation of browsers supporing any of them, even though there is support for some of them by crypto libraries (e.g. [openssl](https://matthewarcus.wordpress.com/2014/05/10/srp-in-openssl/)) – Spyros Dec 07 '22 at 06:59
0

A PSK-secured website does not make much sense, it's difficult to create and maintain, and does not add any security over what TLS already have. PSK on a server-to-server communication is viable and easily done, but PSK involving user entering data over a plain HTTP connection is not.

If you have a server so resource constrained that you cannot run TLS on it, it cannot be called a server. Even single board modules like ESP8266 have TLS support. Someone even managed to run TLS over HTTP (so no proper HTTPS, but quite close) on an Arduino. So "limited server that does not support TLS" isn't a likely scenario.

If SSL cannot be trusted, there's little left that can be trusted. Certificate management is not trivial, but managing any server that is important enough to have some kind of security is more difficult than that. So it's not a likely scenario either.

If you don't have TLS, PSK does not make sense. Any attacker on the path could read the packets on the wire to get the PSK, or inject a script to get the PSK on the page and send to him, or redirect the user to a site he controls and ask the PSK there. Without TLS protecting the connection, the user cannot tell the attack is taking place (except the last one).

If you do have TLS, PSK is not needed. I would trust more a TLS connection that uses a library that is trusted for decades by banks, government and military more than any plugin, script or extension someone wrote.

One scenario that is possible, plausible and likely is when the user is behind a TLS Termination Proxy. In those cases, the TLS connection is not entirely under user and server control, and there's a server in the middle between the two. In those cases, the proxy can read everything and alter everything on the connection. If this proxy is hostile, TLS cannot be trusted.

But in this scenario, PSK over this connection cannot be trusted either. The proxy is in position and have the capabilities to inspect and alter any packet, so it could inject a token stealing script, could record the token after being entered, or could inject a script to ask for the token on any site.

ThoriumBR
  • 51,983
  • 13
  • 131
  • 149
  • "If you don't have TLS, PSK does not make sense. Any attacker on the path could read the packets on the wire to get the PSK," Well that's quite a strawman -- of course you wouldn't send the PSK itself over the plain connection. The PSK is shared in advance or over a secure side channel. Refer to the link in the question for the basic premise. – personal_cloud Dec 05 '22 at 01:19
  • "Even single board modules like ESP8266 have TLS support" Yes and it consumes 75% of the device's RAM. – personal_cloud Dec 05 '22 at 01:22
  • "PSK on a server-to-server communication is viable and easily done, but PSK involving user entering data over a plain HTTP connection is not." Perhaps not "easily done", but the complexity is in patching JavaScript fetching functions to use the secure versions. But the end result could well be easier for the user than the current process of loading a new certificate into a browser. – personal_cloud Dec 05 '22 at 01:25
  • @personal_cloud: *"the current process of loading a new certificate into a browser"* - the current process does not involve loading a certificate into the browser. For public sites or company sites (with trusted private PKI) the browser trusts these already - nothing to be done. For systems which are not part of some trusted PKI (self-signed certificates) the user gets a warning in the browser and simply mark this specific certificate as trusted for this specific domain. The browser remembers this decision for the future and there is no explicit certificate installation involved. – Steffen Ullrich Dec 05 '22 at 07:33
  • @personal_cloud if enabling TLS takes too much RAM on your server, you should get a better server. – ThoriumBR Dec 05 '22 at 10:13
  • @ThoriumBR " if enabling TLS takes too much RAM on your server, you should get a better server." Right, that's an assumption that SSL makes, and one of many reasons why it's not currently suitable for simple IoT devices. – personal_cloud Dec 06 '22 at 22:05
  • "I would trust more a TLS connection that uses a library that is trusted for decades by banks, government and military more than any plugin, script or extension someone wrote." Sometimes. But would you trust TLS if provided by a company that does not have full-time PKI staff? At least with a file:// script, I know that any attacks are limited to my interaction with it. It can't do anything to hijack my bank's URL. Unlike a (potentially misconfigured) root certificate added to my browser. I can't imagine that that many people know how to verify the Subject chain, if Python itself got it wrong. – personal_cloud Dec 06 '22 at 22:19
  • If you somehow allow `file://` you open a nice can of worms, allowing scripts to escape the sandbox e potentially read data from your user's computer. – ThoriumBR Dec 06 '22 at 23:53