256-bit AES Encryption for SSL and TLS: Maximal Security
SSL and TLS are the workhorses that provide the majority of security in the transmission of data over the Internet today. However, most people do not know that the degree of security and privacy inherent in a “secure” connection of this sort can vary from “almost none” to “really really good … good enough for US government TOP SECRET data”. The piece which varies and thus provides the variable level of security is the “cipher” or “encryption technique”. There are a large number of different ciphers — some are very fast and very insecure. Some are slower and very secure. Some weak ones (export-grade ciphers) are around from the days when the USA did not permit the export of decent security to other countries.
AES, the Advanced Encryption Standard, is a relatively new encryption technique/cipher that is the successor of DES. AES was standardized in 2001 after a 5 year review, and is currently one of the most popular algorithms used in symmetric key cryptography (which, for example, is used for the actual data transmission in SSL and TLS). It is also the “gold standard” encryption technique; many security-conscious organizations actually require that their employees use AES-256 (256-bit AES) for all communications.
This article discusses AES, its role in SSL, which web browsers and email programs support it, how you can make sure that you only use 256-bit AES encryption of all secure communications, and more.
More about AES
AES has been available in most cryptographic libraries for a long time. It was available in “OpenSSL” starting in 2002 with v0.9.7. OpenSSL is the foundation of most SSL services in UNIX and Linux environments, such as that used by LuxSci. GPG, the open source implementation of PGP, also include an AES 256 option.
So, while AES is the new kid on the block, it has been around long enough to permeate most software. However, as we shall see, this does not mean that is its actually being used on your computer!
How Secure is 256-bit AES?
AES is FIPS (Federal Information Processing Standard) certified and there are currently no known non-brute-force direct attacks against AES (except some side channel timing attacks on the processing of AES that are not feasible over a network environment and this not applicable to SSL in general). In fact, AES security is strong enough to be certified for use by the US government for top secret information.
The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. The implementation of AES in products intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition and use.” (Lynn Hathaway, June 2003 – reference.)
If you have the choice of encryption methods, 256-bit AES is the method to choose. Also good are 128-bit and 192-bit versions of AES.
The Beast Attack and SSL-secured web sites
For SSL used for web site traffic (as opposed to other things like IMAP, SMTP, encryption of files, etc.), there is an attack knows as The Beast. In this attack, people in a trusted location on your network can potentially break into your SSL session and eavesdrop on your communications.
The solution is to use TLS v1.1+ ciphers. However, this BEAST is not considered an important attack vector anymore.
And there alternatives to AES?
There are many alternative ciphers that can be used in SSL and TLS. A good alternatives or additions to your cipher suite would include “3DES” (e.g. for compatibility with Windows XP). We would not recommend using RC4 anymore, due to known weaknesses. If you look at the list of ciphers recommended by FIPS/NIST for high security, they are all essentially AES or DES with various hashes, key exchange protocols, etc.
How is the cipher chosen in an SSL or TLS session?
In general, when an SSL client, such as an email program or web browser, connects to a server and wishes to use SSL or TLS, the client sends the server a list of encryption ciphers that it supports. The server then goes through the list, in order, and chooses the first match that it also supports. Usually, the client orders the list with the most secure methods first, so that the most secure method supported by both the client and server is selected. Sometimes, the client orders the list based on other criteria to make a compromise between security and speed; this can result in a sub-optimal cipher being chosen.
Most modern web and email servers that support SSL encryption, like LuxSci.com’s servers, support many different strong encryption techniques all the way up to 128-bit RC4 and 256-bit AES. They provide a variety, instead of just a single really good method, so that users who have old or broken software can still take advantage of encryption, even if it is weaker than it should ideally be.
Additionally, most companies that provide security services do not permit use of techniques that deemed are “too weak” and which can be broken very easily (like the old “export grade ciphers” that used to be in prevalent use). So, if you are connecting to a reputable service provided over SSL or TLS, the type of encryption that will be used is almost certainly determined by your client program (i.e. email program or web browser) based on the options (and the order thereof) presented by the server.
What encryption techniques are supported by modern web browsers?
For any given web browser, it is easy to see what the best encryption technique it supports by browsing to the web site: https://www.howsmyssl.com/
Checking out some of the current browsers available, we see:
||Operating System||Best Cipher||Verdict?|
|Native Android Browser (LG G3)||Android v4.4.2+||AES 256-bit||Good!|
|Chrome v39+||Android v4.4.2+||AES 256-bit||Good!|
|FireFox Mobile v8+||Android||AES 256-bit||Good!|
|Safari||iOS v8+ (iPhone/iPad/etc.)||AES 256-bit||Good|
|Safari||iOS v5.0.1||AES 128-bit||Good|
|Safari||iOS v2.2||AES 128-bit||Good|
|Silk||Kindle Fire||RC4 128-bit||Fair|
|FireFox v35+||Windows XP & Vista, Mac OSX||AES 256-bit||Good!|
|FireFox v8+||Windows XP & Vista, Mac OSX||AES 256-bit||Good!|
|FireFox v3.0.5||Windows XP & Vista, Mac OSX||AES 256-bit||Good!|
|Safari v8+||Windows Vista/7, Mac OSX||AES 256-bit||Good|
|Safari v5.1.2||Windows Vista/7, Mac OSX||AES 128-bit||Good|
|Safari v3.2.1||Windows Vista, Mac OSX||AES 128-bit||Good|
|Safari v3.2.1||Windows XP||RC4 128-bit||Fair|
|Chrome v40+||Windows Vista/7, Mac OSX||AES 256-bit||Good!|
|Chrome v15+||Windows Vista/7, Mac OSX||AES 256-bit||Good!|
|Chrome v1.x||Windows Vista||AES 128-bit||Good|
|Chrome v1.x||Windows XP||RC4 128-bit||Fair|
|Internet Explorer v11||Windows 7||AES 256-bit||Good|
|Internet Explorer v9||Windows 7||AES 128-bit||Good|
|Internet Explorer v9||Windows Vista||RC4 128-bit||Fair|
|Internet Explorer v7 & v8||Windows Vista||AES 128-bit||Good|
|Internet Explorer v8||Windows XP||RC4 128-bit||Fair|
|Internet Explorer v7||Windows XP||RC4 128-bit||Fair|
|Internet Explorer v6||Windows XP||RC4 128-bit||Fair|
|Opera v26+||Mac OSX||AES 256-bit||Good!|
|Opera v11.10+||Windows Vista||AES 256-bit||Good!|
|Opera v9.62||Windows XP & Vista||AES 256-bit||Good!|
So, by default, only some browsers will take advantage of AES encryption, when available. We also see that any program that uses the windows default SSL libraries, will use RC4 in Windows XP and 128-bit AES in Windows Vista. So, anyone using Windows XP (or 2000) should really use a program that includes its own SSL cipher management (i.e. FireFox, Opera).
What encryption techniques are supported by modern email programs?
Asking this question about web browsers begs the question as to what is supported by the various email programs out there. Clearly, if you are using a WebMail interface to your email, then the answer depends on what web browser you are using.
Note that email connections are not subject to The Beast attack.
We tested several popular email programs to see what encryption cipher they end up using when connected to a server like LuxSci’s that supports a variety of strong ciphers.1 Here are the results:
|Email Program||Operating System||Verdict?||Results|
|Mozilla Thunderbird v2+||Windows XP & Vista||Good!||256-bit AES|
|Thunderbird v2+||Mac OSX v10.4.11||Good!||256-bit AES|
|Outlook 2010||Windows 7||Good!||256-bit AES|
|Outlook 2007||Windows XP||Fair||128-bit RC4 is the best supported|
|Outlook 2007||Windows Vista||Good||128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and thus not used)|
|Outlook 2003||Windows XP||Fair||128-bit RC4 is the best supported|
|Mail.app||Mac OSX v10.10||Good||256-bit AES|
|Mail.app||Mac OSX v10.5.5||Good||128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and thus not used)|
|Mail.app||Mac OSX v10.4.11||Good||128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and thus not used)|
|Mail.app||iPhone v2.2||Good||128-bit AES chosen (though 256-bit is there, it is not listed 1st in the program and thus not used)|
|Eudora v7||Windows XP||Good||256-bit AES|
|Eudora v8||Mac OSX v10.4||Good||256-bit AES|
|Entourage v12||Mac OSX v10.4||Fair||DES|
We see a similar pattern here. For most cases, the cipher used depends on the Operating System and not the program. Some programs roll their own SSL (i.e. Thunderbird/Eudora) and some use the OS built-in libraries. So, from this we can infer that any newer version of Outlook on Vista or Windows 7+ will go for at least 128bit AES, most things on Windows XP will use 128bit RC4, etc.
How to force use of 256-bit AES for secure web and secure email
As discussed above, the choice of email client is the prime determination of what encryption cipher will be used. So, for example, if you use Mozilla Firefox or Opera for web browsing and Mozilla Thunderbird for email, you will be using 256-bit AES encryption, as long as it is supported by the server.
However, if you would like to go a step further and be sure that you do not make any secure connection unless 256-bit AES encryption is used, that is also possible. This level of security is needed if your organization mandates that secure connections use 256-bit AES, or if you do not trust that all of the servers which you connect to will have good security ciphers in place.
It is also useful if the web sites that you are connecting to have prioritized RC4 over AES, but your know that your browser is safe from The Beast attack (e.g. you are using TLS v1.1+) and you would prefer AES. Currently, the most recent versions of almost all all modern browsers (e.g. Internet Explorer, FireFox, Chrome, Opera) are safe from The Beast. Also, old browsers will be affected by The Beast.
Following the instructions below, you can be sure that 256-bit AES will be used for all secure connections; the connections will flat out fail if the server doesn’t support this encryption technique. If you have instructions appropriate for other operating systems or programs, please drop us a comment!
Note that if your remove RC4 cipher support, you may not be able to connect to some web sites — ones that require RC4 and do not present other options. They are out there — the pizza place near our offices where we can order lunch online is one example.
- Type “about:config” in the address bar to open up the detailed list of configuration parameters.
- Make sure that “security.tls.version.min” is “1” to turn off support for SSLv2 and SSLv3.
- Search for “security.ssl3“
- Change to “false” the value for all ciphers that do not include “aes_256″ in the name (e.g. the RC4, camellia and des ones). This will make them no longer available for use.
- You will be left with various versions of AES 256 with TLS v1.0+.
- You don’t even have to restart Firefox for this to take effect!
Note that there is a cool plugin for FireFox called “CipherFox” that allows you to view the cipher information for any site you are connected to.
Mozilla Thunderbird: (see also optimization tips for Thunderbird)
- Select “Options” from the “Tools” menu
- Under the “General” section of the “Advanced” tab of the resulting “Options” dialog box, click on the “Config Editor…” button.
- Follow the same instructions as for Firefox in terms of disabling SSL2 and SSLv3, and turning off all ciphers that do not include “aes_256″ in the name.
- Restart Thunderbird so that any persistent connections are broken and re-opened.
- Make sure that your email accounts are all configured to use SSL or TLS (not “if available”, but “always”).
- If possible at your email provider, disallow insecure connections to your account altogether. This will make the connection fail even if the email program is accidently configured to make a secure connection. (LuxSci allows this to be set on the user-level or to be enforced by policy account-wide).
Chome generally uses whatever SSL support is available via your computer operating system. So, if you change the cipher order or remove RC4 via the operating system (see below), that should solve the issue for your in Chrome.
We have found that if you startup Chrome with some additional command line parameters, you force TLS v1.0+ and can block use of certain ciphers. E.g. adding this to your Chrome shortcut (as the “Arguments”) or command-line
will block RC4 usage.
To disable RC4 or make AES256 be the main cipher, you will need to change the cipher support in your Windows Operating Sysem. See below for how.
- Off topic, but Skype uses 256-bit AES encryption, so if you use it for chat or voice calls, your data is also being encrypted in this fashion.
Windows Vista, Windows 7+
Windows Vista and higher, we have seen, does support 256-bit AES, but it publishes 128-bit first in the list and thus this is what is used by most applications in a Windows environment that rely on Windows’ built-in SSL libraries (i.e. Internet Explorer, Chrome, Outlook, etc.).
If you have Windows “Small Business Edition” or better, you can remove ciphers that you do not want and change the order of their presentation by using the “group policy editor”. For example, to make 256-bit AES the default choice, rather than 128-bit AES or RC4, follow these instructions:
- Open your group policy editor by entering gpedit.msc at a command prompt.
- Choose Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
- There’s only one item here: SSL Cipher Suite Order. Open it.
- Select Enabled.
- Now here’s where you need to tread carefully. You’ll see that the list is the same as above, but rather than formatted nicely with carriage returns, they’re simply separated with commas. The first item in the list is:
And the second item is:
Cursor your way through the list. Change that first 128 to 256. Then cursor forward a bit more and change the 256 to 128. (If you can’t edit or type — copy the value, paste it into Notepad, edit it there, then paste it back in the field).
- If you want to get rid of RC4 and other non-AES ciphers, so that your computer uses AES instead of RC4, and you know that your browsers are safe from The Beast, remove the RC4 items in the list as well. E.g. TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, and SSL_CK_RC4_128_WITH_MD5
- Feel free to change other orders, too, but keep your changes within algorithm types.
- OK your way out, close the group policy editor, and reboot.
Similarly, you can use the same procedure to remove all ciphers that are not wanted and thus lock down Windows to AES-only encryption or 256-bit AES only encryption.
However, for those of us who have Home Basic or Home Premium Edition, there is no “group policy editor” (and if you copy it from another Windows, it won’t run) and it is thus much harder to make this change. All of the settings that you would be changing above are found in the Windows Registry and can be changed directly therein. We are not going to go into how to do this here, as it is not for the faint of heart. (See this link for more information on how to do this.)
If you are unsure what version of Windows you have, try the instructions, above, and see if the gpedit.msc brings up a dialog box.
Locking down your web site (in Apache)
If you are the owner of a web site and have SSL security on it, you can “lock it down” so that the only cipher that your web site supports is “256-bit AES”. This takes the choice out of the end user’s hands — either they use AES or they don’t connect securely. This is a good thing to do for very sensitive sites. However, the “danger” is that some of your users may be using web browsers that do not support AES (like old versions Internet Explorer), and thus will not have any access to your site unless they change browsers.
To lock your site down to support 128-bit and 256-bit AES only (to get AES but not require 256-bit, so that some browsers like iPhone and such will work), you would add to your Apache httpd.conf file:
This can be added globally, in a virtual host, or even in your .htaccess file. It will ensure that any successful connection to your site will use one of these ciphers. Just be sure to add it to the secure settings for your site and not just the insecure site area! See more information here.
In general, for a high security configuration for Apache, you will want to support only TLS v1.0+ and only NIST-recommended cipher suites. See: what level of TLS is required for HIPAA.
AES encryption is the way to go when using SSL, if you have any choice about it. It won’t really affect speed or performance as long as your computer is not ancient. If you have qualms about security, we highly recommend using a web browser and/or email client that will enable use of AES (which these days includes all modern programs).
Note that SSL and TLS protect only the data sent between you and the server. When you send and receive email, the message data travels over the Internet between the sender and recipient and will be unprotected, no matter how good your SSL is. For details on this, read The Case for Email Security. The solution in this situation, is to use an end-to-end email encryption solution, like LuxSci’s SecureLine, in addition to SSL (SecureLine protects the message content, SSL protects your username and password).
1 For actual email programs, we tested by running an “openssl” server on a secure IMAP port with debugging enabled. This logged the encryption techniques (ciphers) shared by the client and server as well as the one chosen.