Add support for sql server certificate chain validation

[rgl]

SQL Server does not use a raw TLS connection, instead it uses something similar to STARTTLS/Opportunistic_TLS, where you first need to do a clear text handshake to tell it to switch to TLS.

It would be pretty nice to have support for this in ssl_exporter. I already have rgl/dump-sql-server-certificate-chain that dumps the certificates, with some modification I believe it can be integrated here (e.g. by handling tds:// schemed urls).

What do you think?

[ribbybibby]

Interesting. What does the required handshake look like? Do you think it could be integrated in the same way that I've integrated other starttls protocols: https://github.com/ribbybibby/ssl_exporter/blob/master/prober/tcp.go#L75-L124?

I'd rather not import client specific libraries for every protocol here.

[rgl]

I do not really know the details nor do I known how complex it is to go that route. In theory we should be able to extract that part from the mssql client.

[rgl]

After looking more closely at the code, I think its way too complex to handle this without using the mssql library.

Have a look at https://github.com/denisenkom/go-mssqldb/blob/0f454e2ecd6ad8fb4691cdbf10e399e05ca03784/tds.go#L833-L949.

Can I prepare a patch using that library?

[ribbybibby]

It's possible that we could simplify what that library is doing down to the bare essentials and reduce a lot of the complexity. I'd be interested in looking into it myself as I think a generalised approach could then apply to other protocols.

[rgl]

Wouldn't that complexity be almost eliminated by the compiler?

Wouldn't the complexity of implementing/maintaining the protocol shifted here?

In the meantime, I have a working tds prober at https://github.com/rgl/ssl_exporter/tree/add-tds-prober, can you have a look at it?

BTW, do you known about https://github.com/square/certigo/tree/master/starttls? It contains other protocols that would be useful to adopt here, like PostgreSQL.

[ribbybibby]

Support for postgresql was added here: #77. I wonder if it would be possible to use the same approach for mssql.