18-10-2015, 15:16 #1
[EN] NSA can break encrypted Web and VPN connections
"Since a handful of primes are so widely reused, the payoff, in terms of connections they could decrypt, would be enormous," researchers Alex Halderman and Nadia Heninger wrote in a blog post published Wednesday. "Breaking a single, common 1024-bit prime would allow NSA to passively decrypt connections to two-thirds of VPNs and a quarter of all SSH servers globally. Breaking a second 1024-bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites. In other words, a one-time investment in massive computation would make it possible to eavesdrop on trillions of encrypted connections."
Matéria completa: http://arstechnica.com/security/2015...n-connections/
18-10-2015, 15:23 #2
How is NSA breaking so much crypto?Alex Halderman and Nadia Heninger
There have been rumors for years that the NSA can decrypt a significant fraction of encrypted Internet traffic. In 2012, James Bamford published an article quoting anonymous former NSA officials stating that the agency had achieved a “computing breakthrough” that gave them “the ability to crack current public encryption.” The Snowden documents also hint at some extraordinary capabilities: they show that NSA has built extensive infrastructure to intercept and decrypt VPN traffic and suggest that the agency can decrypt at least some HTTPS and SSH connections on demand.
However, the documents do not explain how these breakthroughs work, and speculation about possible backdoors or broken algorithms has been rampant in the technical community. Yesterday at ACM CCS, one of the leading security research venues, we and twelve coauthors presented a paper that we think solves this technical mystery.
The key is, somewhat ironically, Diffie-Hellman key exchange, an algorithm that we and many others have advocated as a defense against mass surveillance. Diffie-Hellman is a cornerstone of modern cryptography used for VPNs, HTTPS websites, email, and many other protocols. Our paper shows that, through a confluence of number theory and bad implementation choices, many real-world users of Diffie-Hellman are likely vulnerable to state-level attackers.
For the nerds in the audience, here’s what’s wrong: If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number with a particular form. There seemed to be no reason why everyone couldn’t just use the same prime, and, in fact, many applications tend to use standardized or hard-coded primes. But there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to “crack” a particular prime, then easily break any individual connection that uses that prime.
How enormous a computation, you ask? Possibly a technical feat on a scale (relative to the state of computing at the time) not seen since the Enigma cryptanalysis during World War II. Even estimating the difficulty is tricky, due to the complexity of the algorithm involved, but our paper gives some conservative estimates. For the most common strength of Diffie-Hellman (1024 bits), it would cost a few hundred million dollars to build a machine, based on special purpose hardware, that would be able to crack one Diffie-Hellman prime every year.
Would this be worth it for an intelligence agency? Since a handful of primes are so widely reused, the payoff, in terms of connections they could decrypt, would be enormous. Breaking a single, common 1024-bit prime would allow NSA to passively decrypt connections to two-thirds of VPNs and a quarter of all SSH servers globally. Breaking a second 1024-bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites. In other words, a one-time investment in massive computation would make it possible to eavesdrop on trillions of encrypted connections.
NSA could afford such an investment. The 2013 “black budget” request, leaked as part of the Snowden cache, states that NSA has prioritized “investing in groundbreaking cryptanalytic capabilities to defeat adversarial cryptography and exploit internet traffic.” It shows that the agency’s budget is on the order of $10 billion a year, with over $1 billion dedicated to computer network exploitation, and several subprograms in the hundreds of millions a year.
Based on the evidence we have, we can’t prove for certain that NSA is doing this. However, our proposed Diffie-Hellman break fits the known technical details about their large-scale decryption capabilities better than any competing explanation. For instance, the Snowden documents show that NSA’s VPN decryption infrastructure involves intercepting encrypted connections and passing certain data to supercomputers, which return the key. The design of the system goes to great lengths to collect particular data that would be necessary for an attack on Diffie-Hellman but not for alternative explanations, like a break in AES or other symmetric crypto. While the documents make it clear that NSA uses other attack techniques, like software and hardware “implants,” to break crypto on specific targets, these don’t explain the ability to passively eavesdrop on VPN traffic at a large scale.
Since weak use of Diffie-Hellman is widespread in standards and implementations, it will be many years before the problems go away, even given existing security recommendations and our new findings. In the meantime, other large governments potentially can implement similar attacks, if they haven’t already.
Our findings illuminate the tension between NSA’s two missions, gathering intelligence and defending U.S. computer security. If our hypothesis is correct, the agency has been vigorously exploiting weak Diffie-Hellman, while taking only small steps to help fix the problem. On the defensive side, NSA has recommended that implementors should transition to elliptic curve cryptography, which isn’t known to suffer from this loophole, but such recommendations tend to go unheeded absent explicit justifications or demonstrations. This problem is compounded because the security community is hesitant to take NSA recommendations at face value, following apparent efforts to backdoor cryptographic standards.
This state of affairs puts everyone’s security at risk. Vulnerability on this scale is indiscriminate—it impacts everybody’s security, including American citizens and companies—but we hope that a clearer technical understanding of the cryptanalytic machinery behind government surveillance will be an important step towards better security for everyone.
For more details, see our research paper: Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice. (Update: We just received the Best Paper Award at CCS 2015!)
J. Alex Halderman is an associate professor of Computer Science and Engineering at the University of Michigan and director of Michigan’s Center for Computer Security and Society.
Nadia Heninger is an assistant professor of Computer and Information Science at the University of Pennsylvania.
18-10-2015, 16:08 #3
Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
David Adrian(1) Karthikeyan Bhargavan(2) Zakir Durumeric(1) Pierrick Gaudry(3) Matthew Green(4)
J. Alex Halderman(1) Nadia Heninger(5) Drew Springall(1) Emmanuel Thomé(3) Luke Valenta(5)
Benjamin VanderSloot(1) Eric Wustrow(1) Santiago Zanella-Béguelin(6) Paul Zimmermann(3)
(1) University of Michigan
(2) INRIA Paris-Rocquencourt
(3) INRIA Nancy-Grand Est, CNRS, and Université de Lorraine
(4) Johns Hopkins
(5) University of Pennsylvania
(6) Microsoft Research
For additional materials and contact information, visit WeakDH.org
We investigate the security of Diffie-Hellman key exchange as used in popular Internet protocols and find it to be less secure than widely believed. First, we present Logjam, a novel flaw in TLS that lets a man-in-the-middle downgrade connections to “export-grade” Diffie-Hellman. To carry out this attack, we implement the number field sieve discrete log algorithm. After a week-long precomputation for a specified 512-bit group, we can compute arbitrary discrete logs in that group in about a minute. We find that 82% of vulnerable servers use a single 512-bit group, allowing us to compromise connections to 7% of Alexa Top Million HTTPS sites. In response, major browsers are being changed to reject short groups. We go on to consider Diffie-Hellman with 768- and 1024-bit groups. We estimate that even in the 1024-bit case, the computations are plausible given nation-state resources. A small number of fixed or standardized groups are used by millions of servers; performing precomputation for a single 1024-bit group would allow passive eavesdropping on 18% of popular HTTPS sites, and a second group would allow decryption of traffic to 66% of IPsec VPNs and 26% of SSH servers. A close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community.
Our findings indicate that one of the key recommendations from security experts in response to the threat of mass surveillance—promotion of DHE-based TLS ciphersuites offering “perfect forward secrecy” over RSA-based ciphersuites—may have actually reduced security for many hosts.
In this section, we present concrete recommendations to recover the expected security of Diffie-Hellman as it is used in mainstream Internet protocols.
Transition to elliptic curves. Transitioning to elliptic curve Diffie-Hellman (ECDH) key exchange with appropriate parameters avoids all known feasible cryptanalytic attacks. Current elliptic curve discrete log algorithms for strong curves do not gain as much of an advantage from precomputation. In addition, ECDH keys are shorter than in “mod p” Diffie-Hellman, and shared-secret computations are faster. Unfortunately, the most widely supported ECDH parameters, those specified by NIST, are now viewed with suspicion due to NSA influence on their design, despite no known or suspected weaknesses. These curves are undergoing scrutiny, and new curves, such as Curve25519, are being standardized by the IRTF for use in Internet protocols. We recommend transitioning to elliptic curves where possible; this is the most effective long-term solution to the vulnerabilities described in this paper.
Increase minimum key strengths. Server operators should disable DHE_EXPORT and configure DHE ciphersuites to use primes of 2048 bits or larger. Browsers and clients should raise the minimum accepted size for Diffie-Hellman groups to at least 1024 bits in order to avoid downgrade attacks when communicating with servers that still use smaller groups. Primes of less than 1024 bits should not be considered secure, even against an attacker with moderate resources.
Our analysis suggests that 1024-bit discrete log may be within reach for state-level actors. As such, 1024-bit DHE (and 1024-bit RSA) must be phased out in the near term. NIST has recommended such a transition since 2010 . We recommend that clients raise the minimum DHE group size to 2048 bits as soon as server configurations allow. Server operators should move to 2048-bit or larger groups to facilitate this transition. Precomputation for a 2048-bit non-trapdoored group is around 109 times harder than for a 1024-bit group, so 2048-bit Diffie-Hellman will remain secure barring a major algorithmic improvement.
Avoid fixed-prime 1024-bit groups. For implementations that must continue to use or support 1024-bit groups for compatibility reasons, generating fresh groups may help mitigate some of the damage caused by NFS-style precomputation for very common fixed groups. However, we note that it is possible to create trapdoored primes [20, 44] that are computationally difficult to detect. At minimum, clients should check that servers’ parameters use safe primes or a verifiable generation process, such as that proposed in FIPS186 . Ideally, the process for generating and validating parameters in TLS should be standardized so as to thwart the risk of trapdoors.
Don’t deliberately weaken crypto. Our downgrade attack on export-grade 512-bit Diffie-Hellman groups in TLS illustrates the fragility of cryptographic “front doors”. Although the key sizes originally used in DHE_EXPORT were intended to be tractable only to NSA, two decades of algorithmic and computational improvements have significantly lowered the bar to attacks on such key sizes. Despite the eventual relaxation of crypto export restrictions and subsequent attempts to remove support for DHE_EXPORT, the technical debt induced by the additional complexity has left implementations vulnerable for decades. Like FREAK , our attacks warn of the long-term debilitating effects of deliberately weakening cryptography.
PS: Em especial, vale a leitura de "4.3 Effects of a 1024-bit Break"
18-10-2015, 20:37 #4
18-10-2015, 22:09 #5
Rodei para um servidor SMTP/IMAP/Webmail e o resultado foi A+ mas não estou certo da ordem de preferência ser a melhor. Também não me lembro porque usei ECDHE 384 bits e DHE 4096 bits. A curva utilizada é "secp384r1" (sugestão de algum site de segurança).
Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites at the end) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 384 bits (eq. 7680 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 384 bits (eq. 7680 bits RSA) FS 128 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 384 bits (eq. 7680 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 384 bits (eq. 7680 bits RSA) FS 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 384 bits (eq. 7680 bits RSA) FS 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 384 bits (eq. 7680 bits RSA) FS 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 128 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 384 bits (eq. 7680 bits RSA) FS 112 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 112 TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256 TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128 TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128
Última edição por 5ms; 18-10-2015 às 22:17.
18-10-2015, 23:33 #6
Estranho esses resultados do registro.br. Na simulação do meu servidor foi empregado AES_256_GCM
Handshake Simulation Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128 BingPreview Jan 2015 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128 IE 11 / Win 7 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS 128 IE 11 / Win 8.1 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS 128 IE 11 / Win Phone 8.1 Update R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) FS 128 Edge 12 / Win 10 (Build 10130) R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128 OpenSSL 1.0.1l R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128 OpenSSL 1.0.2 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128 Yahoo Slurp Jan 2015 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128 YandexBot Jan 2015 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128
(R) Denotes a reference browser or client, with which we expect better effective security.
Última edição por 5ms; 18-10-2015 às 23:37.
19-10-2015, 00:39 #7
Hows' my SSL?
Windows 7 - Firefox 41.0.1
The cipher suites your client said it supports, in the order it sent them (*), are:
Windows 7 / Internet Explorer 11.0.23
The cipher suites your client said it supports, in the order it sent them (*), are:
(*) This ordering is sometimes used to determine which cipher suite a client prefers, but TLS servers tend to choose their own preference of those cipher suits.
Última edição por 5ms; 19-10-2015 às 00:47.
19-10-2015, 01:12 #8
Android 4.0.4 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
Android 4.1.1 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
Android 4.2.2 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
Android 4.3 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
Android 5.0.0 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
Chrome 43 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
Firefox 31.3.0 ESR / Win 7 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
Firefox 39 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
IE 7 / Vista TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
IE 8-10 / Win 7 R TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
IE 11 / Win 7 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
IE 11 / Win 8.1 R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
IE 10 / Win Phone 8.0 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
IE 11 / Win Phone 8.1 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
IE 11 / Win Phone 8.1 Update R TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
Edge 12 / Win 10 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
Java 7u25 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA FS 128
Java 8u31 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
OpenSSL 0.9.8y TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA FS 256
OpenSSL 1.0.1l R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
OpenSSL 1.0.2 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 FS 128
Safari 5.1.9 / OS X 10.6.8 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
Safari 6 / iOS 6.0.1 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 FS 256
Safari 6.0.4 / OS X 10.8.4 R TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA FS 256
Safari 7 / iOS 7.1 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 FS 256
Safari 7 / OS X 10.9 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 FS 256
Safari 8 / iOS 8.4 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 FS 256
Safari 8 / OS X 10.10 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 FS 256
Dica: 256 consome 40% mais processador do que 128 ... Pense em https generalizado, cpus lentas de smartphones, energia de bateria gasta no processamento, e o concorrente usando 256 bits.
Última edição por 5ms; 19-10-2015 às 01:19.
19-10-2015, 04:31 #9
ECDHE x DHE define a negociação da chave de sessão, enquanto AES_128 x 256 e CBC x GCM definem como é o uso da chave de sessão. Então as escolhas aqui dependem, além de perfil de risco, do quanto se tem sessões mais longas ou mais efêmeras.
Na questão 128 x 256, o que acaba determinando é a preferência do client... quem estiver sendo perseguido por um governo deve preferir 256. Deixa eu me colocar na lista de alguns deles postando algo como "bomb the USA" e "Free Tibet".