Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/tls: add PSK support #6379

Open
gopherbot opened this issue Sep 13, 2013 · 26 comments
Open

crypto/tls: add PSK support #6379

gopherbot opened this issue Sep 13, 2013 · 26 comments

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 13, 2013

by tiebingzhang:

RFC 4279 (http://tools.ietf.org/html/rfc4279#page-10) added PSK to TLS.
OpenSSL and GnuTLS already have support for it.

The RFC defines three additional key exchange algorithms:
PSK
RSA-PSK
DHE-PSK

It would be nice to add at least PSK and DHE-PSK to GO's crypto/tls package. The work
seems to be reasonable size.

According to Wikipedia
(http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_Exchange_Algorithms_.28Alternative_key-exchanges.29),
RSA-PSK has not been implemented by any of the listed implementations, so it is maybe
okay to push that one off for later.
@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Oct 18, 2013

Comment 1:

For now at least, very low priority.

Labels changed: added priority-someday, removed priority-triage.

Status changed to Accepted.

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Nov 27, 2013

Comment 2:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 3:

Labels changed: added release-none, removed go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 4:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@tchap

This comment has been minimized.

Copy link

@tchap tchap commented Feb 17, 2017

Might be a good idea to revisit this. I am interested in IoT and some devices simply cannot do regular TLS. Having a solid implementation of TLS-PSK would enable people to use Go to implement a server communicating with a swarm of IoT devices. I am not so much into crypto to be able to implement this myself. Basically just saying that IoT is on hype today and the last comment in this thread is more than 3 years old. For someone knowing crypto and crypto/tls it seems that this would not be too much work...

@tchap

This comment has been minimized.

Copy link

@tchap tchap commented Feb 17, 2017

Sorry, the last change in this thread is 2015, but anyway :-)

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Feb 17, 2017

/cc @agl for advice

@agl

This comment has been minimized.

Copy link
Contributor

@agl agl commented Feb 17, 2017

My feeling is that this is fairly obscure and that we (by which I mean "I") should focus on TLS 1.3 support in crypto/tls, at least in the 1.9 cycle.

@mordyovits

This comment has been minimized.

Copy link

@mordyovits mordyovits commented May 18, 2017

@agl @rsc @tchap I have implemented the PSK and DHE_PSK ciphers (server and client). Is there interest in merging code for this? It required removing assumptions about there always being a server cert, so it's not totally trivial.

@bradfitz bradfitz modified the milestones: Go1.10, Unplanned May 18, 2017
@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented May 18, 2017

Go 1.9 is frozen, but I'll let @agl decide for Go 1.10.

@mordyovits

This comment has been minimized.

Copy link

@mordyovits mordyovits commented Jun 6, 2017

You can find my fork with PSK support here:
https://github.com/mordyovits/golang-crypto-tls

@EdSchouten

This comment has been minimized.

Copy link

@EdSchouten EdSchouten commented Apr 4, 2018

TLS-PSK would be quite a nifty tool for securing Paxos/Raft-based systems without the need for complex certificate management.

@tommie

This comment has been minimized.

Copy link

@tommie tommie commented Apr 4, 2018

I have a hopefully mergeable version in https://github.com/tommie/go/tree/tls-psk. It's a bit behind master by now, but seems fine.

I need to go over it one more time to double-check sanity there. There are some assumptions about certificate fields being set in the current code, and my patch needs to wrap those in if-statements, making it a bit scary. I also only cared about relatively modern PSK cihper suites.

If there is interest, I can push forward with that. I just haven't had the time lately. OTOH golang/go allows GitHub pull requests now, so that's nice. :)

@agl agl added the Proposal-Crypto label Apr 26, 2018
@golang golang deleted a comment from hexfusion Apr 26, 2018
@bradfitz bradfitz modified the milestones: Go1.11, Unplanned Jun 6, 2018
@golang golang deleted a comment from ddljdd Dec 12, 2019
@jvmatl

This comment has been minimized.

Copy link

@jvmatl jvmatl commented Dec 15, 2019

It would seem we are a lot closer to external PSK support with TLS 1.3, but as far as I can tell, the existing TLS stack only supports PSKs in the context of session resumption. I'm not a TLS expert, but I think the only things missing now would be:

(a) an interface to getKey/getIdentity on client and server side (I like what Raffael Sena did here https://github.com/raff/tls-psk -- this is my current "solution") and
(b) support for the (pskModePlain) Key Exchange mode on the client and server.

I know that PSKs are not 'cool' -- but the whole world is not a web browser! There are places where PSKs still make a lot more sense than certificate-handling: @EdSchouten, above has one use case for etcd. - In my case, I have a network of many, many highly constrained IoT devices (constrained in both code space and battery power) that need to talk to a Golang backend; I can't afford the code space or CPU time for asymmetric crypto or elliptic curves, but pre-provisioning AES keys at the factory is easy.

So currently my options are to use a forked crypto/tls (suboptimal, because of the tight coupling between crypto/tls and net/http, and with each version of Go the fork gets more out of date,) or switch to a CGo wrapper around WolfSSL or mbedTLS or {shudder} OpenSSL, with all the fun and performance benefits of CGo...

I had put off making the switch because I had thought if I could hold out until TLS13 in Go the PSK support I needed would be built-in... but alas no.

At this point, there are at least three people (Raff, above, @tommie , and @mordyovits ) who thought having external PSK functionality was useful enough that they went ahead and forked crypto/tls themselves to implement it. And I have to assume the number of people who are qualified to do that are pretty small, so the fact that three did suggests to me that there are many others who would do it if they felt comfortable doing so. Please consider taking the last step and making this use case supported by Go out-of-the-box...

@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Dec 16, 2019

It is indeed pretty easy to add PSK support in TLS 1.3. (Or at least everything but the actually hard part of picking an API for it.) The problem is that with static RSA cipher suites hopefully on their way out, we are close to getting to a sane place where all crypto/tls connections have forward secrecy.

Would ECDH+PSK actually satisfy anyone's use cases? Because pure PSK doesn't have forward secrecy and I am extremely reluctant to add that.

Next it's a matter of how many people need this. Judging from the popularity of the forks, it doesn't look like a very widespread need, and crypto/tls is in a constant fight against the wide scope of TLS to manage complexity.

Finally, now that modules are here it's actually pretty easy to replace crypto/tls by using the vendor folder, without having to fork net/http or replace the whole GOROOT. I should probably write that up.

@jvmatl

This comment has been minimized.

Copy link

@jvmatl jvmatl commented Dec 17, 2019

Well, I can't speak for everybody, but in my case, forward secrecy is not important to me because we have a mechanism to rotate the PSKs outside the context of TLS. (Also, because in an IoT sensor network, the ability to go back and decode old sensor data is of limited value.) I can certainly understand why we might not want to enable TLS modes that don't provide forward secrecy by default, but enough people thought there was a valid use case for plain to include it in the TLS1.3 spec despite the lack of forward secrecy, so I can't be the only one who would use it if it were available.

I realize I'm in the minority, but I work with tiny embedded devices for which every kilobyte of code space is precious, and every single byte sent over a network costs me battery life. So, rather than have a 'dummyproof' TLS stack with PFS, I would much rather have one that lets me make the security tradeoffs that make sense for my problem space.

All that said, if this change never makes it into the std library, I would love a writeup explaining how to handle vendoring crypto/tls. And if any kind soul wants to provide some unofficial code with the 'easy' changes to handle plain external PSKs, I wouldn't turn my nose up at that, either. ;)

@tommie

This comment has been minimized.

Copy link

@tommie tommie commented Dec 17, 2019

I agree with John. My specific usecase was using the ESP8266 embedded computing modules, and trying to avoid rolling my own crypto. The benefit of ESP8266 is an extremely cheap WiFi enabled module, but it has limited computational power (and no hardware support for cryptography). It's normally running at 40 MHz, but the vendor's SSL library boosts it to 80 MHz during RSA computations... 1,536 bits is barely doable, and at 2,048 bits the watchdog timer usually resets the device.

And so, I didn't feel the RSA support was worth using. AES is fine, and as @jvmatl mentioned, pre-provisioning per-device symmetric keys is often fine for embedded devices.

I think it's important to have something that allows even the smallest of devices to run encryption, and ECDH/RSA/EC is too slow to be really practical. I completely agree it should be harder to enable PSK than forward-secrecy mechanisms, there is certainly a risk that making it difficult to use TLS at all for some devices leads us to a "roll-your-own" situation that benefits no-one in the end.

Finally, I'd like to mention that Mosh is another great example of a situation where PSK works. They have a pre-authenticated channel over SSH, but need to switch to UDP. So they simply send a symmetric key. (They're of course not using TLS, due to UDP.)

@rmspeers

This comment has been minimized.

Copy link

@rmspeers rmspeers commented Dec 17, 2019

I had been watching this thread for a while but noticed today there was some discussion happening on it. I work consulting on cryptography (and other items) with a number of companies in the embedded IoT space, and it is very common that we have to figure out a transport encryption solution that works with their embedded constraints. It looks like @jvmatl above has mentioned some of those cases -- limited code size and battery life. In some cases, our code size is more constrained than the chip as for security purposes (among others) we want to be able to bank memory to be able to safely update in the field -- meaning our code size is cut in half. Regardless of how it happens -- code size and battery usage are real-world constraints and it would be great to use TLS rather than roll-their-own. The movement to use a supported TLS implementation in my opinion would add security benefit to people implementing transport encryption -- and allow them to go directly to their Go backends (if they use Go, which we have seen movement on a few of our customers to want to use) rather than having a proxy to decrypt between the IP connection and the backend.

@tommie

This comment has been minimized.

Copy link

@tommie tommie commented Dec 17, 2019

@rmspeers For battery-constrained devices where you wouldn't want to wake up just to send a TCP keep-alive (or similar), wouldn't a more datagram-friendly layer like DTLS be preferred?

My ESP8266 use-case was just a hobby project, so I didn't have any hard constraints to work with. I wanted PSK in TLS because the ESP8266 standard library implements that, so I could have faster turn-around. Does this apply to other devices, or would it make more sense to add PSK in e.g. crypto/dtls specifically for these?

@jvmatl

This comment has been minimized.

Copy link

@jvmatl jvmatl commented Dec 17, 2019

@FiloSottile - you said

It is indeed pretty easy to add PSK support in TLS 1.3. (Or at least everything but the actually hard part of picking an API for it.)

-- What do you think about what Raff did as a starting point for discussion? (https://github.com/raff/tls-psk/blob/tls13/psk.go#L44)

If we take that, and add a boolean to explicitly allow pskModePlain, wouldn't that address everybody's concerns? The server could (and should!) still prefer to use pskModeDHE if offered by the client, and so nobody would ever accidentally get a session without forward secrecy;

The only time a TLS1.3 session with a Go server would lack forward secrecy would be if:

  • The client and server have a shared PSK (can't happen by accident)
  • The client only offers only pskModePlain in the clientHello.pskModes
  • The server enables AllowPskModePlain in the tls config
package tls
type Config struct {
    ...
    // Configure the use of Pre-Shared external keys for use between
    // endpoints. This is typically only used in closed environments
    // where client and server can agree on keys out-of-band from TLS
    // and use of public/private keys is impractical. 
    PreSharedKeys PSKConfig
    ...
}

type PSKConfig struct {
    // Controls support for a PSK key exchange mode that is easier to
    // compute on very low-powered devices, but which does NOT offer
    // "Forward Secrecy". Enable only if you understand the security tradeoff.
    // (See `psk_ke` in RFC 8446, Section 4.2.9.)
    AllowPskModePlain bool

    // client-only - returns the client identity
    GetIdentity func() string

    // for server - returns the key associated to a client identity
    // for client - returns the key for this client
    GetKey func(identity string) ([]byte, error)
}


If the change to add external, plain PSK to TLS1.3 really is an easy one, and it's impossible for users to accidentally shoot themselves in the foot, and there are real-world use-cases for the feature where potentially millions of IoT devices get better transport security, isn't this a no-brainer?

@jvmatl

This comment has been minimized.

Copy link

@jvmatl jvmatl commented Dec 17, 2019

@tommie - in some contexts, yeah, DTLS with PSK would be preferred, but DTLS support in applications/frameworks is not nearly as widely available as TLS.

For example, the Eclipse Paho project (arguably the go-to project for people looking for open-source mqtt clients) has clients for MQTT-SN (which is explicitly designed for low-power sensor networks!) and they don't even support DTLS yet, let alone DTLS with PSK. (See eclipse/paho.mqtt-sn.embedded-c#90)

But if Go's official crypto were to add baked-in support for external PSKs in TLS1.3 support, you can bet that every single Golang-based MQTT, CoAP, and LWM2M project would find they had a bunch of users wanting to make use of that new capability.

@raff

This comment has been minimized.

Copy link

@raff raff commented Dec 17, 2019

I have just updated my "tls-ext" package to latest Go crypto/tls (from Go 1.13.4). See https://github.com/raff/tls-ext/tree/tls13

This is the minimum required for my PSK implementation (i.e. I have only exported methods/values needed to build my tls-psk package) so it's easy to compare with the original code.

Note that this version doesn't actually support TLS 1.3 for PSK (the TLS 1.3 path is still trying to pick a certificate, that doesn't exist). I wasn't sure of what cipher-suites to add and I don't have any tests or implementation to compare to. So for now it's really just an "update" to my original implementation.

@robmccoll

This comment has been minimized.

Copy link

@robmccoll robmccoll commented Dec 19, 2019

With these suggestions, adding PSK seems like a good choice.

The argument that it doesn't achieve PFS seems like perfect is the enemy of good. Encouraging forking the standard implementation and rolling your own PSK extension sounds more likely to lead to vulnerable code in the wild than having a PSK implementation in the standard library. Having it in the standard library leads to better testing, compatibility, and visibility over an external implementation. It would have to be explicitly enabled, so the security of default implementations isn't diminished.

@jvmatl

This comment has been minimized.

Copy link

@jvmatl jvmatl commented Jan 22, 2020

Finally, now that modules are here it's actually pretty easy to replace crypto/tls by using the vendor folder, without having to fork net/http or replace the whole GOROOT. I should probably write that up

@FiloSottile -- can you elaborate on this? It seems like discussion on this topic halted over the holidays...

@jvmatl

This comment has been minimized.

Copy link

@jvmatl jvmatl commented Feb 13, 2020

Now that I have gone further down my current path, the real cost of not having this in the standard library is growing geometrically; the downstream cost is much higher than just having to use an alternate TLS package in my own homegrown code. So just in case it's not clear, here is where I am at.

  • I cannot change the embedded platforms: there are literally millions of IoT endpoints already manufactured over the course of years, and even if some of them are upgradeable over-the-air (and many are not) -- they don't have the code space or computational power to use asymmetric crypto effectively.
  • If I want to develop a service that these devcies can connect to securely, I can (and am) using @raff's fork of the Go 1.13 crypto/tls. This is pretty straightforward
  • I wanted to run a third-party MQTT broker and have it listen for TLS-PSK connections. In order to do this, I am forced to fork the MQTT broker package to make the modifications required to let it use the new tls package, rather than simply modifying some entries in the broker config file's tls.Config. Once I have done that, I have added the indefinite maintenance burden of keeping my changes in sync with upstream (so I can continue to receive new features/bugfixes)
  • Next, I wanted to be able to run load-testing and integration tests with simulated clients written in Go. But in order to do that, I had to fork the Eclipse Paho mqtt client package o use the new tls. Again, I now have the maintenance burden of keeping that fork in sync with upstream, all because I couldn't add psk-tls functionality in a config file.

From where I'm sitting, this ever-growing spiral of forked code is unmanageable - so at some point I will probably bite the bullet and fork the builtin library itself, because at least that maintenance cost is a constant, but given the complexity of TLS implementation, I am less confident that I will always get this right.

None of this would be necessary if the TLS1.3 stack were extended to include support for PSK connections - something we have already established is technically easy to do, at least according to @FiloSottile.

(*) before somebody points out that getting tls-psk in TLS1.3 does not help me with my embedded clients, that's sort of true, but since I can write homegrown psk listeners relatively easily, I can deploy proxies that listen with the forked tls-psk and forward connections to my internal servers -- and over time, as the old devices retire, I can phase this monstrosity out of service. But if tls-psk never makes it into the standard library, the treadmill never ends...

@gdamore

This comment has been minimized.

Copy link

@gdamore gdamore commented Feb 28, 2020

Just for the record, I came here looking for something like this. PSK's might make my life easier. I have an already established secure channel (out of band) where I can exchange the PSKs securely, and discard them after I've used them. I don't need PFS in this context because I already have it by virtue of the fact I'm' using a secure channel (which does have PFS properties) to exchange these PSKs (which for my use would make them more like single use session keys.)

Notably earlier today I also came looking for DTLS support (for another but related reason).

It almost seems like the maintainers of this package kind of don't care about having it fully featured.

The failure to also have a FIPS 140-2 cert is also limiting.

I'm feeling like there is a business case in here somewhere.... probably an opportunity for someone to charge real $$ to provide a solution to these gaps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.