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

crypto/tls: Currently there's no way to find out what protocol was used to negotiate TLS connection on the client #7231

gopherbot opened this issue Jan 29, 2014 · 6 comments


Copy link


As far as I can tell, there's no exposure to what TLS protocol was used after performing
the TLS handshake.  I noticed we store the version that was used here:

However, this is in a private member of the Connection structure, and there are no
accessors for it.

Now that Go supports more than just TLS1.0 for secure connections from the client side,
it would be nice to expose what protocol was used to perform the handshake.  I figured
adding a Version() method to the connection or perhaps a member in the ConnectionState
struct would work quite nicely.

I scraped/read as much of the crypto/tls package but I'm not super familiar with crypto
stuff.  I couldn't really see a way to be able to determine this information as a user
of the library, so sorry if I'm missing an obvious way to access this.
Copy link

Comment 1:

Owner changed to @agl.

Copy link

mikioh commented Jan 30, 2014

Comment 2:

Not sure what's your use case but for debugging/developing/dissecting TLS stuff at
plugfest, you can scratch an established tls.Conn by using package reflect like the
func tlsVersion(c *tls.Conn) (int, error) {
        cv := reflect.ValueOf(c)
        switch ce := cv.Elem(); ce.Kind() {
        case reflect.Struct:
                fe := ce.FieldByName("vers")
                return int(fe.Uint()), nil
        return 0, errors.New("something wrong")
For managing TLS entities, you can also implement

Copy link

Comment 3 by

Eh, this is something I'd like to do on every request, so ideally, I'd like something
very performant.  I'm not sure what the performance hit of using the reflection package
is, but it seems to me that it would be much slower than a straight up dereference check

Copy link

agl commented Jan 30, 2014

Comment 4:

Agreed. We should have the version in the ConnectionState. Will do for 1.3.

Labels changed: added release-go1.3maybe, repo-main.

Copy link

Comment 5 by

I've given a crack at adding the patch myself, seemed straight forward enough that I
figured I would give it a try:

Copy link

agl commented Feb 24, 2014

Comment 6:

This issue was closed by revision c7612f3.

Status changed to Fixed.

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018
Fixes golang#7231.

R=golang-codereviews, bradfitz
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

5 participants