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.)

Or if you just want to try things out:

    $ caddy "tls self_signed"

I'm glad to see setting the env var in init() is enough to trigger this on - I'll be doing the same at $DAYJOB.

I was curious about new features in tls1.3 and this doc was a good breakdown

https://www.cloudflare.com/learning-resources/tls-1-3/

Any concerns exposing Go tls1.3 directly to the internet today?

Is 0-RTT on the roadmap for Go 1.13?

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?

0 - https://github.com/golang/go/issues/25807

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.

My use case recently was [0]. I might open an issue if that spec comes further along.

> I mean to extract Client Hello parsing

Something like that could have helped when I was toying w/ DTLS, though [1] did a great job on their impl.

0 - https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01#se... 1 - https://github.com/pions/dtls

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?

[1] see https://godoc.org/golang.org/x/crypto/bn256

How can we help with getting support for Ed25519 in crypto/x509 and crypto/tls?

OK thanks, basic question, but.. What is TLS?

The S in HTTPS. The technology that is securing your HTTP connections, but also used by other protocols.

https://en.wikipedia.org/wiki/Transport_Layer_Security

Oh ok.. thank you! (Somehow I'd never heard of that.)

Cool, that means that browser developers and web server developers are doing their jobs halfway right :)

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.

My understanding is that the renaming was mostly politics between Microsoft, Netscape, and the IETF in the 90s. See more details here: http://tim.dierks.org/2014/05/security-standards-and-name-ch...