Is making it configurable still possible while preserving backwards compatibility in the future?

Yes: making something configurable is backwards-compatible as long as the default behavior remains the same. (We can be certain that no existing program configures it to anything other than the default.)

cc @golang/security

CC @golang/security

Looks like this didn't make 1.19. Moving to backlog. Please recategorize as appropriate. Thanks.

I've found real-world case where I can't connect to development server.
handshake message of length 97407 bytes exceeds maximum of 65536 bytes

The server has some extremely long list of SANs, but the certificate is still valid and works for at least for curl and Chrome and AFAIK it's conformant with RFC per "MAX indicates that the upper bound is unspecified. Implementations are free to choose an upper bound that suits their environment."

Also JDK has it's setting jdk.tls.maxHandshakeMessageSize. It would be good to have it configurable, so that even if it's against best practices let the user decide what maxHandshake works for them

Is there a concrete API proposal here, It sounds like essentially what is wanted is a new field on tls.Config? i.e.

type Config {
    ...

    // MaxHandshakeMessageSize is the maximum acceptable TLS handshake message
    // size in bytes. The protocol maximum is 16MB, calling Conn.Handshake with
    // a value higher than this will result in an error. If
    // MaxHandshakeMessageSize is 0, the default value is 64KB.
    MaxHandshakeMessageSize int
}

What is the best way to move this forward? I can create an API proposal (similar to this) and provide an implementation if desired.

If 64kB is no longer a reasonable upper limit, it seems like we should bump to a new reasonable limit. That wouldn't be an API change.

I propose going directly to the maximum length provided by the spec (16MB), unless there are performance or security concerns that make this infeasible.

Could there be some users that are implicitly relying on the low default limit to mitigate the threat of resource exhaustion attacks? There's no way to currently specify a request size limit in net/http.Server, and both http servers and TLS configs mainly deal with time limits rather than size limits.

Given how rarely this limit is run into, it might be safer to provide configurability rather than a change in behaviour. At some point (maybe even at the same time) the default can also be raised somewhat.

This is mainly a theoretical concern though and I'm not sure this would actually be a problem in practice. I'm just worried about internet-exposed servers suddenly being vulnerable to DDoS by a client opening thousands of connections with large handshakes then holding the connections open until timeout. This was the original motive for having a low limit, I imagine.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

This cap limits how much memory we can be made to allocate in a handshake (which happens before anything higher level such as net/http is brought in). We should not go straight to 16MiB.

If the only message that can conceivably be that big is the Certificates message, let's just make the cap for that specific message 256KiB or something like that.

That way most servers will be unaffected, and anyway it takes more work to do a DoS than just spamming giant Client Hello messages.