Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: crypto/tls: make maxHandshake configurable #50773

Open
awnumar opened this issue Jan 24, 2022 · 6 comments
Open

proposal: crypto/tls: make maxHandshake configurable #50773

awnumar opened this issue Jan 24, 2022 · 6 comments
Assignees
@FiloSottile
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal
Milestone
Backlog

Comments

@awnumar
Copy link
Contributor

awnumar commented Jan 24, 2022 •
edited

What version of Go are you using (go version)?

$ go version
go version go1.17.6 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/awnumar/Library/Caches/go-build"
GOENV="/Users/awnumar/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/awnumar/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/awnumar"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.17.6/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.17.6/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17.6"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/s2/fftr5j0n443f4z2sm11wlxv40000gn/T/go-build2260917661=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

  1. Generate a very large certificate. I passed mkcert many short SANs to get this.
  2. Start a Go TLS server.
  3. Connect to it with a Go TLS client.

What did you expect to see?

I expected the connection to succeed.

What did you see instead?

tls: handshake message of length 110013 bytes exceeds maximum of 65536 bytes

The limit is defined here:

const maxHandshake = 65536 // maximum handshake we support (protocol max is 16 MB)

and it says that the protocol max is 16 MB, not 64 KiB. I assume this hard limit is to mitigate resource exhaustion attacks, but it would be preferable if it was configurable.

Context

We dynamically generate certificates for mTLS within and across clusters and configure which services are allowed to open connections between each other using Subject Alternative Names. In extreme cases a service that needs to communicate with many other services could have a certificate that's larger than this limit.

This isn't a problem right now but a limit of 64 KiB provides a fairly small and uncomfortable safety buffer. Is there a reason that this limit is not configurable?

This issue is related to #35153 where @FiloSottile says "Documenting something makes it a backwards compatibility promise". Is making it configurable still possible while preserving backwards compatibility in the future?
@bcmills
Copy link
Contributor

bcmills commented Jan 24, 2022

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

@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 24, 2022
@seankhliao
Copy link
Member

cc @golang/security

@FiloSottile FiloSottile self-assigned this Mar 2, 2022
@FiloSottile FiloSottile added this to the Go1.19 milestone Mar 2, 2022
@ianlancetaylor
Copy link
Contributor

CC @golang/security

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

@ianlancetaylor ianlancetaylor modified the milestones: Go1.19, Backlog Jun 24, 2022
@fkalinski
Copy link

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

@rolandshoemaker
Copy link
Member

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
}

@rolandshoemaker rolandshoemaker changed the title crypto/tls: make maxHandshake larger or configurable proposal: crypto/tls: make maxHandshake configurable Oct 18, 2023
@malt3 malt3 mentioned this issue Apr 3, 2024
Merged
5 tasks
@malt3
Copy link

malt3 commented Apr 3, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@FiloSottile FiloSottile

Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal
Projects
Proposals
Status: Incoming
Release Status & Release Blockers
Status: No status
Milestone
Backlog
Development

No branches or pull requests
8 participants
@FiloSottile @malt3 @ianlancetaylor @fkalinski @rolandshoemaker @bcmills @awnumar @seankhliao