- Writing an HTTPS Server
- Writing a Secure Client
- Dealing with the Limitations
- Looking at the Security Landscape
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Dealing with the Limitations
The OpenSSL library makes writing standard and secure network programs fairly easy. As this article has shown, the interface is straightforward and not really an obstacle. However, for all its ease of use, it does present some limitations. These limitations are not showstoppers, but you may need to prepare yourself for them.
One limitation in the library is a lack of session recovery. Session recovery is a feature in highly reliable network programs that are able to restart a session where it left off. OpenSSL doesn't appear to include this feature in the API. The simplicity of the API (you accept the raw connection) contributes to the flaw. The program creates a streaming socket and then hands it off to the OpenSSL library. In a sense, OpenSSL never really owns the socket. So, if the peer connection is lost, the library can't restart the connection and resume the session. Instead, if you're careful, you can use checkpointing during the session, and when a client reconnects after a communication break, the program moves to the last known checkpoint.
Another surprise you may encounter is the protocol itself. For some reason, Netscape 4.7 only connects to SSLv2 (it then claims that the connection is SSLv3). Later versions may not exhibit this problem, but you may have to support several protocols in your released code. Fortunately, supporting multiple protocols is fairly simple.
Finally, OpenSSL is a moving target. The version as of this writing is 0.9.6a. Change happens. Also, the API is good and solid but not 100% documented, making development a little challenging. So, as you develop programs, you may want to subscribe to the developers' message forum to gain insight and get help if needed.