Schneier on Security

65535 • November 29, 2014 2:11 AM

The entire ACM org paper was eye opening.

Table 2 depicting DV certificate market share [on page six] shows the 91% share for Symantec [36% + 10%] Godaddy [40%] and Comodo [5%] – which is mostly based under USA/NSA jurisdiction is very discomforting.

I suspect all three major CA have already been NSL’d or CALEA’d in one way or another.

I notice the ACM’s report focused on Godaddy’ certificates as an example of what could go awry if Godaddy’ CA were compromised [a huge ‘weakest link’ hole in the entire certificate ecosystem].

ACM must be aware of the fact that Godaddy forces it’s customers to use Godaddy’s certificates – in addition to their webs provider services [domain name selection reservation, hosting service, Certificate creation services or CRS, Certificate Signing Requests and Certificate authority] making their product an “all-in-one” shop.

That one-stop-shop is not very transparent about the method of certificate signing – possibly leading to certificate forging at the NSA and probably other lower level perpetrators of MITM attacks.

Table 2 page on page six of the pdf:
https://dl.acm.org/ft_gateway.cfm?id=2673311&ftid=1502414&dwn=1&CFID=603767920&CFTOKEN=32789828

[next]

“A more distributed approach that allows everyone to publish their own key is DANE, using the DNSSEC mechanisms for authenticity and trust. By publishing your public key in your own signed dns zone, the reliance on a top-down authority is limited to the DNSSEC trust chain… “ –Mikael

That is true and would be a great help. But it is not widely adopted. Which begs the question: is some “Nation State” player blocking its wide adoption?

@Hanno and Grauhut:

“Wich key will all those Cloudflare users pin?” –Grauhut

That is a good question. How about an answerer Hanno? How would you deal with wild card certificates?

[Next, use of consumer servers with CA’s built in – such as M$ servers with full CA’s, Exchange, and IIS servers, used by some contractors – and thinly protected by civilian IDS and/or weak firewall appliances]

“A ton of Mil / Agencies are relying on the standard CA deployments (routers, firewall, HSM, switches, app servers … etc) for their ID sources in their civil sectors of their Mil/Agencies/Contractor services and are also being hit by the same problem as the sh** they tried to backdoored and introduce…A warning to Mil/Agencie…you will one day be your own undo-ing sooner or later because you need to use COTS/civi stuff.s… he poisonous snake biting itself gets more sick everyday” –Thoth

That circles to the “back-dooring” of civilian boxes as with the _NASKEY problem which by now is probably done with more invisible methods [Heartbleed on Openssl and unknown amounts of SSL stripping from NS@/GCH@/Gamma/Bo@ing/Blueco@t/Cisc@/rayth@on/ and the cottage industry of zero day virus makers].

This will cause a “race to the bottom” or a race to sink CA’s to the bottom – causing negative consequences for all involved.

‘Why aren’t the public keys for domains published in DNS records, signed by the parent domain?… how many of the issues with CAs would disappear if one was required to get three or four CAs to sign your certificates? …” –Earl Killian

Both ideas are interesting. But, there a many tricks to break/or strip SSL/TLS.

Some have noted there are risks in exposing and correlating certificates with a large amounts of cipher-text making encryption cracking possible.

One of the methods is a “chosen-ciphertext” attack [with certain mitigating factors].

“Alice’s computer willingly decrypts C for Cynthia and sends her P É C mod N. But in reality Cynthia formed C by choosing a random R and setting CÉ CR mod N. After Alice is tricked into sending her P, all Cynthia has to do is divide it by R modulo N in order to learn P …in such an attack the adversary is assumed to be able to get Alice to decipher any ciphertext C she wants other than the target ciphertext C…”

See page two of the AMA org document [or page 358 of entire pdf document]
http://www.ams.org/notices/201003/rtx100300357p.pdf

[The above notes the trick of soliciting plain-text from other sources to break asymmetric encryption – but the the amount of both plain text and ciphertext needed is large]

Bruce posted this document in the below link:
https://www.schneier.com/blog/archives/2014/11/the_security_un.html

Bruce has noted it takes a large amount of ciphertext – about 70 TB in certain cases – and other factor to break encryption.

Here is what Bruce S. said on the subject [excluding, keyloggers, side channel attacks and other NSA hacking]:

“…Right now the upper practical limit on brute force is somewhere under 80 bits. However, using that as a guide gives us some indication as to how good an attack has to be to break any of the modern algorithms. These days, encryption algorithms have, at a minimum, 128-bit keys. That means any NSA cryptanalytic breakthrough has to reduce the effective key length by at least 48 bits in order to be practical… There’s more, though. That DES attack requires an impractical 70 terabytes of known plaintext encrypted with the key we’re trying to break. Other mathematical attacks require similar amounts of data. In order to be effective in decrypting actual operational traffic, the NSA needs an attack that can be executed with the known plaintext in a common MS-Word header: much, much less… while the NSA certainly has symmetric cryptanalysis capabilities… converting that into practical attacks on the sorts of data it is likely to encounter seems so impossible as to be fanciful… The defense is easy… stick with symmetric cryptography based on shared secrets, and use 256-bit keys.
[Discussion of quantum computers and NSA’s privileged position on the backbone]… “maybe some of it [quantum computing] even practical. Still, I trust the mathematics.”- Bruce S.

https://www.schneier.com/blog/archives/2013/09/the_nsas_crypto_1.html

[and]

Bruce’s tips on how to stay secure:

“Hide in the network. Use Tor to anonymize yourself. Yes, the NSA targets Tor users, but it’s work for them [Tor users].

“Encrypt your communications. Use TLS. Use IPsec…you’re much better protected than if you communicate in the clear.

“Assume that while your computer can be compromised, it would take work and risk on the part of the NSA – so it probably isn’t. If you have something really important, use an air gap…

“Be suspicious of commercial encryption software, especially from large vendors. My guess is that most encryption products from large US companies have NSA-friendly back doors, Try to use public-domain encryption that has to be compatible with other implementations. For example, it’s harder for the NSA to backdoor TLS than BitLocker, because any vendor’s TLS has to be compatible with every other vendor’s TLS, while BitLocker only has to be compatible with itself…” [possibly out of date given the Openssl heartbleed problem and now TrueCrypt shutdown]

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

Given what we now know from the Snowden documents and other open source information it would be interesting to see if the above solutions would make SSL/TLS more secure. Anybody have comments or solutions?