Resultados 1 a 9 de 9

18102015, 16: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 1024bit prime would allow NSA to passively decrypt connections to twothirds of VPNs and a quarter of all SSH servers globally. Breaking a second 1024bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites. In other words, a onetime investment in massive computation would make it possible to eavesdrop on trillions of encrypted connections."
Matéria completa: http://arstechnica.com/security/2015...nconnections/

18102015, 16: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, DiffieHellman key exchange, an algorithm that we and many others have advocated as a defense against mass surveillance. DiffieHellman 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 realworld users of DiffieHellman are likely vulnerable to statelevel attackers.
For the nerds in the audience, here’s what’s wrong: If a client and server are speaking DiffieHellman, 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 hardcoded 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 DiffieHellman (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 DiffieHellman 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 1024bit prime would allow NSA to passively decrypt connections to twothirds of VPNs and a quarter of all SSH servers globally. Breaking a second 1024bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites. In other words, a onetime 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 DiffieHellman break fits the known technical details about their largescale 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 DiffieHellman 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 DiffieHellman 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 DiffieHellman, 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 DiffieHellman 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.

18102015, 17:08 #3
Imperfect Forward Secrecy: How DiffieHellman 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 ZanellaBéguelin(6) Paul Zimmermann(3)
(1) University of Michigan
(2) INRIA ParisRocquencourt
(3) INRIA NancyGrand 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
ABSTRACT
We investigate the security of DiffieHellman 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 maninthemiddle downgrade connections to “exportgrade” DiffieHellman. To carry out this attack, we implement the number field sieve discrete log algorithm. After a weeklong precomputation for a specified 512bit group, we can compute arbitrary discrete logs in that group in about a minute. We find that 82% of vulnerable servers use a single 512bit 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 DiffieHellman with 768 and 1024bit groups. We estimate that even in the 1024bit case, the computations are plausible given nationstate resources. A small number of fixed or standardized groups are used by millions of servers; performing precomputation for a single 1024bit 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.
...
RECOMMENDATIONS
Our findings indicate that one of the key recommendations from security experts in response to the threat of mass surveillance—promotion of DHEbased TLS ciphersuites offering “perfect forward secrecy” over RSAbased ciphersuites—may have actually reduced security for many hosts.
In this section, we present concrete recommendations to recover the expected security of DiffieHellman as it is used in mainstream Internet protocols.
Transition to elliptic curves. Transitioning to elliptic curve DiffieHellman (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” DiffieHellman, and sharedsecret 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 longterm 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 DiffieHellman 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 1024bit discrete log may be within reach for statelevel actors. As such, 1024bit DHE (and 1024bit RSA) must be phased out in the near term. NIST has recommended such a transition since 2010 [4]. We recommend that clients raise the minimum DHE group size to 2048 bits as soon as server configurations allow. Server operators should move to 2048bit or larger groups to facilitate this transition. Precomputation for a 2048bit nontrapdoored group is around 109 times harder than for a 1024bit group, so 2048bit DiffieHellman will remain secure barring a major algorithmic improvement.
Avoid fixedprime 1024bit groups. For implementations that must continue to use or support 1024bit groups for compatibility reasons, generating fresh groups may help mitigate some of the damage caused by NFSstyle 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 [38]. 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 exportgrade 512bit DiffieHellman 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 [7], our attacks warn of the longterm debilitating effects of deliberately weakening cryptography.
https://weakdh.org/imperfectforwardsecrecyccs15.pdf
PS: Em especial, vale a leitura de "4.3 Effects of a 1024bit Break"

18102015, 21:37 #4
De https://www.ssllabs.com/ssltest/anal...stro.br&latest :
 Preferência para ECDHE ao invés de DHE sempre que disponível
 DHE de 2048 bits
 Sem uso de números primos comuns e sem reuso

18102015, 23: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 serverpreferred 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; 18102015 às 23:17.

19102015, 00:33 #6
@Rubens
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; 19102015 às 00:37.

19102015, 01: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:
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
 TLS_RSA_WITH_AES_128_CBC_SHA
 TLS_RSA_WITH_AES_256_CBC_SHA
 TLS_RSA_WITH_3DES_EDE_CBC_SHA
Windows 7 / Internet Explorer 11.0.23
The cipher suites your client said it supports, in the order it sent them (*), are:
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
 TLS_RSA_WITH_AES_256_GCM_SHA384
 TLS_RSA_WITH_AES_128_GCM_SHA256
 TLS_RSA_WITH_AES_256_CBC_SHA256
 TLS_RSA_WITH_AES_128_CBC_SHA256
 TLS_RSA_WITH_AES_256_CBC_SHA
 TLS_RSA_WITH_AES_128_CBC_SHA
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
 TLS_RSA_WITH_3DES_EDE_CBC_SHA
 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
 TLS_RSA_WITH_RC4_128_SHA
 TLS_RSA_WITH_RC4_128_MD5
Fascinante
https://www.howsmyssl.com/
(*) 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; 19102015 às 01:47.

19102015, 02:12 #8
Autoexplicativo
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 810 / 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; 19102015 às 02:19.

19102015, 05: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".