Subject: Re: [TLS] Implementation survey: Client Certificate URL extension

From: Martin Rex <[email-masked]>
Date: Thu, 3 Apr 2008 18:10:19 +0200 (MEST)

If you read the news, you probably noticed the following paper
today or these days:

https://www.cynops.de/techzone/http_over_x509.html

Although this Papers describes a serious design flaw in the
rfc3280 suggestion to put URLs of intermediate CAs into X.509v3
cert extensions and have peers use them in order to be able
to build a certification path, the very same problem will
apply to every concept that a communication peer can be
coerced to access one or more arbitrary URLs prior to
authentication, and the Client Certificate URL extension
appears to suffer the same vulnerabilities and security
problems.

-Martin
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 04 Apr 2008 18:42:31 +1300

Martin Rex <[email-masked]> writes:

>Although this Papers describes a serious design flaw in the rfc3280
>suggestion to put URLs of intermediate CAs into X.509v3 cert extensions and
>have peers use them in order to be able to build a certification path, the
>very same problem will apply to every concept that a communication peer can
>be coerced to access one or more arbitrary URLs prior to authentication, and
>the Client Certificate URL extension appears to suffer the same
>vulnerabilities and security problems.

This has been known for a long time, and is even worse in protocols like OCSP
where you can use this facility to scan and penetrate corporate networks, use
machines as attack amplifiers, and so on.  The PKIX response in the past has
been "not our problem".

I don't know if the TLS WG wants to make it their problem or not.  It's always
seemed a very obvious flaw, my code deliberately doesn't support any of these
"turn a host into an attacker-controlled proxy" extensions.

Peter.

---

From: <[email-masked]>
Date: Fri, 4 Apr 2008 11:24:30 +0300

This vulnerability of Client Certificate URL is already described in
the Security Considerations text in RFC 4366, so it isn't anything
particularly new.

In the context of web browsing over TLS, it isn't really different
than, say, the ability to include IMG URLs pointing to arbitrary hosts
(not just the one the HTML page came from).

I can see that this could be more of a problem in other contexts:
e.g., email clients don't usually fetch image URLs (since that would
reveal that the address works, when the email was read, approximate
network location of the client, etc.) -- but if they fetch URLs during
S/MIME certification path validation, it would have roughly the same
result.

Best regards,
Pasi

> -----Original Message-----
> From: ext Martin Rex [mailto:[email-masked]] 
> Sent: 03 April, 2008 19:10
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [TLS] Implementation survey: Client Certificate 
> URL extension
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Apr 2008 14:53:39 +0200 (MEST)

> (not just the one the HTML page came from).

It is completely different!

The regular HTTP/HTML based attacks attack the client/browser.

The certificate extensions and the client-cert-URL extension for TLS
attack the server, and there is no "must visit a hostile website" involved
at all, the server is guaranteed to fall prey to every attack automatically
if it supports/implements such a feature (or "inherits" this feature
from the underlying middleware).

> S/MIME certification path validation, it would have roughly the same

For some firewalls it is sufficient to call a particular URL from
the inside (with parameters tacked at the end of the URL) in order
to open a hole that can be entered from the outside.

Generating advertising "clicks" might be another abuse. 

Being able to coerce a server to access an arbitrary URL from the
inside of his network is IMHO a pretty serious security problem.

-Martin

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 05 Apr 2008 02:16:47 +1300

Martin Rex <[email-masked]> writes:

>For some firewalls it is sufficient to call a particular URL from the inside
>(with parameters tacked at the end of the URL) in order to open a hole that
>can be entered from the outside.
>
>Being able to coerce a server to access an arbitrary URL from the inside of
>his network is IMHO a pretty serious security problem.

It's even worse than that, it's turning the server into an attacker-controlled
proxy inside the firewall.  For example I can perform port scans of an
organisation's internal network (and in general attack its internal servers)
using this "feature".  I'll see if I can dig up the postings about this,
although since the discussion was up to 10 years ago I'm not sure if I still
have them.

Peter.

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 04 Apr 2008 18:24:58 -0700

> Generating advertising "clicks" might be another abuse. 

Generating "clicks" on child porno sites might be enough to bring the FBI
to visit the victim site's sys admins, in the USA.

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 10:35:07 +0300

Martin Rex wrote:
> > than, say, the ability to include IMG URLs pointing to arbitrary
> > hosts (not just the one the HTML page came from).
> 
> attack the server, and there is no "must visit a hostile website"
> involved at all, the server is guaranteed to fall prey to every
> attack automatically if it supports/implements such a feature (or
> "inherits" this feature from the underlying middleware).

You're quite right, I wasn't thinking clearly -- this is indeed
quite different, since it targets the server.

Nevertheless, it is described in RFC 4366 already; do you think
there's something more we should add in 4366bis?

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Apr 2008 17:49:17 +0200 (MEST)

> there's something more we should add in 4366bis?

Security Considerations, section 6.3 of rfc4366 already describes the
problems and implications in quite detail (I wasn't aware of that).
But maybe that isn't scary enough?  Personally, I feel quite uncomfortable
with such a dangerous extension in an IETF standard.  *I* can NOT think
of a safe mode of operation for the client certificate URL extension.
As soon as the admins enables it, his server is toast.  Do we really need
to standardize something that is so extremely dangerous?

Btw. why should rfc4346bis (TLS 1.2) obsolete rfc4366 (TLS extensions)?
draft-ietf-tls-rfc4346-bis-09.txt has this in the second line:
  Obsoletes (if approved): RFC 3268, 4346, 4366

None of the vital Security Considerations from rfc4366 was merged into
rfc4346bis, so this appears to be an error.
There is a fairly fresh rfc4366bis I-D claiming to obsolete rfc4366.

-Martin

---

From: Mike <[email-masked]>
Date: Thu, 10 Apr 2008 09:01:43 -0700

> to standardize something that is so extremely dangerous?

This could be made safe with some help from PKIX (if X.509 doesn't
already support it -- I haven't read RFC 3280 or -bis in a while).
If root certificates listed constraints on what constitutes a valid
URL for retrieving issued certificates, then a server could scan
the combined list from each trusted root to determine if it is safe
to fetch a client certificate.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Apr 2008 09:06:36 -0700

At Thu, 10 Apr 2008 17:49:17 +0200 (MEST),
> to standardize something that is so extremely dangerous?

Too late for that. Plus, it's not like this is the only place this
kind of thing is standardized. Cf. web pages.

> There is a fairly fresh rfc4366bis I-D claiming to obsolete rfc4366.

Together 4346-bis and 4366 bis obsolete 4366.

As far as I know the security considerations in 4346-bis do cover
the security considerations for the extensions mechanism itself
and the extensions described in the document.

-Ekr

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 10 Apr 2008 17:45:06 -0700

> to fetch a client certificate.

Are you all aware of this paper, now making a stir?

It claims that fetching CA certs from URLs found in AIA extensions in certs
that have not yet been validated is a vulnerability.  At least one browser
organization known to me agrees.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Apr 2008 18:08:25 -0700

At Thu, 10 Apr 2008 17:45:06 -0700,
>     https://www.cynops.de/techzone/http_over_x509.html

Yes, Martin cited this paper a few weeks ago.

> organization known to me agrees.

How does that organization feel about inline images in HTML pages?

-Ekr

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 10 Apr 2008 18:28:54 -0700

> How does that organization feel about inline images in HTML pages?

The problem isn't so much when browsers initiate fetches for certs from
servers.  The major concerns are:
a) servers fetching URLs from unvetted client auth certs, and
b) mail clients fetching certs to verify signatures in emails from strangers.

Some email clients, in particular, are good at not fetching remote content
from html emails, which confirms email addresses to spammers.  AIA cert
fetching weakens their ability to defend against such attempts to validate
email addresses.

Servers see them selves as similarly weakened.

I'm receiving inquiries about white listing CA URLs for AIA fetching. :(
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Apr 2008 19:15:37 -0700

At Thu, 10 Apr 2008 18:28:54 -0700,
> I'm receiving inquiries about white listing CA URLs for AIA fetching. :(

I assume these people are up in arms about DKIM, then?

-Ekr

---

From: Mike <[email-masked]>
Date: Thu, 10 Apr 2008 20:20:52 -0700

> organization known to me agrees.

What I suggested is that the information about which URL's are safe
for the client certificate URL extension could be embedded in the
-root- certificate, which you trust.  When a client sends you a URL
in place of a certificate, you would compare it to the information
in each of your root certificates.  If the URL matches one of them,
you know it's safe to retrieve it; otherwise you best not.  Also,
theoretically it would be wasted effort since you would not be able
to build a complete certificate chain.  So this could also improve
performance in cases where client authentication will fail.

Mike

---

From: Florian Weimer <[email-masked]>
Date: Fri, 11 Apr 2008 14:15:14 +0200

> kind of thing is standardized. Cf. web pages.

The more relevant example seems to be DTD fetching for XML documents
(which can be triggered by automated document submission to a web
server).  It turns out that it's difficult to switch that off in many
processing environments.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 11 Apr 2008 11:38:22 -0700

> I assume these people are up in arms about DKIM, then?

No, they're just not doing DKIM.  Otherwise they might be. :)
With respect to email, their concern is presently limited to S/MIME v3.
Their concern is: take an existing S/MIME v3 MUA and upgrade the cert
verification library to one that can do AIA cert fetching: vulnerable.
But of course, this email concern is a bit off topic for this list. :)
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 11 Apr 2008 12:31:07 -0700

Mike wrote, On 2008-04-10 20:20:
> you know it's safe to retrieve it; otherwise you best not. 

Please look at a diagram of the US Federal Bridge CA PKI, or the equivalent
bridged PKI in Japan or South Korea, and tell us how your proposal would
work in those environments.

Regards,
/Nelson

---

From: Mike <[email-masked]>
Date: Fri, 11 Apr 2008 19:59:30 -0700

> work in those environments.

I don't know the specifics of any PKI, but I think the answer is
the same for any one of them.  A server can not blindly retrieve
any URL presented by a client, so it needs to be configured as to
what URL's are acceptable.  One way to accomplish that is to put
the information in the CA certificates as I suggested.

If your question was meant to say that this would be difficult
to do for those PKI's because servers don't know all of the
intermediate CA's and don't have all of their certificates, then
the answer is that they either need to be configured with those
missing certificates, or they can't safely support the client
certificate URL extension for those clients.  This seems to be
a case where you can't have your cake and eat it too.

Mike