An Introduction to OpenSSL Programming, Part II of II

Part two of the series that started in the September 2001 issue.
The Interaction of Multiplexed I/O with Rehandshake

We saw earlier that rehandshaking could cause SSL_write() to return with SSL_ERROR_WANT_READ. Similarly, SSL_read() can return with SSL_ERROR_WANT_WRITE if rehandshake occurs and the write buffers fill up (this is relatively unusual on modern platforms since the write buffers are generally large enough to accommodate typical SSL handshake records). In either case, the correct procedure is to select for read/write-ability and then reissue the offending call. This leads to some confusing logic since it means that under certain circumstances you respond to a socket being ready to read by calling SSL_write().

Let's take the case of SSL_write() first. If SSL_write() returns SSL_ERROR_WANT_READ we set the state variable write_blocked_on_read. Ordinarily, this would cause us to call SSL_read() but because write blocked on read is set, we skip the read loop and fall through to the write loop where the call to SSL_write() is reissued. Note that since the SSL handshake requires a number of reads and writes, it's quite possible that this call won't complete either, and we'll have to reenter the select() loop.

Now consider the case of SSL_read(). If SSL_read() returns SSL_ERROR_WANT_WRITE we set the state variable read_blocked_on_write and reenter the select() loop waiting for the socket to be writable. When it is we arrange to call SSL_read() again (see the second line of the test right after the call to select(). Note that after we call SSL_read() we fall through the the write section of the loop. However, even though the socket is writeable and so the FD ISSET test passes, SSL_write() will only be called if c2sl is nonzero and there's really data to write.

What's Still Missing?

Taken together, these articles demonstrate most of the essentials of writing SSL clients and servers with OpenSSL. However, OpenSSL offers a number of other powerful features that we don't cover, including:

Cryptographic Toolkit

Underlying OpenSSL's SSL implementation is a crypto toolkit implementing all the major cryptographic primitives, including RSA, DH, DES, 3DES, RC4, AES, SHA and MD5, as well as an ASN.1 encoder. Thus, OpenSSL is useful for people writing other kinds of cryptographic applications, even if they don't involve SSL.

Certificate Authority

OpenSSL contains the basic software required to write a certificate authority (CA). A number of CAs have been written on top of OpenSSL, including the free OpenCA project (see the references section).

S/MIME

OpenSSL now includes an S/MIME implementation, allowing it to be used to write secure mail clients. This is still somewhat of a hard hat area--the S/MIME support isn't quite complete yet and neither is the documentation.

External Resources

Parts of this article were adapted from my book SSL and TLS: Designing and Building Secure Systems, Addison-Wesley 2000. SSL and TLS offers a comprehensive guide to the SSL protocol and its applications. See www.rtfm.com/sslbook for more information.

Machine-readable source code for the programs presented here can be downloaded from the author's web site at: www.rtfm.com/openssl-examples. The source code is available under a BSD-style license.

You can get OpenSSL from www.openssl.org. The docs are on-line here as well.

The SSLv2 and SSLv3 specifications are on-line at www.netscape.com/eng/security/SSL_2.html and home.netscape.com/eng/ssl3/index.html The specifications for TLS (RFC 2246) and HTTPS (RFC 2818) are available at www.ietf.org/rfc/rfc2246.txt and www.ietf.org/rfc/rfc2818.txt.

The mod_ssl project lives at www.modssl.org. The ApacheSSL project lives at www.apachessl.org. The OpenCA project lives at www.openca.org/.

Acknowledgements

Many thanks to Lutz Jaenicke and Bodo Moeller for help with OpenSSL and catching a number of problems with the example programs. Thanks to Lisa Dusseault for review of this article.

Eric Rescorla has been working in internet security since 1993.

email: ekr@rtfm.com

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Block socket with SSL_MODE_AUTO_RETRY

Anonymous's picture

If I use block socket with SSL_MODE_AUTO_RETRY
The flag SSL_MODE_AUTO_RETRY will cause read/write operations to only return after the handshake and successful completion.

Do I have to handle the retrying in SSL_Read and SSL_Write? Isn't it easier to do this way? I know it hurts throughput a little, but is it a big deal?

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions