Preferred curve order

[frenchvandal]

I guess this is not the most essential feature but I was wondering if Caddy can set the preferred elliptic curves in a specific order.

With the API in Caddy 2, we have the ability to custom the elliptic curves to support:

                    "tls_connection_policies": [
                        {
                            "alpn": [
                                "h2"
                            ],
                            "curves": [
                                "x25519",
                                "secp521r1",
                                "secp384r1",
                                "secp256r1"
                            ]
                        }
                    ]

When I check my TLS grade on SSL Labs, the info is: Supported Named Groups secp256r1, secp384r1, secp521r1, x25519 (Server has no preference)

For example, if curves are declared in this field, could it be considered implicitly that their position in the JSON list is the server preferred order? In my example above, x25519 would be used in priority, then secp521r1 and so on.

[mholt]

That's odd, I saw that at first too, but can't reproduce it now.

• On my first test using a pre-existing server I had running (with all Caddy defaults -- but not Go defaults necessarily), I first saw that the server had a preferred order in the results.

• After adding curves x25519 secp256r1 secp384r1 secp521r1 to my Caddyfile, the results then showed "(Server has no preference)"

• After changing that line to Caddy's defaults (the same as if it had been omitted entirely) which are currently curves x25519 secp256r1, the tests showed the same results. (Yes I'm clearing the test cache.)

• After removing that line from my config, the tests still show the same results as before.

• Even after restarting the whole server process and using the defaults as in the beginning, it still says "(Server has no preference)"

• I've confirmed that Caddy is setting the curve IDs on the crypto/tls.Config struct in the proper, specified order by printing them out: 2020/04/17 07:22:25 CURVES: [29 23 24 25]. After that, it's up to the Go std lib.

As far as I can tell, Caddy is working perfectly fine here.

If this is important to your deployment, I'd suggest filing an issue either with Go or with Qualys... or both... since I'm not sure where the problem lies. I'd be super surprised if it was a bug in the Go standard lib, and the Qualys test results do seem inconsistent and unexplainable, to be honest.

So I'm leaning toward a bug in the Qualys test.

Let me know what you find out! Closing for now.