On Sat, Mar 12, 2016 at 3:57 PM, Ray Satiro via curl-library <[email protected]> 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. Agreed. > 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. Thanks, - Henri Hein ------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
