Compass SSL/TLS recommendations

Mozilla created an extensive page [7] concerning the best current choice of SSL/TLS cipher suites, primarily for web servers. Compass Security agrees broadly with the article, but recommends some additional restrictions in order to provide the most resistance against active and passive attacks versus TLS secured connections:

  • Use 3DES cipher instead of RC4
  • Disable SSLv3 support

Compass Security recommends against using RC4, and favors 3DES for a transitional period. 3DES only provides 112 bit keys (and may therefore be more prone to brute force attacks on the key), but is otherwise regarded as not (yet) broken. RC4, on the other hand, is considered not secure anymore:

  • A “nearly practical” attack exists, as the first bytes of the stream cipher are biased (not perfectly random)[4]
  • Microsoft recommends to disable it, and warns developers to not use it anymore [1]
  • The NSA is suspected to be able to decrypt it in real-time [2][3]
  • RC4 was primarily used to thwart BEAST and Lucky13 attacks. But BEAST is fixed on current browsers. Exploiting Lucky13 is currently not practically feasible [6]

For additional security, it is possible to remove SSLv3 support altogether, as it contains several weaknesses:

  • Weaker key derivation process than TLS
  • Cannot be validated under FIPS 140-2
  • There have been various attacks on SSLv3 implementations
  • Vulnerable to certain protocol downgrade attacks

TLSv1.0, which was released in 1999, contains several additional security features in comparison to SSLv3. For example, it uses both SHA-1 and MD5 at the same time, making it less vulnerable if one of these hash functions becomes insecure.

All browsers, except IE6 on Windows XP (in its default configuration) support at least TLSv1.0. The default IE8 browser on an up-to-date Windows XP, happily connects to TLS-only web servers. Nevertheless, other software may not be compatible with such an restricted configuration yet.

Furthermore it is recommended to turn off TLS compression. This will fix the CRIME attack on TLS connections, even if vulnerable OpenSSL implementation on the server is being used, while an obsolete browsers which do not have this issue fixed is connected. If the server uses current OpenSSL library, and/or the client has the CRIME fix implemented, this attack is not feasiable anyway. Turning off TLS compression will not mitigate the BREACH attack, as it uses the compression feature of HTTP, not TLS. See [12] for further information about this issue.

This concludes the discussion about most of the currently known SSL/TLS attacks, and their mitigation.

Update April 2015: Web Server configuration generator

An up to date and detailed Apache SSL/TLS configuration generator can be found here: Mozilla SSL Configuration Generator. Mozilla changed their opinion on RC4, and also switched to 3DES for backwards compatibility.

Apache Configuration

The following chapter provides an Apache configuration example, which incorporates the discussion above. It is based on

The implemented cipher prioritization logic is as follows:

  1. Most secure TLS 1.2 ciphers first: AES-GCM
  2. AES with PFS: ECDHE (Elliptic Curves)
  3. AES with PFS: DHE (Traditional RSA)
  4. AES128
  5. AES256
  6. 3DES

The cipher prioritization list:


Virtual host SSL configuration:

<VirtualHost *:443>
    SSLProtocol             All -SSLv2 –SSLv3
    SSLCipherSuite          <recommended ciphersuite from above>
    SSLHonorCipherOrder     on
    SSLCompression          off # default off, except in 2.4.3 and 2.2.24 to 2.2.25
    SSLInsecureRenegotiation off # default

This TLS- and AES/3DES-only configuration was successfully tested with current versions of IE8, Chrome and Firefox on Windows XP.

Windows IIS

Example configuration settings for Windows. This should act as a basic configuration skeleton. Before deployment, the configuration needs to be actively tested in an production environment. The cipher list has been extracted on a Windows 7, but is identical to that of a Windows 2012 Server.

Disabling SSLv2 and SSLv3:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server] 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server] 

Cipher list:

  10. RSA AES
  11. RSA 3DES

Configure Schannel according to the recommendations above and these pages:

Update February 2015: TLS1.0 discussion

With the discovery of the POODLE attack, it is now widely recommended to disable SSLv3 support. But it is important to realize that neither TLS 1.0 or TLS 1.1 are considered secure. Especially TLS1.0 contains only small improvements over SSLv3.

Luckily, TLS 1.1 does not have any publicly known protocol problems. Nevertheless, TLS 1.2 implements stronger and more trustworthy algorithms. For example TLS 1.1 uses SHA1/MD5 in the pseudorandom function, both of them are considered broken. TLS 1.2 uses SHA2. It also supports the new GCM ciphers, which are more resistant against certain attacks than CBC ciphers.

Sadly, the support for TLS1.1 for Internet Explorer in its default configuration is only available for IE11 on Windows 7 and higher. Schannel supports TLS1.1 from Windows 7 onwards, which includes IE7/8/9, but is not active “out of the box”. Therefore it is not possible for Compass to recommend TLS1.1/1.2-only public facing websites, even if security considerations dictate so. Nevertheless for web interfaces where the supported user-base is known, it should be evaluated to disable TLS1.0, and even TLS1.1. For example a public facing firewall configuration web interface, where all users of it are known to have Chrome installed.

Further Recommendations

This renewal in favor of more secure SSL ciphers can be a good opportunity to kick-off further clarifications and investigations about SSL related topics in your company, e.g.:

  • Is all your web infrastructure (proxies, WAFs, web servers, …) ready to support TLSv1.1 and TLSv1.2?
  • Are the clients you manage use an adequate configuration for setting up SSL communication (e.g. Prioritizing Schannel Cipher Suites for Windows clients)
  • Does your SSL certificate use at least a 2048 bit private key?
  • Do your CA SSL certificates use at least 4096 bit private keys?
  • Does your internal PKI enforce best practices and is moving to SHA2 and ECC? [10][11]
  • Are you using the most current version of the webserver?
  • Are you using the most current version of OpenSSL?


  1. Microsoft recommends disabling RC4
  2. Article about suspicious that NSA is able to decrypt RC4
  3. Article about suspicious that NSA is able to decrypt RC4, german
  4. Bruce Schneier about attack on RC4 from spring 2013
  5. Discussion “RC4 is kind of broken in TLS”
  6. Qualys Discussion about retiring RC4
  7. Mozilla Article about SSL ciphers
  8. Qualys SSL Test
  9. Web Browser Support Matrix
  10. MS SHA1 deprecation policy
  11. Windows Root Certificate Program – Technical Requirements version 2.0
  12. Nginx SSL Module
  13. Qualys – Defending against the BREACH Attack

Thanks to Alexandre Herzog for research, review and discussions concerning this matter.

Dangerous Sudoers Entries – PART 5: Recapitulation

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

Define the allowed “sudo” commands carefully. Don’t allow commands to be run without knowing all the features it offers.

1. Disallow the execution of further commands by adding the “NOEXEC” flag:

hacker10 ALL= (root) NOEXEC: /bin/less /var/log/*

2. Check if the feature set of the command can be restricted. E.g. check for environment variables shown “LESSSECURE=1” for “less”:

Defaults        env_reset, env_keep=LESSSECURE

3. Check the file permissions carefully as this might render all your efforts useless:

4. Only use wildcards when you know that a breakout will be impossible.

The first example shows how to access the “/etc/passwd” file directly:

The second example shows how to open an additional file which can later be accessed by typing “:n” in “less”:

By following these rules you might avoid a malicious user to gain further privileges on your system.


Dangerous Sudoers Entries – PART 4: Wildcards

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

The last issue with our example “sudo” command is the wildcard (*).

Excerpt from the “sudoers” man page:


sudo allows shell-style wildcards (aka meta or glob characters)
to be used in hostnames, pathnames and command line arguments in
the sudoers file. Wildcard matching is done via the POSIX glob(3)
and fnmatch(3) routines.  Note that these are not regular
*       Matches any set of zero or more characters.
?       Matches any single character.
[...]   Matches any character in the specified range.
[!...]  Matches any character not in the specified range.
\x      For any character "x", evaluates to "x". This is used to
        escape special characters such as: "*", "?", "[", and "}".
POSIX character classes may also be used if your system's glob(3)
and fnmatch(3) functions support them.  However, because the ':'
character has special meaning in sudoers, it must be escaped.
For example:
/bin/ls [[\:alpha\:]]*
Would match any filename beginning with a letter.
Note that a forward slash ('/') will not be matched by wildcards
used in the pathname. When matching the command line arguments,
however, a slash does get matched by wildcards. This is to make
a path like:
match /usr/bin/who but not /usr/bin/X11/xterm.
Exceptions to wildcard rules
The following exceptions apply to the above rules:
""      If the empty string "" is the only command line argument
in the sudoers entry it means that command is not allowed to be
run with any arguments.

As the wildcard in our example is part of the arguments and not the path name, it allows us to break out. One way to do this is shown in the following example:

Another way to break out would be the following command:

When in less it is possible to use the “:n” command to switch to the next file in the file list:


Wildcards are extremely dangerous. Don’t use them if you are not 100% sure that a malicious user is able to abuse it.

The more secure solution to the issue would be to write a script which does input validation and is the only thing that is allowed to be called using “sudo”.

Dangerous Sudoers Entries – PART 3: Permissions

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

Another pitfall of securing “sudo” commands are the file system permissions. If the permissions aren’t set correctly, an attacker might circumvent the restrictions we have implemented during the last two blog posts. For the next example the administrator changed the directory permissions for the directory “/var/log/” to “777”. Obviously, this is a bad idea for this directory and a almost unrealistic scenario. None the less, this situation might appear if we use an application specific directory which has been configured manually.

Because of the write permissions in this directory we are allowed to create arbitrary files in it. This allows us to create links to files residing in other directories. This will grant us access to the linked file once we use “less” as user root:

“less” shows us the following content when the previous command is executed:

Furthermore, ensure that the user has no write permissions on the executable.


The only solution to this issue is setting appropriate permissions on the file system!

Dangerous Sudoers Entries – PART 2: Insecure Functionality

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

In this article we are going to focus on insecure functionality “less” offers. The example with “less” is just to illustrate that the functionality of each application we use with “sudo” has to be checked carefully to ensure that a malicious user won’t be able to abuse it.

“less” offers a command to read other files on the system. Again, the current permissions of “less” are used to read these files.

Excerpt from the man page:

:e [filename]

Examine a new file. If the filename is missing, the "current" file
(see the :n and :p commands below) from the list of files in the
command line is re-examined. A percent sign (%) in the filename
is replaced by the name of the current file. A pound sign (#) is
replaced by the name of the previously examined file. However, two
consecutive percent signs are simply replaced with a single percent
sign. This allows you to enter a filename that contains a percent
sign in the name. Similarly, two consecutive pound signs are
replaced with a single pound sign. The filename is inserted into
the command line list of files so that it can be seen by subsequent
:n and :p commands. If the filename consists of several files, they
are all inserted into the list of files and the first one is
examined. If the filename contains one or more spaces, the entire
filename should be enclosed in double quotes (also see the -"

In the following example the /etc/shadow file has been read.


The environment variable “LESSSECURE” can be set to “1” to disable dangerous features of “less”.

Excerpt from the man pages:

When the environment variable LESSSECURE is set to 1, less
runs in a "secure" mode. This means these features are disabled:
!      the shell command
|      the pipe command
:e     the examine command.
v      the editing command
s -o  log files
-k     use of lesskey files
-t     use of tags files
metacharacters in filenames, such as *
filename completion (TAB, ^L)
Less can also be compiled to be permanently in "secure" mode.

There are now two steps we have to take to ensure that this works as expected. First, the current user must have the “LESSSECURE” environment variable set as read-only. Otherwise the user would be able to change its value. This can be achieved by adding the following line to a file in the path “/etc/profile.d/”. We use a new file called “/etc/profile.d/” and add the following content:


The second step is to tell “sudo” to keep the “LESSSECURE” variable from the user. This is achieved by adding the env_keep option in the sudoer’s file:

Defaults        env_reset, env_keep=LESSSECURE

The following message appears now if someone tries to use one of the insecure commands.

Dangerous Sudoers Entries – PART 1: Command Execution

The following article describes common security issues regarding misconfigured sudoers’ files. The article focuses on a single entry which contains several security issues:

hacker10 ALL= (root) /bin/less /var/log/*

The article is split into the following five chapters:

In this article we are going to focus on the command execution feature of “less” which may appear in other applications and scenarios as well. “less” allows a user to execute arbitrary commands by entering “!”.

Excerpt from the less man page:

! shell-command

Invokes a shell to run the shell-command given. A percent sign (%)
in the command is replaced by the name of the current file. A
pound sign (#) is replaced by the name of the previously examined
file. "!!" repeats the last shell command. "!" with no shell 
command simply invokes a shell. On Unix systems, the shell is
taken from the environment variable SHELL, or defaults to "sh".
On MS-DOS and OS/2 systems, the shell is the normal command

As an example, we run the command “whoami” within “less”:

This command is being executed with the same rights “less” is running. Therefore, whoever is allowed to read a file with less is allowed to execute commands with the same rights. In this case as the user “root”.

Another feature that falls in the category command execution is the possibility to start the default text editor as this is nothing else but the execution of another application. To start the default text editor the user has to press the “v” key.

Excerpt from the man page:

v      Invokes an editor to edit the current file being
viewed. The editor is taken from the environment variable VISUAL
if defined, or EDITOR if VISUAL is not defined, or defaults to
"vi" if neither VISUAL nor EDITOR is defined. See also the
discussion of LESSEDIT under the section on PROMPTS below.

In our case we start the editor “nano” from “less”:

Of course it is possible to prevent “less” from executing arbitrary commands. There are two possible ways to do this. The one described in this part of the blog post focuses on the general prevention of additional command execution and isn’t “less” specific. Therefore, it is possible to use this solution for other applications as well.


The execution of other binaries might be prevented by adding the NOEXEC tag in the sudoer’s file. This works only if “sudo” has been compiled with noexec support and if the underlaying OS supports this as well.

hacker10 ALL= (root) NOEXEC: /bin/less /var/log/*

The following two screenshots shows the results of the previously described methods to run an arbitrary command or default editor.