9

Ars Technica is reporting on a new attack against HTTPS. Called FREAK, the devices reported as vulnerable include iPhones, Android devices, and Macs running OS X. The attack (as has been clarified below - thank you @bonsaiviking) is that an active MITM can alter the TLS negotiations between the client and the server to only offer to the server EXPORT strength ciphersuites. This tricks an accommodating server into choosing an EXPORT strength key. The MITM then ensures that the reply back to the client looks normal, but still uses the lower strength key. Vulnerable clients accept this lower strength key even though they didn't offer that option during the negotiation. This clearly isn't secure enough, and can therefore be bruteforced.

How come these keys are still active in so many devices and services? Especially Apple devices - we all know how they often cut loose dated technology quickly. I would have thought once the export of crypto from the States was relaxed, these weak keys would have been pulled much quicker than appears to be the case.

Further reading: Blog post by Matthew Green, the official website (appears down as I post), Hacker News thread.

  • 3
    The answer to the servers part of the question is obvious: because idiots – Mints97 Mar 4 '15 at 8:52
  • This is a version of a downgrade attack. For anyone looking to do this, they would have to be in your upstream, or possibly on your wifi unless it's one of those bgp rerouting type entities. i.e. most services don't expect themselves to be subject to mitm attacks. – munchkin Mar 5 '15 at 11:39
  • It used to be quite common actually to utilize lower grade encryption in mobile or battery powered hardware to reduce CPU cycles and battery consumption. For example, the NintendoDS supported 64bit WEP only for those reasons. – k1DBLITZ Mar 12 '15 at 18:32
8

While your question, why are there so many servers offering export ciphersuites, is valid, your description of the problem is in error. FREAK is:

  • a class of client-side bugs
  • exploitable due to server-side configuration.

The vulnerable devices you list are not configured to use export-grade ciphersuites, but they can be tricked into using export-grade key lengths with standard ("full-strength") ciphersuites. The scenario works like this:

  1. Vulnerable client sends plaintext ClientHello message containing supported ciphersuites, none of which is EXPORT.
  2. Attacker intercepts the ClientHello and replaces the ciphersuites with EXPORT ones.
  3. The server selects one of the EXPORT ciphersuites and responds with the reduced-length export key. If the server is not configured to use EXPORT ciphersuites, then it issues a fatal alert instead, and the connection stops.
  4. The attacker modifies the ServerHello response to replace the EXPORT ciphersuite with the non-export version, but leaves the weak key alone.
  5. Because of the bug, the client accepts the export key and negotiates a weakened TLS connection.

There are obviously more subtleties involved, and Matthew Green does a great job of explaining them, but these are the basic facts.

  • So the client implementation does not check that the ciphersuite chosen by the server is actually one of the ciphersuites the client want? Won't that lead to more kinds of attacks? – Siyuan Ren Mar 4 '15 at 4:02
  • @SiyuanRen The ciphersuite is changed back to what the client expects. The bug is that the client will accept export-grade keys even when the ciphersuite should be using longer keys. Edited my answer to clarify. – bonsaiviking Mar 4 '15 at 4:30
4

These keys are still active because like so many other things the web is fundamentally broken for the purposes of backwards compatability. Technology vendors are quite often stuck with the choice between doing the right thing and supporting what is out there already.

Could you imagine the uproar against Google and Apple if they shipped a web browser that didn't support this ? The blame would not be with the servers that refuse to use more modern technology, the blame would be with Apple and Google.

We saw similar stuff during the Netscape/internet explorer war in the 90s

  • Absolutely. On a related note, a poor choice of defaults often leads to the same result, as many people can't be bothered/don't have time/don't have the knowledge to properly configure the services they deploy. – user16793 Mar 4 '15 at 3:25
  • @lmontrieux yep, but if all of a sudden things if things broke overnight then they would be the first and loudest to complain ( eg if Apache and ngnix both provided a update which "broke" Rsa export handshakes this problem could be fixed for 90% of the deployed web overnights) – Damian Nikodem Mar 4 '15 at 3:29
  • 1
    The uproar would be zero since there's nearly zero websites that ONLY support the old crippled small RSA keys from the 1990s. Google is NOT afraid of breaking things in Chrome in the interests of simplicity. Most recently they removed a javascript function called window.showmodaldialogue that broke a small number of websites. The uproar was relatively minor. – Steve Sether Mar 4 '15 at 16:22
  • Yea, most browsers disabled them years ago. – Yuhong Bao Mar 10 '15 at 5:46
3

There are many servers which support export-grade ciphers simply because default cipher sets had, and in some cases (inexplicably) continue to have them enabled. One of the changes in TLS 1.1 (section A.5) was to state that export grade ciphers MUST NOT be used in TLSv1.1. TLS 1.0 (section D.4) leaves it up to the implementation to decide on the required level of security.

Apache httpd's default SSLCipherSuite is the value "DEFAULT", which up to and including openssl-1.0.2, would include just about everything compiled in, excluding only ciphers sets with anonymous-authentication or null encryption. However, as of httpd-2.4.7 (Nov 2013) the export grade (and aNULL/eNULL) ciphers are removed by mod_ssl, and cannot be restored using SSLCipherSuite. This change was not back-ported to 2.2. Up to and including httpd-2.2.21 (Sept 2011) the default configuration file had "LOW" ciphers explicitly enabled, and "EXPORT" (40) implicitly enabled, only "EXPORT56" are disabled (possibly an oversight).

A likely source of problems is someone running a reasonably up-to-date Apache-2.2, but with an older configuration file.

Your description of the attack isn't quite complete though. "Export grade" is often interpreted as meaning "less than 128-bit". A true export-grade cipher may also require the use of a shorter export grade key/modulus in key exchange. There are two distinct types of keys in an SSL/TLS cipher, most people will be familiar with the export ciphers as using small (40-bit or 56-bit) keys. This refers only to the symmetric key size, used only for the symmetric cipher such RC4 or DES. The other key type is the asymmetric key used to securely exchange the symmetric key.

The U.S. Export controls do not affect just symmetric cipher key size, they affect the asymmetric key size too:

Encryption Export Controls: Revision of License Exception ENC and Mass Market Eligibility, Submission Procedures, Reporting Requirements, License Application Requirements, and Addition of Note 4 to Category 5, Part 2

[...]

a.1.a. A “symmetric algorithm” employing a key length in excess of 56-bits; or

a.1.b. An “asymmetric algorithm” where the security of the algorithm is based on any of the following:

a.1.b.1. Factorization of integers in excess of 512 bits (e.g., RSA);

If a server has an RSA 1024-bit (or larger) key, it cannot be used with all export ciphers with normal RSA-based key exchange (an encryption operation), it must be downgraded somehow to a 512-bit key. (Signing keys can key larger than 512-bits though.)

$ openssl ciphers -v "kRSA" | egrep "(512|1024)"
EXP1024-RC4-SHA         SSLv3 Kx=RSA(1024) Au=RSA  Enc=RC4(56)   Mac=SHA1 export
EXP1024-DES-CBC-SHA     SSLv3 Kx=RSA(1024) Au=RSA  Enc=DES(56)   Mac=SHA1 export
EXP1024-RC2-CBC-MD5     SSLv3 Kx=RSA(1024) Au=RSA  Enc=RC2(56)   Mac=MD5  export
EXP1024-RC4-MD5         SSLv3 Kx=RSA(1024) Au=RSA  Enc=RC4(56)   Mac=MD5  export
EXP-DES-CBC-SHA         SSLv3 Kx=RSA(512) Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-RC2-CBC-MD5         SSLv3 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
EXP-RC2-CBC-MD5         SSLv2 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv2 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export

kx=RSA(512) means the key-exchange is a fixed size RSA 512-bit, independent of the certificate size (or more correctly, modulus size). The RSA 1024-bit export ciphers (EXPORT56) are less interesting here, but are still a potential weakness when used with 2048-bit or higher certificates (they have long since been removed from OpenSSL though).

Unlike a hash output or symmetric key, an asymmetric key (modulus) cannot simply be chopped in half (the mathematics behind the RSA algorithm would no longer hold), so instead a temporary RSA key is used. This key is signed with the servers real RSA key, and exchanged in an optional ServerkeyExchange (type 0x0C) message. (A similar step happens with DHE key exchange, as the RSA certificate alone does not contain the data needed to complete the exchange.)

You can see this with an export cipher like EXP-EDH-RSA-DES-CBC-SHA:

$ openssl ciphers -v EXP-EDH-RSA-DES-CBC-SHA
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1 export
^^^^^^^

The interesting part here is EXP-EDH, the extra ServerKeyExchange contains a shorter (512 bit) EDH key. It's not clear from Matthew Green's discussion if DH is also a problem. RSA Kx is a problem, you can see what happens if you capture a session and run it through ssldump:

$ sudo tcpdump -s1520 -c 18 -w insecure-rsa.pcap host www.insecure.com and port 443 &
$ openssl s_client -showcerts -connect www.insecure.com:443 -cipher EXP-RC4-MD5 -msg
[...]
$ ssldump -VAN -r insecure-rsa.pcap
[...]
1 4  0.0245 (0.0000)  S>CV3.1(205)  Handshake
  ServerKeyExchange
    params
      RSA_modulus[64]=
        b4 3c e4 c5 f2 9b 8b 8e ef 6e 29 4e 5d 80 78 1c 
        1d e8 80 0f 65 32 a0 a6 be d4 35 a6 09 6b 2c 15 
        f2 80 e7 cd 22 9b 01 21 1e 7b 13 12 95 34 03 16 
        7b 9a 66 79 4e d1 6d 15 28 3d 73 45 91 85 a0 c1 
      RSA_exponent[3]=
        01 00 01 
    signature[128]=
      c6 09 b9 14 88 94 6d 06 82 84 e6 af eb af 72 fc 
      fd c6 d5 09 63 a8 f5 f8 e7 3a 79 69 14 9f 24 0e 
      ed dd 71 4b c4 8d 99 51 7c e6 1f aa af ea b2 b9 
      05 04 3c db 31 40 8d 11 f8 94 73 26 a5 5c 2f 28 
      84 49 77 62 3c 27 90 51 52 9f ab 61 6c 12 cd 49 
      9e ab ad f5 bf 2b f7 9c 1b 1e 05 a2 40 f6 7c 60 
      b3 8b 1d 8a 2f 4c bb 1e b0 04 ed 42 a8 14 95 55 
      7c b1 54 ff a2 3e e2 98 f4 15 96 7a 48 c4 a6 8c 

(ssldump is a little old, and has a few problems, but it works fine for this.)

The RSA modulus of 64 bytes is the "512-bit" problem here, it's equivalent to a certificate for RSA key exchange, but it can be brute-force factorised.

A viable attack involves specific server and client behaviour:

  1. The server must support an export-grade cipher with RSA (possibly enabled by default). When this is used, the server must also have a weak (<=512-bit modulus) key available, it protects the modulus when used by signing with its real (strong) key.
  2. The server must use a medium to long-term temporary RSA-export key (Apache does this) since real-time factorisation isn't viable.
  3. The attacker must obtain the weak RSA public modulus by establishing an export grade connection, and then factor the modulus (approx 8 hours, $100) before it's replaced with a new one. The attacker cannot masquerade as the server using this, but he can decrypt data intended for the server if a client uses it.
  4. The attacker must MITM a client who will erroneously accept an export grade key (RSA modulus), even if export ciphers are not enabled, and were not in the client handshake (broken OpenSSL and Apple clients do this).

    • The attacker must modify the ClientHello to include only RSA export ciphers (in TLS, the server picks the cipher from the client list), the export (temporary) key must be signed by the real (long-term) server key (which the attacker does not have).
    • The attacker must modify the ServerHello so that it meets the clients expectations (i.e. using one of the original RSA non-export ciphers)
    • The attacker sends the (out of state) ServerKeyExchange with the weak 512-bit modulus, the client will trust this since it's been signed with the real server key
    • The client accepts the export grade RSA key because it appears at the correct stage in the handshake, the TLS state-machine processes it due to a flaw and subsequently uses it instead of the real one in the certificate.
  5. The attacker obtains the pre-master secret, it is encrypted with the temporary RSA key and sent by the client, the attacker can then compute the master secret (using the pre-master, and other data exchanged earlier in the handshake)
  6. Now the attacker has the master secret, he can compute and send valid "finished" messages, neither side is able to detect any interference in the connection. Game Over.

This problem is a combination of two things:

  • a mis-configured server with export grade cipher support, this necessitates the use of weak temporary RSA keys
  • a flawed client which accepts the export cipher indicated in a handshake even though it did not initiate a connection using it. (The client need not be configured to offer the cipher, but the client's SSL/TLS library must have the implementation present.)

(There's another problem too, by virtue of an export grade cipher being used, each client connection may be brute-forced as it's only 40- or 56-bit, but breaking the RSA part is more useful and interesting.)

Historically, generating the primes for an RSA key took time, which is presumably why Apache only generates this once on startup. On contemporary hardware it takes only a few extra ms at most. In the old Apache-ssl source (apache-1.3.x era, predating mod_ssl-2.0) you'll find this humourous reference:

#if SSLEAY_VERSION_NUMBER >= 0x0920
/* FIXME: This ought to generate a new key from time to time - why make the
Feds' life easy? */
static RSA *TmpRSACallback(SSL *pSSL,int nExport,int nKeyLength)
{
static RSA *pRSA512=NULL;
static RSA *pRSA1024=NULL;

ap_log_error(APLOG_MARK,APLOG_DEBUG|APLOG_NOERRNO,
         SSL_get_ex_data(pSSL,EX_DATA_SERVER_REC),
         "Generating %d bit key",nKeyLength);

This FIXME was never fixed, even in Apache-1.3 with mod_ssl-2.8 which freely quoted (and ignored) the TLS spec's recommendation on key reuse/regeneration. Finally, export RSA support was ripped out entirely in September 2013 in the dev branch (which will be httpd-2.5).

  • You forgot that once the master secret is obtained, the Finished hash can be forged. As such I think 512-bit DHE probably is affected. – Yuhong Bao Mar 10 '15 at 5:45
  • @YuhongBao thanks, I've expanded the description to include this. – mr.spuratic Mar 12 '15 at 12:16
1

Removing old cruft such as support for export ciphers is often seen as a cost saving measure so the code doesn't have to be maintained. Old code like this is often like a submarine. Hard to detect unless it makes itself known, or unless someone is specifically looking for it. It becomes like an appendix. Relatively useless, and can easily be lived without, but removing it takes effort. Keeping it requires no effort. No effort usually wins unless someone is actively thinking about the issue, which requires knowledge it even exists.

At this point, the tradeoff for backwards compatibility is essentially non-existent. The US cryptography export laws were largely eliminated almost 20 years ago, in 1996. Servers have supported strong cryptography for many years since, and the number of servers that only support this weak cryptography is surely exceedingly small.

  • 2000, not 1996. – Yuhong Bao Mar 9 '15 at 7:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.