Fix | Skip the CRL check during authenticaiton

[DavoudEshtehari]

Passing the true as the last parameter in AuthenticateAsClient(String, X509CertificateCollection, SslProtocols, Boolean) method enables the Certificate Revocation List (CRL) check during authentication. If the CRL wasn't accessible from where the request was sent, it will fail to send the request to the SQL Server.

• related issue Unable to connect to SQL Server with encryption enabled with 4.0 #1402

[David-Engel]

I'd note in the description that passing false instead of true to that API changes the behavior of the call back to the way it was prior to the changes in #1168.

[roji]

It may be worth adding a connection string parameter to allow opting into the CRL check, for users which do want it (CRLs can be a very important security thing).

[David-Engel]

It may be worth adding a connection string parameter to allow opting into the CRL check, for users which do want it (CRLs can be a very important security thing).

@roji
I don't think that is necessary. The previous method we were calling, AuthenticateAsClient(string targetHost), just called the new method with a false parameter:
AuthenticateAsClient(targetHost, null, SecurityProtocol.SystemDefaultSecurityProtocols, false);
So by changing false to true in the previous PR, I believe we are forcing an immediate CRL check on every connection (bad for performance). I also assume, that by passing false, as the previous method was, we are only suppressing the CRL check for the immediate connection. The underlying platform can still update the CRL list when it deems it is necessary/appropriate.

[roji]

So by changing false to true in the previous PR, I believe we are forcing an immediate CRL check on every connection (bad for performance).

A CRL check on every (physical) connection can be critical for security, otherwise an application may accept certificates that have been revoked. In the common case, I don't expect the performance of physical connection opening to be critical - that's why pooling is there, and SSL/TLS already typically involved multiple round trips between the client and server.

Note that I'm not advocating CRL necessarily be enabled by default - just to allow users to opt into it if they so wish, for added security (FWIW this is what Npgsql does, see docs. After all, SslStream does expose this bool flag, so it's just a matter of allowing users to determine what SqlClient passes into it. If that makes sense, I can open a new issue for that.