2012/4/23 Salisbury, Mark <mark.salisbury_at_hp.com>:
> I've not been keeping on the mailing list for the last couple of weeks; I tune in and I see some great news - Marc Hoersken has implemented a non-openssl SSL for windows. Some of the work I've been doing for my company for the last couple of years has had me using libcurl. I recently received permission to contribute libcurl work back to the open source community.
> One of the things I've done is exactly what Marc has done - create a non-openssl SSL backend for windows. Comparing what I implemented to what Marc has done, I think his implementation is very good and should go forward. I may have a few small improvements to offer though so I will probably follow with some patches headed either his way or to the libcurl community.
> I thought using the SSPI name would be confusing since libcurl uses SSPI for NTLM; creating a SSL backend would use a different part of SSPI (schannel) and it could be enabled independent of NTLM/SSPI. I called my implementation "winssl.c" and it relies on the #define USE_WINDOWS_SSL.
I am not actually using the name "SSPI". I am just re-using existing
SSPI functionality in libcurl and added the flag USE_SCHANNEL.
> I've compared his implementation and mine. Here are my observations:
> Pros in Marc's implementation:
> - it saves the current session ID for re-use; I'd guess this helps make subsequent connections to the same host faster
> - it specifies REVOCATION_CHECK flags depending on verifypeer, it also specifies TLS subversions 1_0 and 1_2.
> - it uses Curl_inet_pton() to determine if the host we are connecting to is an IP address; in that case it disables the hostname to certificate CN comparison check.
> - it appears to implement a non-blocking connect well
> - it may be commented better?
> Pros in my implementation:
> - it's been tested on Windows CE (and XP & Win7).
> - it has implemented a method to verify the server certificate for windows CE since InitializeSecurityContext() does not do this for you on WinCE.
> - write buffering implemented (though this is very easy to do). it continues in a loop until all bytes are written. Not sure if this is what Daniel
> intended as correct when he said "The code considers swrite() returns that are less than "full" to be errors.". The alternative is to maintain a 'bytes to write' buffer an check that first when a send call is invoked.
> - it simplifies setting up security buffers with a helper function (since this is done all over the place with schannel)
> - it doesn't call any socket methods like swrite / sread directly; it uses the libcurl methods Curl_write_plain and Curl_read_plain instead
> - doesn't seem like it has (so many?) hard coded buffer sizes
> Not sure if pro or not:
> - Marc's specify schannel dll version info.
This is changing currently. Steve and others are working on a better
way to represent the version information.
> - Mine uses NO_DEFAULT_CREDS (can't remember why I needed to use this flag)
You probably used it to avoid that Schannel automatically uses stored
client certs. It depends on the situation of this is desired by the
user or not.
> - If SEC_E_INCOMPLETE_MESSAGE is returned (when attempting to decrypt because insufficient data is available) Marc's patch returns CURLE_AGAIN immediately.
> Mine does something a little more complex - if some data was read but not enough to decrypt I'll keep trying to read data up to 1 second before bailing out. Marc's approach may be better as mine may block while other connections could be serviced.
> - Marc copied definitions from sspi.h / schnlsp.h into a local libcurl header file - curl_schannel.h; I include these files directly.
Please take another look. I am also including those files, but I
copied some required definitions, because they are not existent in
mingw32, but still required for cross-compilation.
This is just a quick feedback, because I don't have much time on my
hands right now. Thanks for your work!
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2012-04-23