Go: crypto/tls: feature request: add option to JUST skip hostname verification

[robin865]

I understand in "https://github.com/golang/go/commit/fca335e91a915b6aae536936a7694c4a2a007a60" we made changes to enforce either requiring ServerName or InsecureSkipVerify to be set in our tls libraries.

What about making this the default behaviour but having a "SkipHostnameVerification" option? I have a situation where we are using certs signed by our own private CA. The hostname verification won't work since we pre-generate certs using a CN that isn't an actual DSN/Host name. I still want to validate that other servers certs are at least signed by the same private CA as the client but JUST want to skip the hostnameVerify check. Today that doesn't seem possible.

[ianlancetaylor]

CC @agl @FiloSottile

[FiloSottile]

You can currently do this by using VerifyPeerCertificate and (*Certificate).Verify (and remembering to put the remaining rawCerts into VerifyOptions.Intermediates).

https://github.com/golang/go/blob/39e523792e33a0bd9217161ca53c6c0cb2324a99/src/crypto/tls/handshake_client.go#L315-L344

I don't think this is common enough to add another verification option to the already crowded tls.Config.

[robin865]

Problem is I want to use a library (rafthttp) that only exposes a transport.TLSInfo (https://github.com/coreos/etcd/blob/master/pkg/transport/listener.go) , not a tls Config (https://golang.org/pkg/crypto/tls/#Config). So this sort of manual workaround would need to be plumbed up the stack for me to use it. If there was a simple option, it would be easier to plumb this through.

[https://avatars2.githubusercontent.com/u/3730757?v=4&s=400]https://github.com/coreos/etcd/blob/master/pkg/transport/listener.go

etcd/listener.go at master · coreos/etcd · GitHubhttps://github.com/coreos/etcd/blob/master/pkg/transport/listener.go
github.com
etcd - Distributed reliable key-value store for the most critical data of a distributed system

Package tls - The Go Programming Languagehttps://golang.org/pkg/crypto/tls/#Config
golang.org
Constants. A list of cipher suite IDs that are, or have been, implemented by this package. Taken from http://www.iana.org/assignments/tls-parameters/tls-parameters.xml

---

From: Filippo Valsorda [e-mail]
Sent: September 27, 2017 5:37 PM
To: golang/go
Cc: rsm10; Author
Subject: Re: [golang/go] crypto/tls: feature request: add option to JUST skip hostname verification (#21971)

You can currently do this by using VerifyPeerCertificate and (*Certificate).Verify (and remembering to put the remaining rawCerts into VerifyOptions.Intermediates).

https://github.com/golang/go/blob/39e523792e33a0bd9217161ca53c6c0cb2324a99/src/crypto/tls/handshake_client.go#L315-L344

[https://avatars3.githubusercontent.com/u/4314092?v=4&s=400]https://github.com/golang/go/blob/39e523792e33a0bd9217161ca53c6c0cb2324a99/src/crypto/tls/handshake_client.go#L315-L344

golang/gohttps://github.com/golang/go/blob/39e523792e33a0bd9217161ca53c6c0cb2324a99/src/crypto/tls/handshake_client.go#L315-L344
github.com
go - The Go programming language

I don't think this is common enough to add another verification option to the already crowded tls.Config.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/golang/go/issues/21971#issuecomment-332693931, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAvL8o2bbdzxc8ptfc343eWUqY16IHmQks5smupMgaJpZM4Pf-6w.

[robin865]

As to your original suggestion, curious why on lines 334-336 we seem to skip the first cert in the chain?

    if i == 0 { 
        continue 
    }

[FiloSottile]

The first cert is the leaf, and it’s used on line 339. All the others are intermediates and are used on line 337.

[rsc]

Problem is I want to use a library (rafthttp) that only exposes a transport.TLSInfo (https://github.com/coreos/etcd/blob/master/pkg/transport/listener.go) , not a tls Config

This is a very special case. I would suggest working with the library maintainers (or just having your own fork) to expose the tls.Config. We shouldn't add a second way to do something in the standard library (especially a somewhat confusing security knob) just because one downstream package hides the first way.

[benma]

I am also interested in skipping the hostname verification only. The problem is that if the ServerName is unset, it ill be inferred. As stated above, one way to achieve it is to set InsecureSkipVerify to true and copy/paste the code from the stdlib to config.VerifyPeerCertificate, but that is suboptimal, as one would miss fixes done to this part of the code in the stdlib.

:+1: for a SkipHostnameVerification option.

[sikemullivan]

👍 for a SkipHostnameVerification option as well.

Trying to get client authentication working with MySQL. Using a self-signed cert because I'm running everything out of VPS machines. Everything is IP based. Has anyone built the code for the suggested work around? I don't want to reinvent the wheel.

[benma]

@sikemullivan

yes, here: https://github.com/digitalbitbox/bitbox-wallet-app/blob/b04bd07852d5b37939da75b3555b5a1e34a976ee/backend/coins/btc/electrum/electrum.go#L76-L111

[sikemullivan]

Awesome, thanks for the quick response.

[sikemullivan]

@benma

Should line 109 set the verified chains? Or does it not matter?

Now:

_, err := certs[0].Verify(opts)
return err

Then:

verifiedChains, err := certs[0].Verify(opts)
return err

[benma]

~Based on a quick look through the stdlib, I would say it would make sense, yes. Seems to be exposed only in conn.ConnectionState(), and conn.VerifyHostname(). Not sure why I didn't put it in back then.~

That was too quick. I looked again, and verifiedChains is input to the function, not output. The api/callback doesn't support setting verifiedChains (which should probably be fixed upstream).

[sikemullivan]

Agree, everything seems to work without it getting returned. Thanks for your help.

[gopherbot]

Change https://golang.org/cl/193620 mentions this issue: crypto/tls: add ExampleConfig_VerifyPeerCertificate