| Steve's Networked Programming
Newsletter |
Making Nets
Work
December
2009
|
|
This month
I briefly cover something I learned about while adding
SSL support to Apache Qpid on Windows: there's a native
SSL implementation in Windows. I've used OpenSSL on
Windows for years without knowing Windows has SSL
native.
We've also reached the end of another
year. Thank you for subscribing to my newsletter and an
extra thanks to those who reply to me with your insights
and questions. Hearing from you is the most enjoyable
part of writing this newsletter. Stay safe in your New
Year celebrations!
For those of you fortunate
enough to be getting a well-deserved end-of-year rest,
welcome back, and Happy New Year!
As always, be sure to forward this note to other
people you work with to be sure they know what's
happening in the world of networked application
development.
|
Adding
SSL Support to a TCP/IP Application on
Windows
|
I
spent the better part of December adding SSL support to
Apache Qpid on Windows, both broker and client. I
started researching how to do it a number of months
before. The Linux port of Qpid uses Mozilla NSS for SSL.
That wouldn't work for Windows for a few reasons, the
primary one being that the I/O layer in Qpid on Windows
is all asynchronous and NSS wouldd not work with that
scheme. Also, Windows offers a perfectly good SSL
implementation called Schannel (yes, this was a surprise
to me!) that's nicely integrated with the certificate
handling mechanism other parts of Windows use (IE, MS
SQL, web services, etc.). Since Microsoft was funding
the effort, that was also a consideration.
Well,
if deciding to use Schannel for SSL was an easy
decision, figuring out how to use it was
anything but. I pretty quickly located some info in MSDN
with the promising title "Establishing a Secure
Connection with Authentication". I read it and
really just didn't get it. (Of course, now, in
hindsight, it looks pretty clear.) Part of my trouble
may have been a paradigm expectation. Both
OpenSSL and NSS pretty much wrap all of the SSL
operations into their own API which takes the place of
the plain socket calls. Functions such as connect(),
send(), recv() have their SSL-enabled counterparts in
OpenSSL and NSS; adding SSL capability to an existing
system ends up copying the socket-level code and
replacing plain sockets calls with the equivalent SSL
calls (yes, there are some other details to take care
of, but model-wise, that's pretty much how it goes).
In Schannel the plain Windows Sockets calls are still
used for establishing a connection and transferring
data. The SSL support is, conceptually, added as a layer
between the Winsock calls and the application's data
handling. The SSL/Schannel layer acts as an intermediary
between the application data and the socket,
encrypting/decrypting and handling SSL negotiations as
needed. So to add SSL support to an existing TCP-based
application is more like adding a shim that takes care
of negotiating the SSL session and encrypting/decrypting
data as it passes through the shim. Now that I
understand how to use Schannel much better, I'm eager to
use it for other projects. One possible area is the SSL
Sockets classes in ACE. Those classes use OpenSSL now,
but there's no need to require an external package to
get SSL support when Windows offers it natively. If you
have a need for such an addition, let me know!
If
you're interested in hearing more about Schannel, please
keep an eye on my blog - there's a Schannel overview that's
a bit longer than this article, and I'll also be
blogging about how to use Schannel's encrypt/decrypt
functions. If you're thinking about using Schannel,
definitely read those since the MSDN docs are wrong; I
eventually got the correct information from MSDN
support, so save yourself the time and check out the
blog.
|
| Do You
Need Help Designing Your Next System? |
Nobody
has to tell you that designing a well-formed, efficient,
maintainable networked application is hard. You've had
to deal with it. The problem is that networking
functionality is usually in a supporting role to your
system's main purposes, and your skills and experience
are much better used to focus on specific business and
technology issues. It may make more sense to bring in
seasoned expertise to help design a solid networking
base in your next system.
I've helped many
companies get great networked applications built - I may
be able to help you as well. Let's talk and see if I can
help take care of the networking, and let you focus on
applying your expertise and experience to the business
features that'll really help your system stand
out.
Call me at 508-541-9180 or email me at shuston@riverace.com.
| |
|
If you have any ideas for areas of networked
programming you'd like to hear about in future issues,
please email me with your suggestions. In the meantime,
keep those nets working!
Sincerely,
Steve Huston
Riverace
Corporation
| | |
| |
