Update Caddy to use Go 1.8

[mholt]

Go 1.8 introduces some nice improvements to the crypto packages and Caddy should begin using them. There are also some updates to net/http and other packages we should use.

Specifically:

• Manually-configured HTTP/2 server push (HTTP/2 push support plugin (golang 1.8) #1215)
• [-] Automatic HTTP/2 server push (@tdewolff is building https://github.com/tdewolff/push that we can probably use for this) (TODO: Deferring this, server push is a highly intricate dance)
• Use net/http.Server's graceful Shutdown method instead of our own gracefulListener (Replace our old faithful gracefulListener with Go 1.8's Shutdown() #1373)
• Eliminate race condition related to key rotation that was fixed in Go 1.8 (Set session ticket keys properly (fixed in Go 1.8) #1354)
• Use Config.Clone() instead of our own function, cloneTLSClientConfig, in reverseproxy.go (tls: Per-site TLS configs using GetClientConfig, including http2 switch #1389)
• Use Config.GetConfigForClient() to dynamically select a TLS config for the specific site being connected to, rather than having to reduce them all into a single TLS config in config.go:MakeTLSConfig. (tls: Per-site TLS configs using GetClientConfig, including http2 switch #1389)
• Use Config.VerifyPeerCertificate() to give site owner more control over authentication with client certificates. At least, I think that's what this would let us do. TLS client auth is a wonderful and too-underused technology. Let's help make it more popular. (See crypto/tls: add VerifyPeerCertificate to tls.Config golang/go#16363)
• Use new HTTP timeout fields: ReadHeaderTimeout and IdleTimeout (Set Go 1.8's ReadHeaderTimeout and IdleTimeout #1374)
• Add support for curve X25519. (Implement curve X25519 (Golang 1.8) #1376)
• Add support for ChaCha20-Poly1305 (Add support for ChaCha20-Poly1305 (Golang 1.8) #1443)
• Ensure ChaCha20-Poly1305 is prioritized unless there is hardware support for AES-GCM suites

I'm looking into server push next chance I get -- others are welcome to help contribute to the crypto changes.

[elcore]

@mholt

Add support for curve X25519 and ChaCha20-Poly1305. Ensure curve X25519 is prioritized if hardware has AES-GCM support, otherwise prefer a ChaCha20 suite.

You mean "Add support for curve X25519 and ChaCha20-Poly1305. Ensure AES-GCM is prioritized if hardware has AES-GCM support, otherwise prefer a ChaCha20 suite.", right?

"Basically" like my implementation here https://github.com/elcore/caddy

Use Config.GetConfigForClient() to dynamically select a TLS config for the specific site being connected to, rather than having to reduce them all into a single TLS config in config.go:MakeTLSConfig.

So, the user should not be able to configure the TLS Configuration, it should be dynamically configured???

P.S.: Just asking, I am so sorry, but I don´t have enough time to work on this new feature.

[mholt]

So, the user should not be able to configure the TLS Configuration, it should be dynamically configured???

No; the user can still configure TLS, but right now we have to combine all sites' tls directives to a single one (if they're all on the same listener) because there was no way to load a TLS config per handshake before. But now there will be.

[elcore]

No; the user can still configure TLS

Okay

[...] but right now we have to combine all sites' tls directives to a single one (if they're all on the same listener) because there was no way to load a TLS config per handshake before. [...]

I know 😄

Thank you for the clarification

[mholt]

@elcore In regards to:

You mean "Add support for curve X25519 and ChaCha20-Poly1305. Ensure AES-GCM is prioritized if hardware has AES-GCM support, otherwise prefer a ChaCha20 suite.", right?

Yes, sorry, I meant what the Go release notes say: "ChaCha20-Poly1305 is now prioritized unless hardware support for AES-GCM is present."

I updated my original post.

[wendigo]

Is it possible to modify .travis.yml to drop go1.7 and build only for 1.8 (so go1.8 builds will pass)?

[wendigo]

I've started working on (#1389):

• Use Config.Clone() instead of our own function, cloneTLSClientConfig, in reverseproxy.go
• Use Config.GetConfigForClient() to dynamically select a TLS config for the specific site being connected to, rather than having to reduce them all into a single TLS config in config.go:MakeTLSConfig

[mholt]

@wendigo

Is it possible to modify .travis.yml to drop go1.7 and build only for 1.8 (so go1.8 builds will pass)?

Yes! We'll drop support for Go 1.7 when Go 1.8 is released. Won't be long now.

And thank you for working on those :) That's super helpful.

[injust]

Now that go 1.8 has been released, any ETA on a version of Caddy built with it?

[mholt]

@injust Not yet, but hopefully soon!

[suedadam]

I'm down to help, where do you want help @mholt ?

[mholt]

@suedadam Thanks! We're almost done. How would you like to help with the VerifyPeerCertificate feature? Basically, this would allow a user to specify a specific TLS client certificate to allow through, rather than how it is now, which is any certificate signed by the specified CA. I'm not sure how involved this is, depends what you're up to. But that's the only thing on this list that is really remaining at this point.

I've already decided that we're going to hold off on auto-push for now, it's complicated.

None of the remaining TODO items will delay the release on April 20, so we're on track for that. 👍

[suedadam]

@mholt Seems relatively simple at first glance. Would you like me to append the functionality to "basicauth"? Haven't looked too much into the organization of this project so any pointers to where to start the creation and addition of it would help a ton

(I'll try and do most of it tonight)

[mholt]

@suedadam Not quite, this is at the transport layer, not the application layer. This belongs in the tls directive. Right now, we have the "clients" subdirective but it only lets you list entire CAs to accept certificates from. It should be changed so that you list specific client certificates to allow. (Does that make sense?)

[suedadam]

@mholt Gotcha, that makes perfect sense. Thanks!

[thibaultmeyer]

Use Config.VerifyPeerCertificate() to give site owner more control over authentication with client certificates. At least, I think that's what this would let us do. TLS client auth is a wonderful and too-underused technology. Let's help make it more popular. (See golang/go#16363)

Yeah, it could by nice to have access to, at least, that information :

• Result (useful in case of Client Auth is enabled but not mandatory) : “SUCCESS”, “FAILED:reason”, or “NONE”
• Client certificate Fingerprint
• Client subject DN
• Issuer subject DN
• Serial number of the client certificate

As variables, we can pass these data to the proxy via extra headers.

Related forum threads :

• https://caddy.community/t/ssl-mutual-authentication/1890
• https://caddy.community/t/tls-authentication-with-client-cert/1074

[mholt]

Okay, here's an elaboration of what needs to happen to finish TLS client authentication and close this issue:

Right now we can only verify client certificates based on issuing CA, but it would be nice to be able to authorize only specific client certificates based on their public key. This'll probably involve a slight change to the tls Caddyfile syntax:

tls {
     clients allowed_client_key1.pem allowed_client_key2.pem ...
}

and maybe we can read in all the keys in a bundle in a single file, and allow all of them:

tls {
    clients allowed_clients.pem
}

Do we want to continue supporting authorized CAs (current behavior)? If we do, then we should introduce a new tls subdirective called client_ca or something. /cc @carlisia

[zikes]

Would it be worthwhile to consider multiple clients subdirectives, such as with proxy upstream?

[mholt]

@zikes Yes, good point, my intent is that clients subdirective could be specified multiple times if there are many that won't fit on a single line.

[mholt]

This was all done long ago, except for adding improved support for verifying (accepting/rejecting) client certificates, and I think that can be done in a new issue if there's demand for it.