I'm working on adding SSL client support for the C++ client on Windows. This message contains the general plan - I welcome any input.
The current SSL support in the C++ client (and broker) uses NSS/NSPR. The Windows code will use Schannel instead, as it is more integrated with the Windows security architecture and management framework. This also allows the SSL support in Windows to be added without another optional piece of software to download and build. The use of Schannel leads to some areas which are different from Linux: 1. The options to specify the directory where the certificates, etc. are not needed. Windows manages locating these by itself. 2. SSL support need not be an optional plug-in. Since the supporting package is always available in the OS, the SSL support for Qpid can be built in always. Does anyone see a problem with always building it in? Architecturally speaking the Windows Schannel facility is different from NSS/NSPR in a fundamental area. The NSS/NSPR-based SSL code uses a separate set of socket calls right from the get-go. Schannel has functions to handle the SSL and key negotiations apart from socket I/O. Same for encrypt/decrypt. So the same network I/O calls are used in the SSL case as in the non-SSL case. The difference is that when doing SSL, the Qpid client needs to pass data to the Schannel calls at the appropriate times. Thus, whereas the NSS/NSPR-based SSL code pretty much replaces the AsynchIO-level code with code that is nearly the same except using NSS calls, the Windows SSL support is more of a shim that's inserted just above the current AsynchIO layer and intercedes when needed for session negotiation and encrypt/decrypt. As far as that shim is concerned, the work takes place in SslConnector (same as for the NSS case) but the work done by the NSS session calls happens in SslConnector::connect() using Schannel calls and blocking socket I/O. Although the I/O could also be done via the existing AsynchIO mechanism, this would be a change in behavior visible to the upper level and I'd like to keep the behavior the same as viewed from above. First item for changes I'm planning is a new method on qpid::sys::Socket to enable blocking mode (there's already a method to enable NONblocking mode). When I figure out any other command line options to apply for the Windows case, I'll add them to jira QPID-1403. -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
