Secure Cipher-Suites for Qualys SSL Labs server test A/A+ rating

There are many possible ways to configure your server to support only secure cipher-suites and get an A/A+ rating from the SSL Labs SSL Test, some are more restrictive than others, some are more complex than others.

There is no single holy grail, but for openssl-based applications such as Apache, postfix, or nginx, I prefer to go with this to me personally more readable and to me more sensible general notation:
HIGH:!aNULL:!eNULL:!kECDH:!aDH:!RC4:!3DES:!CAMELLIA:!MD5:!PSK:!SRP:!KRB5:@STRENGTH

Checking the openssl documentation, this boils down to the following logic:

  • Only enable strong (High) encryption cipher suites (at least 128 bit length)
  • Exclude cipher-suites without authentication (aNULL) or without encryption (eNULL)
  • Exclude fixed/static ECDHE (kECDH) instead of ephemeral ECDHE keys (no PFS, rarely used)
  • Exclude cipher-suites using DH authentication (aDH), which is rarely used and needs the certificate to have static DH keys
  • Exclude RC4 and 3DES cipher-suites which are known to be weak or outdated
  • Exclude Camellia cipher-suites, which is rarely used/preferred by clients/servers when AES is already supported. AES is the de-facto standard
  • Exclude outdated cipher-suites using weak MD5 HMAC
  • Exclude cipher-suites used extremely rarely or only in very specific applications like Secure Remote Password authentication (SRP), PSK (Pre-Shared Key) and KRB5 (Kerberos5, also supports only old ciphers/HMAC)
  • Sort the cipher list by strength

With at least the recent openssl 1.0.1j version, this will enable a broad range of 30 secure AES-based ciphers suites, including some basic non-PFS AES suites for compatibility reasons (decide for yourself if you’re OK with this). This guarantees an SSL test rating of at least A.
If you really need to support older clients, then you could also consider leaving 3DES enabled.
Note: To get an A+ rating currently your certificate must have a SHA-256 chain and the server also needs to support TLS Fallback SCSV and apparently HTTP Strict Transport Security as well.

Continue reading

Advertisements

[Script] Extending Linux LVM partitions

Here’s a script I wrote a while a go to extend LVM partitions on Linux machines.

The script assumes that you have extended the existing underlying physical (or “virtual” if it’s a VM) storage device prior to execution. It will rescan the disks (skip with -f), resize the existing partition (basically just setting a different end sector), reboot, and run scripts to extend the actual file system after the reboot. There are other ways to extend the disk space including creating a new partition on the additional disk space, but I’ve decided against that approach in favor of a single-partition scheme for management/simplicity’s sake.

This script will work with VMs and physical servers alike. I’ve tested it with RHEL 6/7 and CentOS 6/7, but it should generally work with other Linux distributions as well.

You can get the most recent version of this script on Github here. If you have any suggestions or improvements (which I’m sure there is plenty of room for), feel free to drop a comment or an issue or a pull-request on Github.

Continue reading

THC SSL Renegotiation DoS Tool for SMTP STARTTLS

The so called Secure Client-Initiated Renegotiation function of SSL/TLS suffers from a possible DoS danger because it burdens the server’s CPU orders of magnitude more than the client’s, who initiates it. Because of that, Client-Initiated Renegotiation is nowadays disabled by default in virtually all widely used SSL/TLS implementations.

However, I noticed that it seems to be still enabled by default on the postfix SMTP daemon including recent releases (postfix 2.6.6) and openssl (1.0.1j) versions and there appears to be no way of disabling it in the configuration. Since I already used the thc ssl dos tool which exploits this vulnerability in previous penetration tests on webservers, I thought it would be nice if it worked with SMTP mailservers supporting STARTTLS as well.

Continue reading

MS14-066 / CVE-2014-6321

[Update 2014/11/18]
Details of the vulnerability have been released. If you still haven’t patched internet-facing Windows systems, do it ASAP.
[Update]

After all the (well, partly justified) rage and criticism openssl or free/open source software in general received recently with fuckups like the heartbleed, changecipherspec or shellshock vulnerabilities, it’s been about time for a major vulnerability of a similar scale in our most beloved Windows systems.

This security update resolves a privately reported vulnerability in the Microsoft Secure Channel (Schannel) security package in Windows. The vulnerability could allow remote code execution if an attacker sends specially crafted packets to a Windows server.
The security update addresses the vulnerability by correcting how Schannel sanitizes specially crafted packets.Mitigating Factors
Microsoft has not identified any mitigating factors for this vulnerability.
Workarounds
Microsoft has not identified any workarounds for this vulnerability.
FAQWhat might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability could run arbitrary code on a target server.

How could an attacker exploit the vulnerability?
An attacker could attempt to exploit this vulnerability by sending specially crafted packets to a Windows server.

What systems are primarily at risk from the vulnerability?
Server and workstation systems that are running an affected version of Schannel are primarily at risk.

Oh? What do we have here? Is this an unauthenticated remote code execution vulnerability in the schannel Windows SSL/TLS library, affecting every Windows version since 2003 (probably XP and maybe 2000 as well)?. Let the SSL/TLS fuzzing begin; it’s probably only a matter of time until a PoC exploit is published (if it isn’t already in some secret channels, this was “privately reported”). Patch that stuff now.
Incidentally, this update also adds two new TLS 1.2 cipher suites to the schannel repository.

SSL POODLE Attack – What is SCSV and how does it help?

The POODLE vulnerability is currently the hot topic in the security world. Here is a nice technical overview by the Google SSL Guru. POODLE relies on SSLv3, but today nearly every server and client supports at least TLS 1.0 in addition to SSLv3, which means SSLv3 connections should (and in fact are) be rather rare. But there is still a threat because of downgrade compatibility between the protocols. With POODLE, a rather new SSL/TLS enhancement to mitigate protocol downgrade attacks has been mentioned a lot recently.

[Update 2014/12/09]
Recent developments show that the POODLE attack, which originally was only thought to be applicable CBC cipher-suites in SSLv3 connections, can in some cases be extended to TLS1+ (ALL TLS versions) connections as well. This time however, it is not due to a general protocol weakness in TLS, but because of specific flawed software implementations that just ported certain functions from their SSLv3 code over to TLS, without considering the improved CBC padding specifications of TLS.
Currently known to be affected are load balancers from F5 and A10, as well as Cisco devices , some Check point Firewall components and IBM HTTP Server.
[/Update]

TLS Fallback Signaling Cipher Suite Value prevents SSL/TLS protocol downgrades a man-in-the-middle can enforce when both sides actually support higher protocol versions.
For example, a Client sends a Client Hello handshake message that indicates support for TLS 1.2. Normally the server responds with its own highest protocol version in the Server Hello handshake message, and that will be the negotiated SSL/TLS version of the connection. If the server supports TLS 1.2 as well, the connection will use this protocol. If the server supports a lower version, the connection will use this instead (provided the client supports it as well of course).
Now an attacker who is able to intercept and alter traffic between the systems can screw up the handshake process and make it fail with arbitrary network errors (think: TCP RST). In this case the client often retries the connection with a lower initial SSL/TLS protocol version, say SSLv3 or TLS1, which makes it easier for the bad guy to attack the encrypted channel.

To prevent this kind of protocol downgrade attack, TLS Fallback SCSV was developed. Here’s a short overview of how it works:
Both, the client and server need to support it to make it work. TLS Fallback SCSV is used as a signaling cipher suite (TLS_FALLBACK_SCSV, value 0x5600) during the handshake. A signaling cipher suite does not provide actual encryption algorithms like other, “normal” cipher suites such as “TLS_RSA_WITH_AES_128_CBC_SHA” or “TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256or others. Instead they are used as simple protocol controls, similar to TLS extensions. A client can include the “TLS_FALLBACK_SCSV” cipher suite in his Client Hello message to tell the server, that the connection should only be established if the highest protocol version supported by the server is identical to or lower than that of what it sees in the Client Hello. So if the server supports TLS 1.2 but the Client Hello uses SSL3, TLS 1.0 or TLS 1.1, then the server should respond with an “inappropriate fallback”  TLS alert message.
The nitty gritty details of SCSV can be read in the IETF draft.
Note that TLS Fallback SCSV really only helps against protocol downgrade attacks, and does not actually prevent the POODLE attack by itself. POODLE is a vulnerability in SSL3, and SCSV makes it harder for the attacker to downgrade a connection to it in order to exploit that vulnerability.

Here is an example of a failed handshake between a TLS 1.2 server supporting SCSV and a client using TLS 1.1 supporting SCSV:downgrade

Wireshark doesn’t know about this cipher suite yet so it lists it as unknown. The TLS_EMPTY_RENEGOTIATION_INFO_SCSV” signaling cipher suite is a similar safety guard to prevent an older session renegotiation vulnerability.

In contrast, this handshake completes normally with SCSV since the client supports TLS 1.2:sslnormal

You can test whether a server supports SCSV with a recent openssl version and the -fallback_scsv option. For this to work you must tell openssl to use an older protocol version than what the server actually supports via the -ssl3, -tls1 or -tls1_1 flags. If the server supports SCSV, it will terminate the connection with a TLS alert.
Here’s an example with google.com and a Google mailserver, which both support TLS 1.2 and SCSV:

$ openssl s_client -connect google.com:443 -state -fallback_scsv -tls1_1
CONNECTED(00000003)
3072415468:error:1409443E:SSL routines:SSL3_READ_BYTES:tlsv1 alert inappropriate fallback:s3_pkt.c:1257:SSL alert number 86
3072415468:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596
[...]

$ openssl s_client -connect aspmx.l.google.com.:25 -state -fallback_scsv -starttls smtp -tls1_1 
CONNECTED(00000003)
3072067308:error:1409443E:SSL routines:SSL3_READ_BYTES:tlsv1 alert inappropriate fallback:s3_pkt.c:1257:SSL alert number 86
3072067308:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
[...]

Changing the above to use TLS 1.2 instead will result in successful connections:
$ openssl s_client -connect google.com:443 -state -fallback_scsv -tls1_2
$ openssl s_client -connect aspmx.l.google.com.:25 -state -fallback_scsv -starttls smtp -tls1_2

The SSL Labs online test will also tell you if your server supports SCSV.

If you use an Apache webserver with mod_ssl and one of the recent openssl versions, it should already support SCSV by default. The same goes for my postfix mailserver that depends on openssl and supports SCSV out of the box. I tested this on my own CentOS with openssl-1.0.1e-30.el6_5.2.i686. (Remember, you should restart the services after updating openssl.)

Currently (as of October 2014), of the 3 major browsers only Chrome supports SCSV. Firefox is supposed to add support with version 35, IE does not support it and I’m not aware of any concrete roadmap to include it.

In the meantime, you should seriously consider disabling obsolete SSLv3 on the client and server side of your networks. Firefox will disable SSLv3 by default in Firefox 34 (release November 2014) and Google plans to follow in the next months with Chrome.
SSLv3 is officially dead now.

This is what such an error looks like to the user in Firefox 34 (ESR), when the browser receives a TLS alert from the web server:
ssl_error_inappropriate_fallback_alert

TMG “502 Proxy Error. The data is invalid” while downloading Windows 8.1/2012R2 Update KB2919355

Recently I ran into an odd issue when trying to download the KB2919355 Update bundle from Microsoft. The problem affected WSUS and local Windows Update clients that used TMG as their explicit proxy and was reproducible with browsers as well:
The TMG proxy threw 502 Proxy Error ( The data is invalid.  ) when trying to access various different hosts and URLs serving the same update file such as these:
http://au.v4.download.windowsupdate.com/d/msdownload/update/software/crup/2014/02/windows8.1-kb2919355-x64_66955196a82751d1c8d9806d321487562b159f41.psf
http://fg.v4.download.windowsupdate.com/d/msdownload/update/software/crup/2014/02/windows8.1-kb2919355-x64_66955196a82751d1c8d9806d321487562b159f41.psf
http://wsus.ds.download.windowsupdate.com/d/msdownload/update/software/crup/2014/02/windows8.1-kb2919355-x64_66955196a82751d1c8d9806d321487562b159f41.psf

Strange enough the problem did not occur in transparent proxy mode.

I first suspected the problem was related to the issue described here, but in my case neither HTTP compression nor chunked transfer-encoding are used, thus this article and its explanation do not apply.

First let’s have a look at a normal response (bypassing the Proxy/transparent mode). We can see the file is approximately 3.8GiB in size, quite big but I’ve downloaded larger files without issues. There are no strange HTTP headers or anything sent by the servers (goes for GETs as well) and everything looks just fine:

 $ curl -I 'http://wsus.ds.download.windowsupdate.com/d/msdownload/update/software/crup/2014/02/windows8.1-kb2919355-x64_66955196a82751d1c8d9806d321487562b159f41.psf'
HTTP/1.1 200 OK
Via: 1.1 TMGPROXY01
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
Content-Length: 4052160113
Date: Mon, 13 Oct 2014 11:12:31 GMT
Content-Type: application/octet-stream
ETag: "0cabe2eb931cf1:0"
Server: Microsoft-IIS/7.5
Accept-Ranges: bytes
Last-Modified: Mon, 24 Feb 2014 23:36:04 GMT
X-Powered-By: ASP.NET
X-CCC: IT
X-CID: 2

Continue reading

Illegal OpCode Red Screen of Death while booting a HP Proliant server from an USB SD card

[Update]
As per Jason’s comment, with a new ILO4 update HP apparently has fixed an issue related to booting from SD cards. Whether this is the same issue is unclear though since the original KB article I linked to has not been updated.
[/Update]

Important note: The general symptom of such a Red Screen of Death described here is NOT specific to ESXi or booting from SD cards in general. It can happen with Windows, Linux or any other OS as well as other boot media such as normal disks/RAID arrays, if the server has a problem booting from this device (broken boot sector/partition/boot loader etc).

A couple of weeks ago I was updating a few HP Proliant DL360p Gen8 servers running ESXi on a local SD card with ESXi patches via VUM, so business as usual. Almost, because on one of the servers I ran into the following issue:
After rebooting the host, the BIOS POST completed fine and the Proliant DL360p Gen8 server should now boot the ESXi OS from it’s attached USB SD card where ESXi was installed; but instead it displayed this unsightly screen telling  something went very, very wrong:

iloillegalopcodeI reset the server several times via iLO but the issue persisted and I had no idea what exactly went bonkers here. Then I decided to boot a Linux live image, which worked fine, narrowing down the issue to the OS installation (device) itself. I thought the updates corrupted the installation but that actually wasn’t the case.
When attempting to mount the SD card USB drive from within the live Linux I noticed it was actually completely absent from the system. The USB bus was still ok, but lsusb showed no SD card reader device in the system at all!

Continue reading