Introduction

Today’s most widely used security toolkit is OpenSSL, not only due to its licensing terms (including a commercial use with no restrictions whatsoever) but due to its rich plethora of facilities and building blocks we can use to build any sophisticated cryptosystem.

It is also a rich learning tool, and despite its serious nature, we can use it to understand several basic questions like how internet banking works or how cryptocurrencies function. You can also learn fingerprinting and blockchain logic using the Linux command line and OpenSSL utility.

OpenSSL

Openssl has an API you can use, or config files and command line. Still, in this article, we will focus only on some practical applications of diagnosing and gaining insight into how the Internet trust system was built. We will go over PKI and other certificate trust hierarchy, expiry, how TLS handshake functions, and how symmetric ciphers hide sensitive information.

In doing so, we shall look at several command-line examples using s_client utility and a few other commands that OpenSSL supports out of the box. To try these commands, you may not even need to install it, as it comes out of the box on most Linux distributions.

If you want to start with the basics of OpenSSL, I would recommend reading my previous blog on “Dipping our toes into OpenSSL.”

Command samples

Below are useful OpenSSL commands that can get you diagnostic information:

$ openssl s_time -connect gmail.com:443 -new Collecting connection statistics for 30 seconds *************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************

361 connections in 0.78s; 462.82 connections/user sec, bytes read 0
361 connections in 31 real seconds, 0 bytes read per connection

The above helps you know the speed of the cryptographic operations done on the server-side.

$ openssl s_client -host example.com -port 443 -cipher ECDHE-RSA-AES256-GCM-SHA512 2>&1 </dev/null

Example.com is a real domain in the above example. This command forces the server to negotiate a cipher suite we specify(ECDHE-RSA-AES256-GCM-SHA512).

The output ends with this:

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4675 bytes and written 631 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

DONE

So from above, we know the server can only do SHA384, not our SHA512. Therefore we have to downgrade our digest to suit the server. Then only a TLS connection can exchange data securely.

Apropos of it, TLS is just a layer above which you can build any other protocol like POP3, IMAP, LDAP, HTTP, or anything you develop that is proprietary as well.

Next command:

$ openssl s_client -connect www.feistyduck.com:443 -cipher kEDH

<em>--- </em>
<em>No client certificate CA names sent</em>
<em>Peer signing digest: SHA512 </em>
<em>Peer signature type: RSA </em>
<em>Server Temp Key: DH, 2048 bits </em>
<em>--- </em>
<em>SSL handshake has read 4066 bytes and written 646 bytes </em>
<em>Verification: OK</em>

You see, the temporary key is size 2048 bits. Look for “Server Temp Key” above.

You can inspect the entire certificate chain from this <strong>command s_client</strong>.

$ openssl s_client -connect www.google.com:443 

It lists many certificates in text format, and you can further inspect the fields inside using the x509 command of OpenSSL.

Since a certificate is a public entity, we can see for ourselves what all it contains.

OpenSSL, however, will not allow you to look into private encrypted information. Still, it will help you identify patches and security weaknesses to ensure that you are doing things right from a security perspective.

For instance, from a vulnerability perspective, the heartbleed bug, the chunked encoding bug in Apache, and so on come to mind.

Conclusion

OpenSSL is such a building block that even other cryptographic systems like GnuPG and <strong><em>ssh / scp / sftp</em></strong> rely on OpenSSL behind the scenes. Hopefully, this article in the series gives you some more appetite to learn its potential and use it to your advantage.

Did you enjoy this content? Follow our linkedin page!