Two for the price of one

For me, the penny dropped when I realised that the Logjam paper sets out two strategies. The first is a cryptanalytic attack that uses pre-computation to speed up the process of cracking a Diffie-Hellman (DH) key exchange. The second is a protocol attack that allows weaker export-grade versions of DH-based cipher suites to be selected, so long as they are supported by the server. A man-in-the-middle attacker who can make use of the second technique can downgrade vulnerable connections, which helps the first attack by forcing the use of weaker cryptography. But an attacker doesn’t have to rely on the downgrade trick for an attack on the security of the connection to succeed. It all depends on what the attacker wants to achieve and what position they are in.

Attack scenarios

If the attacker wants to modify the data in transit then the attack must be performed in real time. The attacker must be a man-in-the-middle and have access to sufficient computing resources to perform the necessary cryptanalysis in a short space of time. To ease the cryptanalysis, if the attacker can downgrade the connection to using a 512-bit prime, then so much the better. That’s only possible if the server supports export-grade DH cipher suites. In the opinion of the Logjam authors, any 512-bit prime should be considered vulnerable but a 768-bit, and certainly a 1024-bit, DH prime would require a serious amount of effort to attack.

In contrast, decrypting (but not modifying) the secure traffic from a connection that begins with a DH key exchange can be done passively in slower time: the attacker can capture the traffic and run the cryptanalysis offline. In this case, the attacker must contend with whatever strength of DH prime was selected during the TLS negotiation, which is unlikely to be 512-bit. For passive attacks, cipher suite preference is therefore more important: if the server prefers a common cipher suite that isn’t based on the standard DH key exchange (e.g. AES256-SHA) then a passive attack is very unlikely to succeed.

Client-side fixes

As with a number of previous TLS bugs, browsers have applied plasters to the sores to try to mitigate the impact. Although the downgrade attack exploited a weakness in the TLS protocol rather than an implementation flaw, refusing to accept 512-bit DH primes is a quick and effective solution. But taking that strategy all the way up to 1024-bit primes is dangerous in terms of user experience – users could start complaining that sites are suddenly inaccessible. So the success of client-side “patching” will depend on the vendors, the minimum size of DH prime their browser accepts and the user’s update regime.

Common primes

Another factor to consider is the prime itself. The Logjam paper noted that servers tend to re-use it – and, not only that, but the same primes are in circulation across different implementations. The pre-computation work for the cryptanalysis is based on a single DH prime so it’s in the attacker’s interest to do the number crunching for primes that are most widely used. A server that uses a common prime is thus more of a target. But what are these common primes? The Logjam paper itself makes explicit reference to two 512-bit primes. A number of larger primes can be found by inspecting the JavaScript behind the server test page on the Logjam site. You can test for a dozen common primes by adding a bit of code to the file apps/s_cb.c before compiling OpenSSL. Since version 1.0.2 the default output includes a line, when appropriate, beginning “Server Temp Key”, e.g.

Insert the following lines after the line that outputs the bit length, which is BIO_printf(out, "DH, %d bits\n", EVP_PKEY_bits(key)); (line 519 for the current version 1.0.2d):

if (EVP_PKEY_bits(key) > 1024)
   break;
const char *common[12]; // common primes from https://weakdh.org/imperfect-forward-secrecy.pdf, https://weakdh.org/docheck.js
common[0] = "9FDB8B8A004544F0045F1737D0BA2E0B274CDF1A9F588218FB435316A16E374171FD19D8D8F37C39BF863FD60E3E300680A3030C6E4C3757D08F70E6AA871033";
common[1] = "D4BCD52406F69B35994B88DE5DB89682C8157F62D8F33633EE5772F11F05AB22D6B5145B9F241E5ACC31FF090A4BC71148976F76795094E71E7903529F5A824B";
common[2] = "E9E642599D355F37C97FFD3567120B8E25C9CD43E927B3A9670FBEC5D890141922D2C3B3AD2480093799869D1E846AAB49FAB0AD26D2CE6A22219D470BCE7D777D4A21FBE9C270B57F607002F3CEF8393694CF45EE3688C11A8C56AB127A3DAF";
common[3] = "D67DE440CBBBDC1936D693D34AFD0AD50C84D239A45F520BB88174CB98BCE951849F912E639C72FB13B4B4D7177E16D55AC179BA420B2A29FE324A467A635E81FF5901377BEDDCFD33168A461AAD3B72DAE8860078045B07A7DBCA7874087D1510EA9FCC9DDD330507DD62DB88AEAA747DE0F4D6E2BD68B0E7393E0F24218EB3";
common[4] = "BBBC2DCAD84674907C43FCF580E9CFDBD958A3F568B42D4B08EED4EB0FB3504C6C030276E710800C5CCBBAA8922614C5BEECA565A5FDF1D287A2BC049BE6778060E91A92A757E3048F68B076F7D36CC8F29BA5DF81DC2CA725ECE66270CC9A5035D8CECEEF9EA0274A63AB1E58FAFD4988D0F65D146757DA071DF045CFE16B9B";
common[5] = "E6969D3D495BE32C7CF180C3BDD4798E91B7818251BB055E2A2064904A79A770FA15A259CBD523A6A6EF09C43048D5A22F971F3C20129B48000E6EDD061CBC053E371D794E5327DF611EBBBE1BAC9B5C6044CF023D76E05EEA9BAD991B13A63C974E9EF1839EB5DB125136F7262E56A8871538DFD823C6505085E21F0DD5C86B";
common[6] = "C9BBF5F774A8297B0F97CDDA3A3468C7117B6BF799A13D9F1F5DAC487B2241FE95EFB13C2855DFD2F898B3F99188E24EDF326DD68C76CC85537283512D46F1953129C693364D8C71202EABB3EBC85C1DF53907FBD0B7EB490AD0BC99289686800C46AB04BF7CDD9AD425E6FB25592EB6258A0655D75E93B2671746AE349E721B";
common[7] = "CD5C22FAEA0C53C39E602242C088FA0EA31586F472E9B04606AEDFB35F56C4948095F687B388575FA1700DB3D02253025A523AC76E9646F755A12338653AE071CB64F185591C34C6673FAC9B78DC4D71E53F3A5CCA6326F89C5400FBF8272A76367C630E234A905E4E558CDA968A46A136AD3088DD295F934EC36ADB5F69C3F3";
common[8] = "92402435C3A12E44D3730D8E78CADFA78E2F5B51A956BFF4DB8E56523E9695E63E32506CFEB912F2A77D22E71BB54C8680893B82AD1BCF337F7F7796D3FB968181D9BA1F7034ABFB1F97B3104CF3203F663E81990B7E090F6C4C5EE1A0E57EC174D3E84AD9E72E6AC7DA6AEA12DF297C131854FBF21AC4E879C23BBC60B4F753";
common[9] = "FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B576625E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE649286651ECE65381FFFFFFFFFFFFFFFF";
common[10] = "D6C094AD57F5374F68D58C7B096872D945CEE1F82664E0594421E1D5E3C8E98BC3F0A6AF8F92F19E3FEF9337B99B9C93A055D55A96E425734005A68ED47040FDF00A55936EBA4B93F64CBA1A004E4513611C9B217438A703A2060C2038D0CFAAFFBBA48FB9DAC4B2450DC58CB0320A0317E2A31B44A02787C657FB0C0CBEC11D";
common[11] = "B10B8F96A080E01DDE92DE5EAE5D54EC52C99FBCFB06A3C69A6A9DCA52D23B616073E28675A23D189838EF1E2EE652C013ECB4AEA906112324975C3CD49B83BFACCBDD7D90C4BD7098488E9C219A73724EFFD6FAE5644738FAA31A4FF55BCCC0A151AF5F0DC8B4BD45BF37DF365C1A65E68CFDA76D4DA708DF1FB2BC2E4A4371";

char *prime;
prime = BN_bn2hex(key->pkey.dh->p);
BIO_printf(out, "---> DH prime: %s\n", prime);
int i;
for (i = 0; i < 12; i++) {    if (!strcmp(prime, common[i])) {        BIO_puts(out, "---> Warning - common prime!\n");
       break;
   }
}

So you should have something like:

Now you’ll get output such as:

Remember that you may need to employ the -cipher DH parameter to force OpenSSL to use a DH-based cipher suite. If export-grade as well as stronger DH suites are supported then you’ll also have to use something like -cipher EXP on a second connection to ensure you test the commonality of both primes.

What is tlslite?

From the source “TLS Lite is an open source python library that implements SSL and TLS”. I’d seen references to it in the original BEAST post written by Thai Duong and an article on TLS Prober by Yngve Pettersen. This gave me some confidence that tlslite would be a good starting point. Obviously it’s not going to be fast but that doesn’t matter. With a SSL/TLS implementation in a high level language, it would be much easier to make the changes required for the sorts of tests I wanted to run, and I thought POODLE_TLS would be a good one to try first.

TLS Prober is in fact where I wanted to be heading. It works on a modified version of tlslite to test for various SSL/TLS bugs. However, the public source code hasn’t been updated since Yngve left Opera in 2013 and thus wouldn’t cover POODLE_TLS. While I could have added that capability, I decided to ignore TLS Prober (for now) and start afresh with the latest tlslite – mainly as it would be a good learning experience.

How to test for POODLE_TLS

I’m not going to re-hash theory that’s already covered elsewhere. Suffice to say that implementations of TLS that are faithful to the RFC shouldn’t be vulnerable to POODLE because the spec states what the contents of the padding bytes should be. Therefore, the way to test for POODLE_TLS is to ignore that rule and see if the connection is terminated by the server. This isn’t the same as performing a full attack but like all testing you have to compromise between accuracy and aggressiveness. I think this test is a good indication. After some rummaging through the source code and a bit of debugging, I found what I wanted.

Changes to tlslite

It seemed a bit crazy to fork the original project as my changes were tiny. I also thought that working through the changes here may be helpful to anyone else who wants to do the same sort of thing.

So to begin with I needed to signal to tlslite that I wanted to send TLS messages with invalid padding. You get things going with tlslite through the TLSConnection class so I changed how that was instantiated. TLSConnection inherits from TLSRecordLayer, which is where the padding code lives, so that needed changing too. Within the “tlslite” folder I made the following changes (obviously line numbers will be version dependent so I’ve added the original code too; my version was 0.4.8):

tlsconnection.py
Line 52 was:
def __init__(self, sock):
Now:
def __init__(self, sock, check_poodle_tls=False):
# now i can signal whether or not I want to perform the test
# if you already have tlslite, you can change it safely because check_poodle_tls defaults to False so it’s backward-compatible with any existing code that makes use of tlslite

Line 61 was:
TLSRecordLayer.__init__(self, sock)
Now:
TLSRecordLayer.__init__(self, sock, check_poodle_tls)
# I need to pass that signal on to the parent

tlsrecordlayer.py
Line 102 was:
def __init__(self, sock):
Now:
def __init__(self, sock, check_poodle_tls):

After line 103 self.sock = sock added new line:
self.check_poodle_tls = check_poodle_tls

After line 600 paddingBytes = bytearray([paddingLength] * (paddingLength+1)) added new lines:
if self.check_poodle_tls == True:
paddingBytes = bytearray(x ^ 42 for x in paddingBytes[0:-1])
paddingBytes.append(paddingLength)
# change all but the last of the padding bytes to be invalid (just XOR with 42, the answer to everything)
# make the last byte of padding valid = the number of padding bytes

And that’s it! Remember, as it’s Python, that tabs are important and the new code needs to be properly aligned.

POODLE_TLS test script

I then created the test script (available here), which attempts a normal TLS connection first before testing for POODLE using the invalid padding trick. Place the script within the modified tlslite and run it as test_poodle_tls.py <hostname>. Remember, it only tests for POODLE over TLS, not SSLv3.

I’ve noticed that sometimes the normal connection fails and one of the reasons for this is that the server does not support any of the small number of cipher suites offered by tlslite. In this case no conclusion can be drawn – and the script catches that.

1. It’s not a standard yet

[See update below]
HPKP is still a draft and as such is likely to be in a greater state of flux than your “average” standard. Last year it went through 11 changes. Of course that’s not to say that every change has been (and will be) critical, but keep an eye on it, as something may change that affects your implementation. For example, version 10 (Feb 2014) dropped SHA-1: currently only SHA-256 is honoured. So if your HPKP header is based on a SHA-1 hash then it’s invalid.

2. What exactly is being pinned?

The next thing to point out is that we’re not pinning certificates, that’s why it’s HPKP and not HCP or something. The reasons for not pinning certificates are discussed elsewhere. What’s actually pinned is the Subject Public Key Info (SPKI) field. According to the X509 standard, this field is “used to carry the public key and identify the algorithm with which the key is used”. Because SPKI sounds a bit abstract, I’ll just use “public key” from now on.

What this means is that you can renew your SSL certificate without any thought to HPKP as long as your CA renews the same public key. On the other hand, if you want to refresh your keys at renewal time, you’ll have to update your HPKP pins, as even if you use your back-up key for the renewal, you’ve then lost your back-up. But I’m implying here that you’ve only got two pins…

3. Validation

Part of the checks for accepting a new pin is that at least one public key in the certificate chain for the connection is submitted for pinning, along with at least one public key that is NOT in the chain, which is your back-up. From this it’s clear that you can pin any one of the public keys in the certificate chain – from the root to the leaf (or more) – and you can have as many back-ups as you like. The flip-side to this is that the browser doesn’t know which pins are active and which are back-ups so, when validating a pinned connection, it’s a case of OR, not AND. In other words, only one of the stored pins needs to match one of the public keys in the presented certificate chain and thus adding more active pins does not mean that a larger part of the certificate chain must be matched for validation to succeed.

4. Updating the policy

The HPKP policy for a host is not set in stone until the expiry date: it can be refreshed with every new valid header – and in fact the policy can be removed altogether with max-age=0. Obviously the public key pins themselves can be updated following validation too.

5. You can trial it safely

HPKP contains a reporting function whereby a failed validation can be reported to a URI set by the report-uri directive in the HPKP header, e.g.

Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="; report-uri="http://example.com/pkp-report"; includeSubDomains

Early on in its development the specification added a PKP-RO (Public-Key-Pins-Report-Only) header that, as the name suggests, instructs the browser not to enforce the policy, only to report any validation failures, e.g.

Public-Key-Pins-Report-Only: pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="; report-uri="http://example.com/pkp-report"

In this way any mistakes aren’t punished with a failed connection but your report-uri page receives details on what went wrong. Note that in this mode any max-age value is ignored (so it isn’t set above) because browsers don’t store the pinning details for report-only directives. But this could lead to a situation where someone (who doesn’t realise this) sets the PKP-RO header with the includeSubDomains directive and assumes that no reporting means everything is working great. In fact, because the validation is performed on the current connection only, the PKP-RO header must always be present wherever validation is needed. So ensure the PKP-RO header is being set throughout your domain space.

I should add that the report-only mode is not mandatory so this feature may be browser-dependent. By the way, you can actually set both headers simultaneously: the specification states that they should be treated independently.

Lastly…

Due to point 1, all of this is subject to change!

UPDATE

HPKP became a standard in April 2015 – RFC 7469

How is a cipher suite chosen?

Quick overview: the connection starts with a Client Hello in which the client advertises which cipher suites it supports in order of preference (most preferred first). This list will be tailored according to any local configuration, as well as to the SSL/TLS protocol version the client is hoping to use, which is also advertised in the Client Hello:

The protocol version is the highest the client supports – unless the browser has gone down the fallback route, which is the mechanism abused by POODLE to make the SSLv3 attack more practical. Cipher suites can vary with protocol version simply because older protocols can’t always meet the needs of newer cipher suites. For example, only TLSv1.2 supports cipher suites that use SHA-256 for message integrity.

In receipt of the Client Hello, the server now has two options: it can either (a) opt for the client’s most preferred cipher suite that it too supports, or (b) ignore the client’s preference and opt for the cipher suite nearest the top of its own list that the client supports. For example, say the client has sent up a list of cipher suites which we’ll just call 1,2,3,4,5,6,7 and the server supports 8,3,4,2,6. In the case of (a) the server’s order is unimportant and it chooses 2; in the case of (b) the server chooses 3. The choice the server makes is returned in the Server Hello message:

Something to note in the above example is that, in the case of the server having a preference, you would never find out that cipher suite 8 is in fact the preferred choice because it isn’t supported by the client and thus it’s never offered in the Client Hello. Server preference is thus not only dictated by the server: it depends on what the client knows too.

Conflicting results

On my last test I had a conflict between SSLyze and SSLscan over which cipher suite was preferred over SSLv3. SSLyze thought it was RC4-SHA (I’m using the OpenSSL notation here)…

…whereas SSLscan went for DES-CBC3-SHA:

Manually testing for preference

To resolve this was simple. I ran:

openssl s_client -ssl3 -connect <host>:443

OpenSSL reported that DES-CBC3-SHA had been chosen. Just to be sure – which I explain below – I let the two cipher suites in question compete with one another using the -cipher switch, which allows you to put specific cipher suites in the Client Hello. OpenSSL orders them exactly how you list them according to the scheme set out in man ciphers. So I ran:

openssl s_client -ssl3 -cipher DES-CBC3-SHA:RC4-SHA -connect <host>:443

and then switched the order of the cipher suites:

openssl s_client -ssl3 -cipher RC4-SHA:DES-CBC3-SHA -connect <host>:443.

In both cases DES-CBC3-SHA was chosen so I was confident that SSLscan was right.

Why did SSLyze get it wrong this time?

Up to now I had tried SSLyze versions 0.9 and 1.0dev and both had reported RC4-SHA as the preferred cipher suite. I then tried an earlier 0.6beta version and found it correctly reported DES-CBC3-SHA. Rather than delve into the code I first took the easy option and fired up Wireshark while running one of the later versions of SSLyze. When enumerating the supported cipher suites, I could see that DES-CBC3-SHA was tested individually; however, when it came to checking for preference, DES-CBC3-SHA was left out of the list in the Client Hello. Obviously the server couldn’t choose it in this case, hence the preference was misreported. I reported this as a bug and Alban Diquet explained that:

The reason why DES-CBC3-SHA isn’t sent within the preference test is that specific servers will not reply at all if the client hello is larger than 255 bytes (due to a bug in a specific brand of load balancers). To reduce the size of the hello, I had to disable some stuff including specific cipher suites.

In this case the server only supported 3 cipher suites over SSLv3 so this misidentification could have been avoided. And this got me thinking…

Algorithm for testing preference

For each supported SSL/TLS protocol version, this is my version 0.1 of a method a tool could use to work out cipher suite preference:

1. Determine which cipher suites are supported individually (i.e. repeatedly send a Client Hello with just one cipher suite and see if it’s accepted).
2. Once you know which suites are supported, send them all up in one Client Hello and see which one is picked. If you’re worried about the buggy load balancers mentioned above then use a subset for now.
3. If the chosen cipher suite is the one that was at the top of the list then there are two alternative explanations: either (a) the server picked the client’s preferred suite as it has no preference of its own, or (b) the server really does prefer that cipher suite and it just happened to be at the top. (This is why I ran more than one test above.) So repeat the test in step 2, this time changing the most preferred cipher suite at the top of the order. If the same cipher suite is chosen then it’s a case of (b) and the server definitely has a preference; otherwise, the first cipher suite should be chosen and it’s case of (a) where the server is happy to be guided by the client’s preference¹.
4. If the cipher suite list has been cut short to appease buggy load balancers, repeat step 2 with the next set of cipher suites. If a preference has been expressed so far, that cipher suite should be included with the next set to allow it to compete.
5. If a preference has been found and you really wanted to go the whole hog, you could determine the order in full by starting again at step 2, missing out the cipher suite previously identified as preferred.

I put some of this to Alban Diquet (as part of the bug report) and he replied “yes I thought of adding the exact check you described but that’s pretty much at the bottom of my TODO list”. I think he was referring to step 3 but, anyway, if you ever have conflicting output from your tools over cipher suite preference, hopefully this posting will help you to resolve the issue.

——————–

¹ Actually, there is a possibility of “no preference” being misreported if you consider a server that supports cipher suite “wildcards” in such as way that there is no preference within a set of cipher suites that match a wildcard. I don’t think any popular implementation features this (hence the footnote) but for the sake of completeness imagine a server that prefers AES-* then RC4-*. The test tool sends up AES-SHA, AES-MD5, RC4-SHA, RC4-MD5 and AES-SHA is chosen. As per step 3, the tool then sends up AES-MD5, RC4-SHA, RC4-MD5, AES-SHA. This time AES-MD5 is chosen, giving the illusion of no server preference but in fact the server does have a preference, it’s just by groups. To cover this, if no server preference has been detected after step 3, repeat step 2 rotating the cipher suite at the top of the list each time; if at any point the cipher suite selected is not the first on the list then the server does have a preference. Admittedly this could add a fair bit of overhead!

TLS_FALLBACK_SCSV is a fake cipher suite advertised in the Client Hello, which starts the SSL/TLS handshake. SCSV stands for “Signaling Cipher Suite Value”. The idea of using a cipher suite as a signal is not new: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a way clients can advertise that they support secure renegotiation (addressing CVE-2009-3555):

The RFC for the TLS_FALLBACK_SCSV mechanism is still a draft but apparently Chrome (and Google from the server-side) has been using it since February 2014. This is no surprise as the RFC was written by two Google heavyweights. (Perhaps this was written with POODLE in mind as the RFC and the attack share an author – but that’s pure speculation!)

The whole business of successively downgrading the protocol version was put in place because browsers wanted to ensure they could connect to servers that were buggy. The TLS_FALLBACK_SCSV mechanism ensures that this downgrade only happens with the client’s blessing.

How does the protection work?

TLS_FALLBACK_SCSV is recommended for a client to indicate that it is knowingly repeating a SSL/TLS connection attempt over a lower protocol version than it supports (because the last one failed for some reason). When the server sees a TLS_FALLBACK_SCSV signal it compares the highest protocol version it supports to the version indicated in the Client Hello. If the client’s version is lower, then the server responds with a new Alert defined by the RFC called inappropriate_fallback. The idea being that the server knows the client supports something better so the connection should have negotiated that. The inappropriate_fallback Alert is a “fatal” error, i.e. the SSL/TLS connection is aborted.

Why does this help against POODLE?

Let’s say both the client and server support TLSv1.2. The client starts off, hoping to make a TLSv1.2 connection but an active man-in-the-middle attacker interferes with the handshake in the hope of forcing a downgrade. By repeatedly doing this, the attacker can force the use of SSLv3 and try some shenanigans like POODLE. Remember, the attacker can’t remove the TLS_FALLBACK_SCSV from the Client Hello because the handshake is cryptographically protected (unlike in SSLv2).

After the first round of interference, the client should try TLSv1.1. With the TLS_FALLBACK_SCSV signal in place, the server will pick up on the fact that the client is only requesting a TLVs.1.1 connection because of some difficulty earlier on. The server now knows that there is no good reason why a connection with a higher procotol version should have failed – and duly aborts the current connection.

The attacker could, of course, drop the TLSv1.1 and the following TLSv1.0 Client Hello. If the lack of response causes the browser to downgrade again then eventually the browser will try a SSLv3 connection, which the attacker will let through. Again, the TLS_FALLBACK_SCSV signal indicates to the server that the client supports something better and will terminate the connection attempt.

Okay, what if the client doesn’t support the server’s best protocol (TLS v1.2 in this example)? Just to be clear, let’s consider that case. The client would begin with, say, a TLSv1.0 connection. The attacker interferes with the handshake and so the client tries a SSLv3 connection with TLS_FALLBACK_SCSV. Again, the server knows that the client is only doing this because an earlier attempt with a higher protocol failed so it returns the Alert and the downgrade is aborted. If the client tries again, unhindered by the attacker, the client’s opening TLSv1.0 request is accepted because it lacks the TLS_FALLBACK_SCSV signal.

It’s more than just a POODLE buster…

The TLS_FALLBACK_SCSV mechanism doesn’t just protect us from attacks to downgrade connections to SSLv3: it protects us from forced downgrades completely. So when we want to connect using TLSv1.2, we can be sure that a meddling attacker can’t drop us down to TLSv1.0, which doesn’t support the best available cipher suites. As ever, we do need the server to play along.

…but it’s not quite a silver bullet

Of course, TLS_FALLBACK_SCSV doesn’t help if the best protocol version is SSLv3 at the client and SSLv3 is supported by the server – or vice versa. In this case SSLv3 will be agreed so no downgrade attack is required but the attacker still needs to make the browser perform multiple requests to the target domain, as the whitepaper explains. Remember that the attack only works with block ciphers operating in CBC mode so if the preferred cipher suite over SSLv3 is RC4 then the attack is likely to fail. Not that I’m advocating SSLv3 with RC4 as a solution though!

If SSLv3 is disabled either on the server or the client, POODLE has lost its bite. The only practical reason to support SSLv3 for servers is to humour IE6 users (because IE6 doesn’t enable TLSv1.0 by default). But if that’s a must then TLS_FALLBACK_SCSV – when supported by both client and server – will protect the vast majority of connections when SSLv3 isn’t necessary.

UPDATE: OpenSSL 1.0.1j supports TLS_FALLBACK_SCSV.

NEW: Assumptions and side effects

While writing up these scenarios I thought of a potential compatibility issue when TLS_FALLBACK_SCSV was in place. The draft RFC states that the connection MUST be refused by the server if the maximum protocol version the server supports is higher than the one advertised in the Client Hello with the TLS_FALLBACK_SCSV signal. This assumes that the server supports all protocol versions in between the client’s stated version and the server’s maximum. What can the server infer about the client? It’s clear the client supports at least a protocol version one higher than that in the Client Hello. But that’s all the server knows. So what if one of those intermediate versions isn’t supported by the server and happens to be the highest version the client supports?

In previous pentests I have seen servers that don’t support TLSv1.1 but do support TLSv1.0 and TLSv1.2. Imagine a client that supports TLSv1.1 at best and so it starts off a TLSv1.1 connection. TLS allows for the server to respond saying effectively “sorry, can’t do that, I can do TLSv1.0″. But supposing it’s one of those buggy servers that the downgrade fallback was intended for…In this case the connection fails in an unexpected way and the browser attempts the connection again, this time using TLSv1.0 with the TLS_FALLBACK_SCSV signal. The server then refuses the connection as its maximum TLS version is 1.2 and it assumes the client can do better. But, in fact, the client doesn’t understand 1.2 and the server doesn’t want to talk 1.1. The two will never talk to each other.

I put this to the RFC authors and I was delighted that Adam Langley replied (on what must have been a particularly busy day!): “I think you’re correct that the server will break in that situation”. He also proposed another, simpler compatibility scenario: “a server believes that it implements TLS 1.2 but is buggy and doesn’t handle, say, the signature_algorithms extension correctly. It works currently because clients downgrade to TLS 1.1. If the server implements TLS_FALLBACK_SCSV then it breaks”.

But is this a problem? I guess it’s unlikely. I don’t know how many of these buggy servers are out there. It’s also a fair assumption that any server that has the awareness to support TLS_FALLBACK_SCSV has also got the TLS version negotiation working. What about from the client viewpoint? In the example above, according to Wikipedia older versions of Chrome and Opera supported TLSv1.1 at best but of course users of these browsers are now very likely to have been auto-updated to later versions. However, we want the TLS_FALLBACK_SCSV mechanism to be future-proof.

At the same, ultimately this is all the fault of buggy servers. Many browsers will look to disable SSLv3 in the light of POODLE, knowing that this will cause issues for a small number of sites but that’s a reasonable price to pay to protect the majority. Enabling TLS_FALLBACK_SCSV for the long-term good could be viewed in the same way. Adam Langley seemed to agree: “TLS_FALLBACK_SCSV is a way for good servers to lift themselves out of the swamp that buggy servers have created. If you have a buggy server and enable TLS_FALLBACK_SCSV then it could certainly break your server. Hopefully that’s noticed in testing and then the real bug can be fixed ”. That’s why, when he acknowledged the potential for compatibility issues, he added “but I’m ok with that”.

Implementing TLS_FALLBACK_SCSV could expose the buggy servers that fallback was designed for – and perhaps that’s just what we need.

The first thing I wanted to do was prove the negative – that is, if the -legacy_rengotation switch did what it seemed to promise, then without it renegotiation should fail. Using OpenSSL 1.0.1i I connected to a server that was missing the secure renegotiation patch and ran the test (more information here):

# openssl s_client -connect insecure.example.com:443
...
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
...
HEAD / HTTP/1.0
R
RENEGOTIATING
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Primary Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0

It worked. Wait a minute, that shouldn’t have happened! So I tried OpenSSL 1.0.1e and then another vulnerable server – and it always connected. After some digging around I found an article on the OpenSSL site. It stated that:

If the option SSL_OP_LEGACY_SERVER_CONNECT or SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set then initial connections and renegotiation between patched OpenSSL clients and unpatched servers succeeds. If neither option is set then initial connections to unpatched servers will fail.

The option SSL_OP_LEGACY_SERVER_CONNECT is currently set by default even though it has security implications: otherwise it would be impossible to connect to unpatched servers (i.e. all of them initially) and this is clearly not acceptable. Renegotiation is permitted because this does not add any additional security issues: during an attack clients do not see any renegotiations anyway.

There was the small print. So as far as s_client is concerned -legacy_renegotiation makes no difference by default because it will renegotiate with insecure servers anyway. To double-check that -legacy_renegotiation and SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION were in fact related, I took a quick look at the source code for s_client.c and the following lines shone out:

else if (strcmp(*argv,"-legacy_renegotiation") == 0)
  off|=SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION;
else if (strcmp(*argv,"-legacy_server_connect") == 0)
  { off|=SSL_OP_LEGACY_SERVER_CONNECT; }
else if (strcmp(*argv,"-no_legacy_server_connect") == 0)
  { clr|=SSL_OP_LEGACY_SERVER_CONNECT; }

As expected, the first line sees -legacy_renegotiation controlling SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION, which we now know has no effect if SSL_OP_LEGACY_SERVER_CONNECT is set. The code also suggests that SSL_OP_LEGACY_SERVER_CONNECT can be controlled with switches, which aren’t listed in the built-in help. Using the switch -no_legacy_server_connect, as the OpenSSL doc states, stops you from connecting to the server at all:

# openssl s_client -no_legacy_server_connect -connect insecure.example.com:443
CONNECTED(00000003)
140264951338664:error:1412F152:SSL routines:SSL_PARSE_SERVERHELLO_TLSEXT:unsafe legacy renegotiation disabled:t1_lib.c:1732:
140264951338664:error:140920E3:SSL routines:SSL3_GET_SERVER_HELLO:parse tlsext:s3_clnt.c:1053:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 63 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)

If you skimmed over the OpenSSL quote above, you may now be thinking “why is it so black and white; why can’t I connect to an unpatched server but s_client refuse renegotiation?” As the OpenSSL doc notes – and if you think back to the attack details – the victim client doesn’t actually initiate a renegotiation, it’s all the attacker’s doing. OpenSSL isn’t leaving you vulnerable by letting you renegotiate to unpatched servers, it’s the very act of connecting to them that leaves you exposed. That’s where the -no_legacy_server_connect switch comes in: it gives you the option of terminating connections to unpatched servers if you don’t want to take any risks (and you can understand why they’ve not made that the default). From a pentest viewpoint, ‑legacy_renegotiation should be avoided when testing for insecure renegotiation.

I pinged Ivan Ristic (of SSL Labs fame) about this for a sanity check, since he was nice enough to get in touch following the release of my cheatsheet. (Quick trailer: it turns out that Ivan is planning to release some of the manual testing aspects from his book Bulletproof SSL and TLS as freeware in the near future.) He agreed that -legacy_renegotiation was something of a red herring as far as manual testing using OpenSSL s_client was concerned – and I think that’s now going to make it into the next version of his book!

The slides can be found here.

Cheatsheet

UPDATE 7th September 2014: I’ve now written a table that pulls together the manual checks discussed in the presentation – plus a few more (which will appear in any future presentations). Since tables are a pain in WordPress and I don’t want to risk a plugin at this time of night, you can find a (lazy) HTML table here.

For updates on content and future presentations follow me.