I'll add, too, that anyone who wants to try TLS 1.3 right now can do so with the latest source builds of the Caddy web server. We just merged support for TLS 1.3 a few minutes after the Go 1.12 release: https://github.com/mholt/caddy/pull/2399
If you have a domain name pointed at your machine:
$ caddy -host example.com
(Roughly equivalent to python -m SimpleHTTPServer but with HTTPS, and production-ready.)
crypto/tls is designed and developed to be fit to be exposed directly to the Internet. The advice I wrote here is mostly dated (I really need to write a follow-up), but it's still indicative: https://blog.gopheracademy.com/advent-2016/exposing-go-on-th...
[Updated to add] TLS 1.3 is opt-in because despite years of improvements, it can still hit compatibility issues with broken or legacy peers. (Search for "TLS 1.3" on the Go issue tracker if you are curious.)
0-RTT is blocked on figuring out good, safe APIs for it. I feel like I am 80% of the way there for servers (just have to figure out how to make it opt-in per http.Handler instead of opt-out), while for clients I have no idea how to fit resending in io.Writer.
> just have to figure out how to make it opt-in per http.Handler instead of opt-out
Hrmm, I can think of a few ways (assuming I'm understanding the problem). One is a ZeroRTTHandler iface w/ a single ServeHTTPZeroRTT function and if Server.Handler impls that iface in addition to Handler, then that function is called instead. Another way is just to have a ZeroRTTAllowed property in the Server struct of type "func(Request) bool" w/ nil as an assumption of false. If it has to be on the handler instead of on the server, do something similar to the context package and have a "func WithZeroRTT(h Handler, allowed func(Request) bool) Handler" that returns the new handler w/ the internal check. Just spitballing, I may not understand the problem (can't escape asterisks here, but Request is meant to be a ptr).
> for clients I have no idea how to fit resending in io.Writer
This is tougher (assuming I understand the problem). Maybe a TLS config or http.Request option that the entire byte slice of first write can be resent as a whole. The other option being a tls.Conn.ZeroRTTFirstWrite method that the http req's Write can use if a setting is present before falling back to regular write, I dunno.
I know and understand the philosophy behind limited exposure/customization of the handshake process. However, there is a lot of value in implementing TLS extensions, adding early data on client hello, etc. I saw [0] but didn't see any details. Is it possible/reasonable to extract some of the internals to /x/crypto/tls or similar? Or is it either too hard to maintain or is there just too much fear about misuse?
Most of it is that it's harder to come up with useful, safe, not overfitting APIs the deeper you go into internals. For example, registering extensions is rarely useful on its own as extensions are allowed to change literally anything else in the protocol, and without hooks for everything else you did not get much value.
But! Hearing about what people would like to do and then putting together an API if it makes sense is my job! So please do open an issue saying what you'd like to do but can't.
For example, I mean to extract Client Hello parsing and a capturing middleware net.Conn, as a lot of passive things can be implemented that way.
Is there any performance issue that we should be aware of when turning on TLS 1.3? Go's standard library has many assembly implementations (to leverage CPU special opcodes). What is the speed of the TLS 1.3 crypto stack in Go?
What's the plan for pairing based curves now that the Extended Tower Number Field Sieve has made BN256 unusable for many applications[1]? Do you plan on integrating BLS curves any time soon?
hehe I guess so. Was a bit shocked to read SSL is deprecated! Still had that on my "Things to learn about one day" list! ...Ah, I did get this error trying to curl something earlier today "error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version" - seems my computer hasn't heard of it either.
SSL and TLS are really the same protocol, except that newer versions are called TLS. Many software stacks still refer to both as SSL, but these days we only use TLS.
I'd be happy to answer any questions about it, or about the rest of the Go cryptography libraries!