Economic Failures of HTTPS Encryption

Interesting paper: "Security Collapse of the HTTPS Market." From the conclusion:

Recent breaches at CAs have exposed several systemic vulnerabilities and market failures inherent in the current HTTPS authentication model: the security of the entire ecosystem suffers if any of the hundreds of CAs is compromised (weakest link); browsers are unable to revoke trust in major CAs ("too big to fail"); CAs manage to conceal security incidents (information asymmetry); and ultimately customers and end users bear the liability and damages of security incidents (negative externalities).

Understanding the market and value chain for HTTPS is essential to address these systemic vulnerabilities. The market is highly concentrated, with very large price differences among suppliers and limited price competition. Paradoxically, the current vulnerabilities benefit rather than hurt the dominant CAs, because among others, they are too big to fail.

Posted on November 28, 2014 at 6:26 AM • 24 Comments

Comments

HannoNovember 28, 2014 6:54 AM

I feel the discussion like in this paper is often somewhat outdated.

We actually have a pretty nice solution for many (but not all) of the problems: HTTP Public Key Pinning (pretty soon to be RFCed).

They mention this, but then the authors write:
"All proposals attempt to solve the weakest-link problem by introducing another authority to check whether the certificate that is validated through the normal HTTPS process is indeed the correct one"

I feel this is simply wrong. Key Pinning does not introduce another authority. It introduces a "trust on first use" concept as an additional protection. And the nice thing is: You can start using it today and it requires no software changes on the server side. Chrome already supports it, firefox will pretty soon and even IE announced that they are working on it.

EglefinoNovember 28, 2014 9:02 AM

I made my own security on my computer so 'not easy to use' that sometimes can't read some product from my own country. Strange enough is their own 'https' not okay:
I have the 'Calomel' (Firefox) SSL Validation in use with a Firefox add-on which gives for Bruce a blue safety sign for his total 'SSL' security at
. The site which wrote this item from New York has a 'broken SSL' connection so it gives me a Red sign with a white cross with the message "Certificate: Verified" WARNING! BROKEN OR UNTRUSTED (red 0%) the "Perfect Forward Security" [PFS]: NO 0/20, where Bruce p.e. has [PFS]: Yes 20/20. The Calomel/Firefox-website have a large security information & written tips for software for several OS, please you need to look here: it's of-course Open Source.... but with proxy, dns, squid, OpenSSH, FreeBSD, Samba, e.s.o. and beautiful futuristic photos (eye-openers every 20 minutes, I thought)

Three Dutch guys wrote & placed that item, because my own difficulties I can't read it :(. But take p.e. the Firefox add-on of 'HTTPS Everywhere' (I'm from the Netherlands and since the NSA-scandel EFF-Cooper-member), that add-on gives you a good survey how many SSL-connecties there are and which are really working well. Most online-companies or magazines have a large mouth about others but forget to look to their own stuff.

Sorry if you can't read my translated English text (I learned it 43 years ago) and I'm bedridden so it isn't the easiest way to get all the dictionaries in my bed, so if you can't read it how you learned it "read between the lines" I did my best.

Ruud(ino)
Eglefino (is an Italian synonym)
Amsterdam

It's my last line in every written message, my own-made slogan & my lifestyle since 2006 (when I became bedridden)
~ I'm open, honest & sincere to myself, to my partner and with some restrictions also to strangers.... ~

EglefinoNovember 28, 2014 9:14 AM

The html-codes in my message were not okay so I replaced them without href but now submitted it gives a terrible long web-link and I only had 3 written links. I'm not a Spammer or are making publicity, but I only want a well ridden message. Thanks.

schneier.com

dl.acm.org/citation.cfm?id=2673311&CFID=603605533&CFTOKEN=26590331

calomel.org

|Eglefino|

It's my last line in every written message, my own-made slogan & my lifestyle since 2006 (when I became bedridden)
~ I'm open, honest & sincere to myself, to my partner and with some restrictions also to strangers.... ~

MikaelNovember 28, 2014 9:40 AM

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 (which doesn't have a revenue model) and there is no need for a certifying authority. It also puts the control and responsibility at the hands of site owners, minimizing the impact of security breaches.

AnonNovember 28, 2014 9:51 AM

The paper really isn't about the technology, but more about deeper issues that have to do with money and power. It explains why these technologies aren't adopted on a large scale. Fine if some browsers support pinning, but the whole issue is that CAs and websites lack incentives to deploy secure communications. I found the paper fascinating.

f4h39hfkfjnkNovember 28, 2014 11:22 AM

It's basically the same logistical flaws found in Banks and other power(plutocratic)-industries, except this industry is vaguely market-driven so the 'fat cats' in this case can't just ignore problems in the name of profit and convenience..

AndrewNovember 28, 2014 2:02 PM

@Where is Skeptical
They realized that his "contribution" make it worse. People add more arguments just to answer to his.

GrauhutNovember 28, 2014 4:34 PM

@Hanno: "a pretty nice solution for many (but not all) of the problems: HTTP Public Key Pinning"

Wich key will all those Cloudflare users pin?

ThothNovember 28, 2014 6:44 PM

I have already sounded the alarm that the CA implementations are simply insecure many Squid posts and other posts ago multiple times.

The use of stock application servers, routers, firewalls, switches and untrusted HSMs with very little foresight and simplistic designs is simply asking for epic fails. No usage of data guards or data diodes in CA implementations I have seen yet from my experience.

We have to face the fact CA/HTTPs market has already collapsed long time ago and failed. It is a matter of when the critical mass is hit and the sh** spills over and causes enough havoc to get people rethinking. For now, the masses are oblivious and the impacts have not been felt. The HSAs and Agencies think they can continue to screw around with civilian security/COTS stuff but fail to anticipate the day that the insecurity of COTS/civil security spread into their secretive environments and finally bring them down as well.

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. Can't talk too much but heck, it's like a poisonous snake biting it's own tail making itself sicker everyday.

One day these stuff lose control, the poison-er infects itself ... it is pretty much game over.

A warning to Mil/Agencies reading this: If you continue to poison civil security/COTS efforts with your sh**, you will one day be your own undo-ing sooner or later because you need to use COTS/civi stuff.

The poisonous snake biting itself gets more sick everyday :P .

Live long .... and "prosper" :D .

Earl KillianNovember 28, 2014 8:09 PM

Why aren't the public keys for domains published in DNS records, signed by the parent domain? The public keys for the root would be published along with the root.hint file. Wouldn't this get rid of the need for CAs?

ThothNovember 28, 2014 8:56 PM

@Earl Killian
Domain signing and DNSSEC stuff are still esoteric in the security market ... sadly .. despite already existing for many years.

Most CAs are plug and play and screw up :) .

For Microsoft CA, just use those bundled in the MS Server package. Otherwise download EJBCA, OpenCA and the CA softwares and you are up and running.

The problem is people think those magical crypto properties of software assurance (as good as low assurance). DNSSEC and domain signing stuff are "harder to do" because you don't get to see them so often but I do still say DNSSEC and domain signing is still lesser assurance as the machines may not be secure.

All in all, security needs to be done from the machine/chipboard onwards and we know how much the HSAs have put into our chipboard to ensure we mostly fail in our sec comms attempts.

Earl KillianNovember 28, 2014 11:40 PM

Here's another thought: how many of the issues with CAs would disappear if one was required to get three or four CAs to sign your certificates? Most companies could get one extra CA, eliminating the TBTF problem, so the failure of any one wouldn't take down their website. It would also make it difficult for a single rogue to issue *.google.com and things like that (instead it would take an organization like the NSA to do penetrate three CAs simultaneously).

Anyway, it's a thought.

ThothNovember 29, 2014 12:01 AM

@Earl Killian
In theory, getting multiple CAs to sign is a good idea but in practice, most CAs are sitting ducks.

Assuming NSA have access to all their crypto-hardwares (Thales/Ncipher, SafeNet, Utimaco, AEP Keyper ...) the NSA would simply just walk in and play with them. We have to assume their hardware security have already been thoroughly breached beyond repair. We know that NSA does intercept mail parcels containing electronic equipment and doing their NSA backdoor stuff on them. We know that NSA goes out to infiltrate companies and factories...

We can simply get multiple CAs to sign thew certificate and hope for the best knowing we are already doomed anyway.

JustinNovember 29, 2014 1:57 AM

@ Thoth

You regulars here post a lot about NSA ownage of any and all hardware that is capable of cryptography, and I think much the same could be said about nearly all popular commercial and open source software with its 0-days. It is consistent with NSA's vision from its official website:

"Global Cryptologic Dominance through Responsive Presence and Network Advantage."
(... although it seems impolitic to enunciate such a vision of worldwide hegemony so brazenly in front of other nations that we want to cooperate diplomatically with.)

65535November 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?

ThothNovember 29, 2014 2:43 AM

@Justin
Yup. It is the fact the American Bald Eagle always wants to be the King of the Skies and doesn't like competition (seeing it as a sign of threat than friendly competition). It has no friends ... just leeches who wants to make use of it.

Whenever the buds of a new security system appears, they will not hesitate to stamp it out from the roots before it even has a chance to grow any further.

OFF TOPIC:
The reason Nick P put in a ton of effort to build a CALEA access to the high assurance design is to give some breathing space for users and self although many of us can readily disagree with Nick P's CALEA + high assurance design, it seems that's one of the better ways (honestly) to worm pass the American Bald Eagle's claws and at least move out of sight a little. What needs to be improved is a systematic and high assurance way of managing the CALEA access in Nick P's backdoor-ed high assurance system.

Digital information is a valuable asset. Whoever "wins" in dominating the digital and radio space would simply put the World (which is hungry for digital and radio technology) in their hands to toy around.

Scott "SFITCS" FergusonNovember 29, 2014 4:02 AM

Eglefino

The html-codes in my message were not okay...

hrefs work, if you close the <a> tag i.e.


<a href=¹' URL'> text to display in the link </a>


Notes: All of the markup tags shown below the textarea in this forum require a closing tag. ¹Be kind to the CMS backend, use 'single quotes' to hold non-variables instead of "double quotes" (it's a common misunderstanding that double quotes are required and/or not slower to process)

Kind regards

RojNovember 30, 2014 2:38 AM

OK, now I understand why the NSA has not been clamoring to ban SSL, TLS, and https, now that most email goes over encrypted links. All they needed to do to break them was subvert a couple of the big CAs, which of course they did long ago.

Has anyone taken a critical look at the EFF's "Let's encrypt" plan? I'd trust EFF a lot more than I'd trust Symantec, Comodo or GoDaddy. I'm 100% sure that at least two of those three have already been subverted by the NSA - using their certificates is about as secure as sending all your secrets in plaintext.

JoeyNovember 30, 2014 8:37 AM

Seems like most of the other posters got the obvious solution already, use DANE to allow the domain holder to specify which certificates are valid for his domain.

The real issue with this is that though the proposal is already several years old, all 4 major browser vendors are refusing to support it. The reasoning in each case is completely unclear, and in two cases the browsers had support that was then taken back out, again for unclear and dodgy reasons.

Anyway, this whole problem goes away in a matter of months when at least 1 major browser starts giving a yellow security warning for non DNSSEC protected domains, and refuses to show the Extended Verification tag for certificates that are not in DANE. Your bank gets a big "weak security" marker for a month or two and this whole thing would be straightened out pretty fast.

There is still the issue of Verizon refusing to support DNSSEC on its DNS servers, but again, a few major banks telling their clients that their ISP is breaking their security, would get straigtened out pretty fast.

PovlDecember 3, 2014 1:22 AM

DNSSEC is good, but not good enough.

Consider a nation-state like China. They own all the name servers you can reach. So they pollute everything. Even if we do hierarchical signing, they would pollute the root, and make sure that is what people trust, or they would get error on all certs.

So it is difficult to ensure something is 100%. Pinning only works if you can pin over a trusted connection. In China everybody will pin the government cert.

ObservateurDecember 20, 2014 2:16 PM

Assuming NSA have access to all their crypto-hardwares (Thales/Ncipher, SafeNet, Utimaco, AEP Keyper ...) the NSA would simply just walk in and play with them. We have to assume their hardware security have already been thoroughly breached beyond repair.

What if some agency (FBI) shows up at the CA's door, and serves a secret court order to hand over the master keys?

If it happens at e-mail providers, why couldn't it happen at a CA?

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.