More Slick OpenSSL Tricks
Many network administrators know OpenSSL as a tool that implements Secure Sockets Layer (SSL) and Transport Layer Security (TLS) cryptographic protocols to secure your web surfing and email. But as we learned earlier this month, OpenSSL can do far more. With OpenSSL you can encrypt and decrypt files, verify file integrity, and see which encryption protocols and ciphers any server supports.
If you want to keep your files from unauthorized access, Linux file encryption tools like GnuPG, EncFS, and TrueCrypt are excellent and easy to learn, but you don't need another application to encrypt files if you already have OpenSSL. For instance, the command below encrypts a single file, in this example file-test. You can name your output file anything you want, or you can omit the output file spec if you want to print the file to your screen. OpenSSL prompts you twice for a password that you'll need to specify when you decrypt the file:
$ openssl aes-256-cbc -salt -in file-test -out file-test.aes
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
This example uses the very strong and fast Advanced Encryption Standard (AES) cipher, at 256 bits strength, using cipher-block chaining (CBC). AES is symmetric, which means it uses the same key for encryption and decryption. Block ciphers encrypt fixed-size blocks of bits in sequence, and the cyphertext (encrypted text) of each block is used to encrypt the next block. We'll talk more about ciphers in a moment.
-salt option. The salt is a set of random characters that OpenSSL combines with the password to create the encryption and authentication keys. This makes dictionary and brute force attacks considerably more difficult. Always use the
Decrypt the file this way:
$ openssl aes-256-cbc -d -in file-test.aes -out file-test-dec
During decryption, OpenSSL can recover a damaged block by looking at two adjacent blocks, so a single error will not corrupt a whole file.
If you're going to attach your encrypted file to an email message, you'll want to encrypt the file using base64 encoding, which you do by using the
$ openssl aes-256-cbc -a -salt -in file-test -out file-test-64
And decrypt it this way:
$ openssl aes-256-cbc -d -a -in file-test-64 -out file-64.dec
You can include the password in your encryption and decryption commands instead of waiting for the password prompt like this:
$ openssl aes-256-cbc -a -salt -in file-test -out file-test-64 -k password
This is not very secure because the password will be visible in your history, but it can speed up testing.
Encrypting Batches of Files
OpenSSL lacks a native batch encryption function, but you can batch-encrypt a group of files using a one-line bash script like the one below, which encrypts all the files in the current directory, and uses a password from a file:
$ for f in * ; do [ -f $f ] && openssl aes-256-cbc -salt -in $f -out $f.enc -pass file:password.txt ; done
It is not the most secure practice to use the same password and salt for a batch of files, or to use a password that's stored in a plain text file, but tracking bales of individual passwords is also risky. If you use this technique, protect your password well.
Another option is to roll up a batch of files in a tarball, then encrypt the tarball:
$ openssl aes-256-cbc -salt -in archive.tar.tgz -out archive.tar.tgz.aes
SHA-1 and MD5 Hashes
OpenSSL can generate a SHA-1 digest, also called a hash, that you can use to verify that a file has not been altered:
$ openssl sha1 file-test-64
If you've ever downloaded a Linux distribution, you're probably familiar with the way hashes are used to verify files. The original hashes are posted on the download site; you download the file, generate a hash using the downloaded file, and compare it to the hash posted on the site. If they match, it's a good download. You can easily generate digests for all the files in the current directory by piping the contents of the directory through the wonderful
$ ls * | xargs openssl sha1
You also have the option of MD5, MDC-2, and DSS1 hashes. I would stick with SHA-1 and MD5 because those are commonly used and well-supported by many Linux, Mac, and Windows commands, so you or whoever you exchange files with won't have to go hunting for the right commands to use them.
What Are Ciphers?
Earlier, I promised to talk more about ciphers. A cipher is an algorithm for encrypting and decrypting files – that is, it transforms their contents according to a specific mathematical methodology. The ciphers used by OpenSSL depend on encryption keys, which are generated from a password and a salt. Files encoded using modern ciphers are extremely difficult to decrypt. This is why attackers try to break encryption passwords rather than attack your files or encrypted network sessions, and that is why security people nag us to use long, complex passwords or passphrases. I ignore the impractical folk who advise not writing down your passwords. Silly people, how else will we remember long strong passwords?
You can query OpenSSL to see what ciphers it supports with this command:
$ openssl ciphers -v
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
That is a partial listing of what you'll see. Supported ciphers are listed in order from strongest to weakest. You can also view them sorted into categories, from high strength to low strength:
$ openssl ciphers -v HIGH
$ openssl ciphers -v MEDIUM
$ openssl ciphers -v LOW
What the heck does all this stuff mean? First of all, the strongest ciphers are 256-bit AES. In the second column SSLv3 means both SSLv3 and TLSv1 are supported. We use SSL/TLS everyday for secure web, email, and VoIP sessions over untrusted networks. SSL/TLS are not encryption schemes, but protocols that mediate the negotiation between client and server to choose which encryption ciphers will be used. This process is called the handshake. The server and client tell each other which ciphers they support, and then negotiate which one they'll use for the session.
You can control the encryption your own servers support. For example, Apache, Exim, and Postfix all have SSL configuration options so you can allow only strong ciphers and not allow weak ones. You can query your own servers, or anyone's servers, to see what they currently support:
$ echo 'GET HTTP/1.0' | openssl s_client -connect example.com:443
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
This is a strong server. It does not support the obsolete SSLv2 or weak ciphers. "Cipher is DHE-RSA-AES256-SHA" is the strongest cipher, and it is supported in all modern web browsers. You could also try the Qualys SSL Server Test to see how your servers rate.
Some shops fear losing users if they support only strong ciphers – but is it worth risking a security breach just to cater to users with unsafe clients? About a third of websites still support SSLv2, even though it has been obsolete for 15 years and is not supported in modern web browsers. But Windows XP and Internet Explorer 6 refuse to die, and about 9% of Internet users still use IE6 despite its multiple serious security problems.
Another reason you might want to query a web server is for your own online safety, to see if the sites you visit are as secure as they should be. I wish I could give you some simple rules to follow that would always keep you safe, but TLS/SSL is complex and continually evolving. The Opera Security Blog is a great source of up-to-date TLS/SSL news and technical information.
This work is licensed under a Creative Commons Attribution 3.0 Unported License
This work is licensed under a Creative Commons Attribution 3.0 Unported License