You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Steve Huston <sh...@riverace.com> on 2009/11/23 23:33:26 UTC

Plans for SSL client support for Qpid C++ on Windows

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:dev-subscribe@qpid.apache.org


Re: Plans for SSL client support for Qpid C++ on Windows

Posted by Carl Trieloff <cc...@redhat.com>.
Steve Huston wrote:
> 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?

The idea for plugins is also not to bloat the runtime when options are 
not used. This will come
down to a call on Windows, but I expect Windows will also do for kerb 
support which gives
auth and encryption. When kerb is being run, there is no need for SSL. 
Thus if it brings in a bunch
of stuff a plugin would be the better way to go.

Carl.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org