cURL / Mailing Lists / curl-library / Single Mail



From: Henri Hein <>
Date: Mon, 14 Mar 2016 17:23:19 -0700

On Sat, Mar 12, 2016 at 3:57 PM, Ray Satiro via curl-library
<> wrote:
> I disagree here. The CTX function is meant to give an application a way to
> modify the context (ie the options) used to make the SSL object which
> represents the connection. It is documented as "called by libcurl just
> before the initialization of an SSL connection".

Understood. It makes sense to keep the SSL implementations aligned.

> Instead I would probably pass SCHANNEL_CRED, if
> there was any interest for that.

By this, do you mean call the SSL_CTX_FUNCTION callback in step 1, as the other
implementations, and pass the SCHANNEL_CRED as the ssl_ctx?

> If you need a way to run extra verification on the server certificate
> SCHANNEL_CRED can't help with that as far as I know.


> There is a new symbol
> CURLINFO_TLS_SSL_PTR [1] we've added for curl 7.48 (to be released later
> this month) that can be used to retrieve the active SSL connection and
> supports schannel. You can use it to get the CtxtHandle (the security
> context -- the closest thing schannel has to an SSL object) and use that to
> get the certificates.

That would indeed serve our purpose. If I understand it correctly, I can use
this to validate the server certificate and close the connection, either after
easy_perform returns, or maybe during callbacks. I would prefer an option
to validate early, after the TLS handshake and before data is being
transferred. I honestly don't know what my options are here.

More info: I used the SSL_CTX_FUNCTION callback to implement
the equivalent functionality to PINNEDPUBLICKEY. I chose to use the
SSL_CTX_FUNCTION callback, because the footprint on libcurl was
much smaller that way. I am willing to make a pull request for
the CURLOPT_PINNEDPUBLICKEY implementation in SSPI, if
that is more agreeable.

  - Henri Hein
List admin:
Received on 2016-03-15