Subject: [TLS] fyi: paper on compelled, certificate creation attack and applicable appliance

From: =JeffH <[email-masked]>
Date: Wed, 24 Mar 2010 14:08:01 -0700

Abstract

This paper introduces a new attack, the
compelled certificate creation attack, in which
government agencies compel a certificate au-
thority to issue false SSL certificates that are
then used by intelligence agencies to covertly
intercept and hijack individuals' secure Web-
based communications. We reveal alarming ev-
idence that suggests that this attack is in ac-
tive use. Finally, we introduce a lightweight
browser add-on that detects and thwarts such
attacks.

------- Forwarded Message

Date:    Wed, 24 Mar 2010 15:34:27 -0400
From:    Dave Farber <[email-masked]>
To:      "ip" <[email-masked]>
Subject: [IP] Surveillance via bogus SSL certificates

Begin forwarded message:

 > From: Matt Blaze <[email-masked]>
 > Date: March 24, 2010 3:09:19 PM EDT
 > To: Dave Farber <[email-masked]>
 > Subject: Surveillance via bogus SSL certificates
 >

 > Dave,
 >
 > For IP if you'd like.
 >
 > Over a decade ago, I observed that commercial certificate
 > authorities protect you from anyone from whom they are unwilling to
 > take money.  That turns out to be wrong; they don't even do that.
 >
 > Chris Soghoian and Sid Stamm published a paper today that describes
 > a simple "appliance"-type box, marketed to law enforcement and
 > intelligence agencies in the US and elsewhere, that uses bogus
 > certificates issued by *any* cooperative certificate authority to
 > act as a "man-in-the-middle" for encrypted web traffic.
 >
 > Their paper is available at http://files.cloudprivacy.net/ssl-mitm.pdf
 >
 > What I found most interesting (and surprising) is that this sort of
 > surveillance is widespread enough to support fairly mature, turnkey
 > commercial products.    It carries some significant disadvantages
 > for law enforcement -- most particularly it can be potentially can
 > be detected.
 >
 > I briefly discuss the implications of this kind of surveillance at http://www
.crypto.com/blog/spycerts/
 >
 > Also, Wired has a story here: http://www.wired.com/threatlevel/2010/03/packet
- -forensics/
 > -matt

- -------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com

------- End of Forwarded Message

---

From: Yoav Nir <[email-masked]>
Date: Thu, 25 Mar 2010 01:21:07 +0200

Oh, where do I start.

1. This is not a new attack. If you can get a CA to issue a bad certificate, you can then use that certificate to impersonate the legitimate web site. Government co-ercion does not make this a new attack, and the results are no different from a CA employee being coerced or bribed by criminals.

2. Section 5 is entitled "evidence", and then goes on to present the evidence: a marketing brochure and something someone told him at a booth in a trade show.

3. Section 6 is ominously entitled "Some CAs Already Participate In Surveillance". I read that expecting more of a smoking gun than that guy in a trade show from section 5. Instead, we go straight to naming names, in section 6.1, "Verisign". Naming and shaming the biggest commercial CA? No. More like innuendo. The section begins with a description of Verisign's business dealings with telecoms and government, with the implication that they're "in bed" with the evil governments. So is the evidence coming next. No, and I'll quote:
  We have no evidence to suggest that the CA unit
  within VeriSign has ever been compelled by the US
  government to produce a certicate for use by in-
  telligence agencies. Likewise, we have no evidence
  to suggest that VeriSign has ever broken any laws,
  or improperly disclosed consumers' private data to
  government agencies.

4. Lastly there's the solution, which is entirely based on countries. If your Chinese bank all of a sudden has an American certificate, the browser kvetches. But the prominence of Verisign actually defeats this defense. A lot of companies from various countries buy certificates from Verisign, either through a local Verisign affiliate, or from Verisign US through a US branch or sales office.  Even my own company does that ( https://www.checkpoint.com )  This also does not solve the problem, only localizes it. If the government in Elbonia wants a certificate for anything, they will lean on the local branch of Verisign (or just bribe an employee) and get a certificate that chains back to Verisign (US). And criminals will do the same.

On Mar 24, 2010, at 2:08 PM, =JeffH wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> Scanned by Check Point Total Security Gateway.

---

From: ArkanoiD <[email-masked]>
Date: Thu, 25 Mar 2010 07:14:02 +0300

Well, that's quite obvious that PKI in the "big internet" as we know it is
just a card house: if *ANY* CA we trust get compromised or mailicious, it
is all flawed. There is nothing we can do besides examining chain of trust
manually and watching for certificate changes. The TOFU technology described there is quite obvious, i always wondered why ssh has it and browsers do not.

It is completely out of the scope of the certid list, though :-(

---

From: Marsh Ray <[email-masked]>
Date: Thu, 25 Mar 2010 12:40:46 -0500

On 3/24/2010 11:14 PM, ArkanoiD wrote:
> Well, that's quite obvious that PKI in the "big internet" as we know
> it is just a card house

True, but there are lots of card houses in compsec in the sense that
flipping just one bit the right way results in a complete compromise.

Predicting whether or not that single bit logic will prove to be robust
or fragile in actual deployed systems is an art form that designers are
still learning. This is as much a social-political-economic-human issue
as a technical one.

I don't see what the big worry is about a CA being "compromised" by some
government. It looks to me like many of the trusted roots installed by
typical software are pseudo-governmental entities (e.g., post offices)
in the first place.

http://support.apple.com/kb/HT3580
> Below is a list of trusted root certificates which are pre-installed
> with the iPhone 3.0 software.
> Subject Name
>      Country Name                 : US
>      Organization Name            : U.S. Government

There's nothing subversive about that, it's totally out in the open.

> if *ANY* CA we trust get compromised or mailicious, it is all
> flawed.

>From the perspective of the https server, that understates it a bit.

Because the https server cannot independently prove the absence of a
mitm, he must rely on the client to do a good job of this.

Thus, the web server ends up transitively trusting _every_ trusted root
cert in _every_ client which connects.

Remember the README for PGP?

  Trusting a key is not the same as trusting the key's owner. Trust is
  not necessarily transferable; I have a friend who I trust not to lie.
  He's a gullible person who trusts the President not to lie. That
  doesn't mean I trust the President not to lie. This is just common
  sense. If I trust Alice's signature on a key, and Alice trusts
  Charlie's signature on a key, that does not imply that I have to
  trust Charlie's signature on a key.
     -- Philip Zimmerman

Transitive trust in this case has brought about the near-complete failure
of the original mission of PKI in ssl (allowing you to shop online).

The only reason that the world isn't up-in-arms about it is that 59% of
PCs are pwned by malware already, making the slightly more complicated
mitm attack unnecessary.

However, there are important uses of SSL/TLS other than end user web
browsers. These are probably better off with just the minimal number of
trusted roots on the clients. But if you're going to the trouble of
reconfiguring your clients anyway, why not just set up your own private CA?

IMHO, the $B+ certificate industry needs to work harder at improving
their actual effective security value than it currently does if they
want the world to continue fund their existence.

> There is nothing we can do besides examining chain of trust manually
> and watching for certificate changes.

We could implement our protocols such that the remote peer is required
to satisfy multiple chains of trust.

When a chain is only as strong as its weakest link, it's best to have
several of them (in a redundant configuration).

> The TOFU technology described
> there is quite obvious, i always wondered why ssh has it and browsers
> do not.

In theory, SSH's approach is inferior to SSL's PKI. In practice it's not
inferior only to the extent that the user is good at scrutinizing the
new keys he gets presented.

If you want that behavior in a web browser, just delete all your trusted
root certs and add a persistent explicit trust whenever you see a cert
the first time. (I have tried this in Firefox)

- Marsh

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 25 Mar 2010 15:33:39 -0400

> reconfiguring your clients anyway, why not just set up your own private CA?

Running your own X.509 CA works if your goal is only
intra-organizational communication.  As soon as you want to federate
communication with external organizations, running your own CA is
insufficient with X.509, because the model only allows a single
certifier per certificate.

> several of them (in a redundant configuration).

This is possible today using out-of-band OpenPGP certification, which
permits multiple certifiers per certificate.

 http://web.monkeysphere.info/

We currently have it working bidirectionally for openssh and
unidirectionally (firefox browsers can authenticate servers) for https.
 More is coming soon, and feedback is welcome, particularly from folks
who are interested in TLS mechanisms.

> the first time. (I have tried this in Firefox)

I believe you can do this system-wide with firefox and other
mozilla-based browsers by removing the nssckbi shared library
(/usr/lib/nss/libnssckbi.so on debian, a .dll someplace on windows),
which provides the pre-defined list of root CAs.

	--dkg

---

From: Ben Laurie <[email-masked]>
Date: Thu, 25 Mar 2010 19:49:12 +0000

> who are interested in TLS mechanisms.

Cool!

---

From: ArkanoiD <[email-masked]>
Date: Thu, 25 Mar 2010 23:24:00 +0300

That's what cross-certification and multiple path validation is for.
Browsers do not support it directly but i wrote a validating mitm proxy
which address this problem among with others.

---

From: Story Henry <[email-masked]>
Date: Thu, 25 Mar 2010 21:58:47 +0100

Context: the  recent publication "Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL"

   http://files.cloudprivacy.net/ssl-mitm.pdf

> certifier per certificate.

Yes, this is a very important point made by Kaminsky in an interview last year
http://searchsecurity.techtarget.com/news/interview/0,289202,sid14_gci1360143,00.html

What is interesting for me is this last paragraph of the paper under discussion:

[[
The CA system is fundamentally broken, and must be overhauled. DNSSEC may 
play a significant role in solving this problem, or at least reducing the
number of entities who can be compelled to violate users’ trust.
]]

What would be possible, and I think Kaminsky is considering this line of
 thinking, is something that is logically similar to foaf+ssl 
( http://esw.w3.org/Foaf%2Bssl ) namely to put the CA cert (or signature) 
in the DNS record.

Let us start by an important philosophical distinction between sense and 
reference. The sense of a word is something like a dictionary definition 
of it, its referent is the the object. 

Applying this to DNS, let us say that the reference of a domain name is
a set of machines. But the sense of this is to be found in the DNS resource 
records. So if one can securely put the DNS public key (indirect) identifier 
in the records then the client can verify the certificate sent by the server
by comparing it with the DNS record.

Foaf+ssl works in a similar way to identify agents. Agents have URLs that 
refer to them, and the sense of this name is to be found in a document on the web.

So

 http://bblfish.net/#hjs

Refers to me, and the description about that is to be found in

 http://bblfish.net/

(note: of course those should be https urls)

In the document about me ( http://bblfish.net/ ) I publish a number of 
public keys. Any server I then connect to can ask me for my client 
certificate and on receiving it, find in the subject alternative name 
my WebId ( http://bblfish.net/#hjs ), dereference that and query the 
returned graph to check if I have the public key that was found in 
my certificate. Since the TLS connection was only possible because I 
had the private key of the public key found in the certificate, and 
verified at the WebId, we have authentication.

DNSSEC could use exactly the same procedure, just reversed to identify 
the server. Instead of using https URLs we use Domain Names, and the 
lookup is whatever the protocol for looking at DNS records is.

To prove this one would just need to adapt the proof presented in 
"FOAF+SSL: Creating a Web of Trust without Key Signing Parties" 

http://blogs.sun.com/bblfish/entry/more_on_authorization_in_foaf

	Henry Story

---

From: Story Henry <[email-masked]>
Date: Fri, 26 Mar 2010 01:41:49 +0100

> http://blogs.sun.com/bblfish/entry/more_on_authorization_in_foaf

Sorry, I meant the proof presented in 
"FOAF+SSL: RESTful Authentication for the Social Web"

http://bblfish.net/tmp/2009/05/spot2009_submission_15.pdf

Henry

---

From: ArkanoiD <[email-masked]>
Date: Fri, 26 Mar 2010 15:08:15 +0300

Well, i guess i should investigate if FOAF is applicable to my thingie:

http://milliways.chance.ru/~ark/benevolent-ssl-mitm.pdf

anyways, issuing warnings on *any* certificate changes (it is done for
self-signed certificates only at the moment) is easy..

On Fri, Mar 26, 2010 at 01:41:49AM +0100, Story Henry wrote:
> email protected and scanned by AdvascanTM - keeping email useful - www.advascan.com 
> 
>