
Attack of the week: FREAK (or 'factoring the NSA for fun and profit') - ivanr
http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
======
amckenna
I can't believe how bad some of the findings were.

From smacktls.com - "JSSE clients allow the peer to skip all messages related
to key exchange and authentication. In particular, a network attacker can send
the certificate of any arbitrary website, and skip the rest of the protocol
messages. A vulnerable JSSE client is then willing to accept the certificate
and start exchanging unencrypted application data. In other words, the JSSE
implementation of TLS has been providing virtually no security guarantee (no
authentication, no integrity, no confidentiality) for the past several years."

To reiterate - The JSSE implementation of TLS has been providing virtually no
security guarantee for the past _several years_.

JSSE - the Java implementation of TLS shipped with the JDK.

I guess the silver lining in all of this is now we have a decent way to fuzz
the TLS state machine which will hopefully prevent things like this in the
future.

~~~
ivanr
I think the most important lesson from the last couple of years is that all
our security protocols must come with adversarial testing suites -- from
inception. Clearly, there's a long way between designing a secure protocol (I
am not saying that SSL and TLS were properly designed) and implementing one.

~~~
a3n
I think the NSA's clandestine backdooring of hardware, software and standards,
_in contradiction of their charter_ , shows that the processes and
organizations producing and shipping those protocols, software and hardware
also need adversarial testing.

------
zaroth
Cross-posting my comment from the other FREAK thread;

If such a suite was enabled, how would the plethora of SSL testing sites out
there have graded it? I assume a passing grade would not have allowed insecure
suites such as these to be allowed. Insecure cipher is insecure; that would
not typically be worthy of a CVE? I guess the bug is that the client will
accept it even if it wasn't on the clients cipher list. But it would still
have to be on the _servers_ accepted cipher list...

This is all OpenSSL has to say about it;

    
    
      RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
      ==============================================================
    
      Severity: Low
    
      An OpenSSL client will accept the use of an RSA temporary key in a non-
      export RSA key exchange ciphersuite. A server could present a weak
      temporary key and downgrade the security of the session.
    
      This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.
    
      OpenSSL 1.0.1 users should upgrade to 1.0.1k.
      OpenSSL 1.0.0 users should upgrade to 1.0.0p.
      OpenSSL 0.9.8 users should upgrade to 0.9.8zd.
    
      This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
      Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
      Henson of the OpenSSL core team.
    

I find these notes are usually too curt to really understand what's going
on... Also, that CVE is from Jan 8, 2015, while this is claiming to be a new
issue disclosed today. I've seen no mention on the oss-security list of
"FREAK", so something is borked with this disclosure if it is a new
vulnerability...

P.S. Matthew makes it clear, this is the same issue, just perhaps a novel way
of upgrading its stated severity from "Low" to "Name That Vuln!". With Zombies
from Walking Dead as the official mascot :-)

------
sprkyco
A bit off topic, but you mention this: " but they also lack poetry in their
souls." I could not have thought of a more fitting statement for the condition
you were talking about. Is this original? Quoted or colloquial saying?

~~~
mutagen
It is a fantastic saying. A quick Google search for the phrase "lack poetry in
their souls" turns up a handful of uses in the past 5 years and one
theological journal article from 1922.

Remove the word 'lack' and I get plenty more results. The ngram viewer
indicates Google found the first usage around 1830 and it was most popular
1840-1850.

~~~
kordless
"I am no poet, but if you think for yourselves, as I proceed, the facts will
form a poem in your minds." \- Michael Faraday

------
yuhong
What is sad is that OpenSSL disabled the EXPORT1024 ciphersuites in 2006. If
you don't know what these are, in year 1999 the US government raised the limit
to 56-bit encryption and 1024-bit RSA. They were described in
[https://tools.ietf.org/html/draft-ietf-tls-56-bit-
ciphersuit...](https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites)
. And for the record it was in year 2000 that the restrictions was removed for
"retail" software.

~~~
edwintorok
They're still available if you ask for them. Can't we disable them at compile
time like it was done for SSLv3?

    
    
      $ openssl version
      OpenSSL 1.0.1k 8 Jan 2015
      $ openssl ciphers -v EXP
      EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA    Enc=DES(40)   Mac=SHA1 export
      EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=DSS  Enc=DES(40)   Mac=SHA1 export
      EXP-ADH-DES-CBC-SHA     SSLv3 Kx=DH(512)  Au=None Enc=DES(40)   Mac=SHA1 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-ADH-RC4-MD5         SSLv3 Kx=DH(512)  Au=None Enc=RC4(40)   Mac=MD5  export
      EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
    

[http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=779669](http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=779669)

~~~
yuhong
56-bit EXPORT1024, not 40-bit EXPORT.

------
yuhong
To go over some of the technical details, attacker can't just generate a
512-bit RSA key as the key in the ServerKeyExchange message is signed by the
server, and the Finished message don't prevent the attack as all the hash
depends on is the master secret that can be obtained after the 512-bit RSA key
is factored. As a side note, this make me wonder if a similar attack is
possible with 512-bit DHE. A server still using it is
[https://www.ssllabs.com/ssltest/analyze.html?d=mobilelinkgen...](https://www.ssllabs.com/ssltest/analyze.html?d=mobilelinkgen.com)

------
x0x0
Why isn't apache updated to replace the rsa key on an interval shorter than
uptime? Even every 5 minutes shouldn't be particularly expensive. That also
seems like a sensible approach.

~~~
matthewdgreen
The TLS spec suggests once per day or every 500 connections. Why didn't they
do this? Who knows. Things like that are hard to get right...

~~~
mnordhoff
It even suggests you replace the key "more often if possible"! :(

------
leni536
OFF:

Please do not use gray fonts on light background. Black is fine, really. Dark
gray is acceptable for background of dark themes since it usually a compromise
between contrast and hurting the eye by making the reader's pupils to dilate.
There is no such compromise for light themes (well, if you don't count
readablity <-> design and your really should weight readability much more).

It's not this article only, but this article made me to change the color in
the developer console.

~~~
nodata
Your comment is gray. Pot kettle black!

------
cesarb
I haven't studied the key exchange for export ciphers, but I wonder if it
would be possible to save a copy of the signature on the 512-bit key and
replay it later. If that's possible, then disabling export ciphers after the
attacker has already a copy of the signed 512-bit key is not enough; the
certificate has to be revoked (and we all know how reliable certificate
revocation is).

------
im2w1l
>NSA outsources its web presence to the Akamai CDN

Well that was unexpected...

~~~
AlyssaRowan
But, you must admit, quite sensible.

Their actual network is *.nsa.ic.gov, and all that fun stuff on Verizon
Business. (Amongst other things.)

------
lil_cain
Original research (which has extra issues) is here. Linked in the cryptography
engineering as well.

~~~
matthewdgreen
The link is:

SmackTLS.com

------
omgitstom
This is an interesting downgrade attack for sure. The author didn't bring this
up, but this will probably work around HSTS if you have your site set up and
preloaded into the browsers HSTS list.

------
natch
Great article. Too bad he felt he needed to add the dig about Nadia needing
"handholding."

~~~
matthewdgreen
Heh. For the record, Nadia was doing the handholding. She ran the job across
75 EC2 nodes with software that kept crashing. I updated the post to make that
a bit more clear.

~~~
natch
Thanks for clarifying.

