-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
Comments
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 |
Sorry, the last change in this thread is 2015, but anyway :-) |
/cc @agl for advice |
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. |
Go 1.9 is frozen, but I'll let @agl decide for Go 1.10. |
You can find my fork with PSK support here: |
@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. |
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. |
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. |
@FiloSottile -- can you elaborate on this? It seems like discussion on this topic halted over the holidays... |
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.
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... |
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. |
Since in TLS 1.3 PSKs are merged with resumption, what would help here is an actual proposal of how an API that allows applications to inject PSKs through the same mechanism used to store session tickets/IDs would look like. A good API would probably solve in one shot this, #25351, #25228 and #19199. (And #46718 and #57753.)
For the record, the maintainers of this package care about not having it fully featured. crypto/tls implements a useful subset of the TLS protocol, it's how it stayed secure and maintainable for 10 years. |
Looks like https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-05 is going to get published, so we might want to just jump ahead to its Importer API, and provide a way to import an external PSK into the session store through that mechanism. Note that we are not going to support ECDH-less PSK modes, as they don't provide per-connection PFS. |
@gdamore Go does have pion/dtls and it supports Certifitates and Pre-shared Keys. If it is missing any features that stop you from using it would love to hear! Sorry to de-rail this ticket. I was looking around Also if anyone is interested I would totally be up for giving up ownership to the Go team! #13525 (comment) the code base is drastically different though. I wrote it to be more verbose/readable, things like each handshake message being their own struct |
Thanks @Sean-Der -- I will look later.. I don't have an immediate need for DTLS, but its probably something I need to think about soon. |
Change https://go.dev/cl/415034 mentions this issue: |
Anyone cite a plain PSK client-server sample? i'm using the rc candidate version
and trying to create a simple TLS client server with just PSK alone and i'm unsure how to construct the the best i could get is sstate := &tls.SessionState{
Extra: [][]byte{[]byte("client1")},
//secret: []byte(combinedKey),
}
tlsConfig := &tls.Config{
GetConfigForClient: func(ci *tls.ClientHelloInfo) (*tls.Config, error) {
return &tls.Config{
MinVersion: tls.VersionTLS13,
WrapSession: func(cs tls.ConnectionState, ss *tls.SessionState) ([]byte, error) {
// todo encrypt
return sstate.Bytes()
},
UnwrapSession: func(identity []byte, cs tls.ConnectionState) (*tls.SessionState, error) {
b, err := sstate.Bytes()
// todo decrypt
if err != nil {
return nil, err
}
return tls.ParseSessionState(b)
},
}, nil
},
} but don't know how to specify the 'secret' (i think you're supposed to encode the PSK secret into the sessionstate which gets wrapped unwrapped) for ref, with nodejs and PSK, you can "just set" the secret via tls pskCallback |
If you look at the code there is a mention of an "extra master secret" (it ends up being a 0 for non-secret and 1 for secret). Again, I didn't try, just a wild guess :) |
@raff unfotunately, that didn't work. @FiloSottile is it possible to directly inject a PSK or is the implementaion for go1.21 using PSK internally for other usecases and not surfaced to users? (i suspect thats the case) |
Hey guys, any update on this? |
i looked at this a bit more and i don't think this feature allows for user-supplied PSK like stunnel, openssl ( I think its used for (i also noticed this bit seems to show all tls in go needs certs here which isn't needed for user-specified psk @FiloSottile if the above is confirmed, that'll clarify what we can use this capability in go for. thanks |
another use case for PSK TLS support is that it is quantum safe, compares to normal TLS using diffi-hellman and PKI; I know NIST/IETF are working on standardizing new PQC alg. for key exchange and pki, but it will take while, even longer for widely adoption, so it would be nice to have PSK TLS support before that |
Over 10 years later... and still no action. There are numerous use cases where an out of band key synchronization is far easier. For example, imagine a remote device setup (like a drone) where you can pair using USB keys or even using a charging cable. This is simpler, easier to get right in implementation, and can be done on much lower end hardware than full up key exchange would allow. It's also as pointed out, Quantum Safe. Please also recognize while the device might have a minimal C version (again because embedded), the peer might have a lot more resources and be written in Go. But the constraint here is not the Go side, it's the tiny embedded side. I completely understand the desire for an easily maintained, minimalist, library especially where security is concerned. But the failure of the maintainers of this package to consider PSK use cases represents an extraordinarily myopic view -- TLS is for more than just web browsers connecting to servers! Numerous parties have offered to contribute solutions, and have in fact provided code to do this. I could do it as well. But without someone from the maintainership taking it on, it's dead in the water. What will it take to convince the maintainers that this is a critical capability gap? |
I've been asked to solve this problem for Mangos (my NNG/nanomsg compatible API.) I would really like to not have to abandon the standard library. Again, real use cases. In the meantime I will tell my users to use the C version of NNG and avoid Go, and point them at this issue. |
Zabbix Agent 2 for the famous Zabbix Monitoring Server is using CGO and some Code from OpenSSL to allow using TLS-PSK: https://github.com/zabbix/zabbix/blob/39c05453954c1182076677439392f27b8ae0b055/src/go/pkg/tls/tls.go Maybe not their wisest decision to use Go for their new Agent. But I guess we've jet another use case. |
by tiebingzhang:
The text was updated successfully, but these errors were encountered: