Caddy: Consider removing support for insecure SSL3 and cipher suites

[igorwwwwwwwwwwwwwwwwwwww]

When reading this page: https://caddyserver.com/docs/tls the following jumped out at me:

The following protocols are supported, in descending order of preference:

• ssl3.0 Note: SSL 3.0 is insecure and should not be used.

and

Note: The HTTP/2 spec blacklists over 275 cipher suites for security reasons. Unless you know what you're doing, it's best to accept the default cipher suite settings.

If they are insecure, why are these options even available? Could it make sense to simply not support those settings, or make it difficult to enable them?

[wmark]

_Caddy_ could be used on a local development machine, with legacy software, where security wouldn't matter. (Yet you would enable TLS or else HTTP/2 will not work with Chrome.)

The default minimum protocol version is TLSv1.0 anyway:
https://github.com/mholt/caddy/blob/ddf4b1fd3b0d7c20514dc2c71cd4fbab044aa8e7/caddy/https/setup.go#L261-L263

The HTTP/2 spec merely _suggests_ to exclude some cipher suites. Not all of them are insecure per se! This struck me (and still does) as political decision (»because we can«) to introduce a reason to discourage deployment of those cipher suites. (Some, like AES+CBC, have been repeatedly found to have flawed implementations and are considered hard to implement.) This has highly controversial implications, like for example the preferred use of AES+GCM over *CBC.

[mholt]

I expect SSLv3 support to be removed entirely from Caddy by version 0.9, and if not (because of high demand for backward insecurity), definitely by version 1.0, no exceptions. Thanks for the question!