How much verification does crypto/tls's InsecureSkipVerify actually skip?

[David Anderson]

I'm writing a piece of software that uses TLS with client and server cert verification to secure communication. However, it also needs to support a "bootstrap" phase where the peers verify their identities using a different mechanism and exchange certificates for future communication. I have a possible way to make this happen, but it is dependent on the semantics of InsecureSkipVerify.

Basically, it relies on A passing to B information about its cert chain (subject+hash of the root and leaf certs). B then connects back to A and sets up a TLS session with no client certs, and InsecureSkipVerify=true. Once the TLS session is up, B checks the server-provided cert chain for a match with the information it was given. If it's a match, it considers the session authenticated, stores A's root and passes its own root back over the TLS channel. At that point, both parties disconnect the bootstrap channel and establish a new TLS session with full client and server cert checking.

This bootstrap method relies on two things:

1. That checking the hash of the DER-encoded certs in the chain against a whitelist of hashes is sufficient to establish initial trust. That is, are SHA-2's collision resistance properties still sufficient to authenticate x509 certs, or is it trivial-ish to construct such a collision and MitM the bootstrap?
2. That InsecureSkipVerify only disables checking of the cert chain against the trust roots (and hostname checking, irrelevant in my situation), but still checks the well-formedness of the presented chain (valid signatures all around, i.e. "this all looks plausible, if only I trusted the root of this chain").

Does tls.Config's InsecureSkipVerify effectively promise (2) ?

Thoughts on (1) are also welcome from knowledgeable crypto folks, if any are lurking. I'd love to use a well-known system for initial bootstrapping, just like I use TLS for the steady state, but I don't know of such a system that doesn't involve exchanging the certs themselves (which I can't do due to length constraints on the bootstrap message I can pass from A to B).

- Dave

[David Anderson]

After a bit of code spelunking, it seems that InsecureSkipVerify skips any and all form of validation on the cert chain, other than basic encoding well-formedness (enforced by the parser), so it's not usable in the way that I was proposing.

It also turns out that I may have overestimated the size of an SSL cert with a decent length key, and should be able to pass the entire cert from one peer to another without excessive trouble.

Sorry for the monologue-like noise :-).

- Dave