RC4 officially deprecated by RFC 7465

A new RFC 7465 has now been published that effectively calls for disabling RC4 everywhere:

   o  TLS clients MUST NOT include RC4 cipher suites in the ClientHello message.

   o  TLS servers MUST NOT select an RC4 cipher suite when a TLS client
      sends such a cipher suite in the ClientHello message.

   o  If the TLS client only offers RC4 cipher suites, the TLS server
      MUST terminate the handshake.  The TLS server MAY send the
      insufficient_security fatal alert in this case.

Cryptographic weaknesses around RC4 were known since many years, but in the beginning of 2013 they finally became feasible to exploit with some considerable, but not too huge of an effort.
The author of the RFC belongs to Microsoft, which published and advisory for disabling RC4 in November 2013 as well. However, Windows Server 2012 R2 with IIS 8.5 which was released in October 2013 still ships with RC4 enabled by default.

A lot of websites and “modern” software still use RC4 today. According to the SSL-Pulse statistics currently more than 60% of all SSL/TLS enabled websites still offer RC4.

It depends on the service and the security requirements, but at the moment I personally don’t see it that much of a problem in offering RC4 as a fallback, if you always prefer other secure ciphers.

Here are some examples of software or websites that still use RC4 in a manner it shouldn’t be used:

  • PayPal (server prefers RC4, though offers AES as well)
  • Youtube (the servers providing the actual video streams, not the general site; RC4 exclusively(!)) I Tested it last week but it seems like Youtube switched to offering and preferring other AES-based cipher suites just recently.
  • All versions of Windows Server and Client OSes, including the respective Internet Explorer enable RC4 by default
  • Some VMware products (at least the vCenter Web Client, and many virtual appliances; most seem to prefer AES though; ESXi hosts and vCenter service on port 443 and SSO on 7444 do not support RC4)
  • HP ILO interfaces (confirmed with ILO4 2.03, ILO3 1.80; prefers RC4)
  • Cisco IronPort Mail appliances seem to be using RC4 exclusively(!)
  • Check Point Gaia Portal web interface (tested with R77.20 with JHFA Take 77; RC4 exclusively(!))

Seems like there’s a lot of work waiting for vendors and website admins to disable RC4.
It’s a mystery to me how some popular websites or recent software releases can be released without support for any cipher suite besides RC4. And no, mitigating BEAST is not a valid excuse.

Replacing the IWSVA Admin Web Interface SSL Certificate

Since documentation on this by Trend Micro is pretty sparse and I’ve had to do this on a number of systems recently, I’ll document the process of replacing or adding a certificate for the IWSVA Admin Web Console with a new CA-signed one here.

Note: This documentation is NOT for replacing the IWSVA SSL-Inspection certificate, though similarities may exist.
I’ve done this successfully on IWSVA 5.6 and 6.5, the process should work without issues on IWSVA 6.0 as well.

The whole process of requesting/creating/converting the SSL certificate described here mainly involves openssl commands and can be done from the IWSVA root shell. I also generally recommend to create at least the certificate public/private key pair always on the system that will in the end host the certificate. This reduces the risk of getting the private key compromised when you create key pairs on a different system and then have to somehow transfer the key over the network or some other way (yes, you can encrypt the keys, but it’s best if the key never left the target system in the first place).

Continue reading

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:

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

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.

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.
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.

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
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 
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: