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

Closed
gopherbot opened this issue Jan 29, 2014 · 6 comments
Milestone

Comments

@gopherbot
Copy link

by manoj.dayaram@moovweb.com:

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:

http://golang.org/src/pkg/crypto/tls/handshake_client.go#L85

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.
@bradfitz
Copy link
Contributor

Comment 1:

Owner changed to @agl.

@mikioh
Copy link
Contributor

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
following:
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 http://tools.ietf.org/html/rfc6353.

@gopherbot
Copy link
Author

Comment 3 by manoj.dayaram@moovweb.com:

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
=/

@agl
Copy link
Contributor

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.

@gopherbot
Copy link
Author

Comment 5 by manoj.dayaram@moovweb.com:

I've given a crack at adding the patch myself, seemed straight forward enough that I
figured I would give it a try:
https://golang.org/cl/55400044/#ps2

@agl
Copy link
Contributor

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.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/68250043
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants