Subject: Re: [TLS] AIA cert fetching seen as harmful

From: [email-masked] (Peter Gutmann)
Date: Tue, 15 Apr 2008 01:35:42 +1200

Mike <[email-masked]> writes:

>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.

And then you look up that URL in your trusted DNS... oops.

(This also ignores the fact that you have to reissue your root cert every time
some random server moves around, which I can't see any CA doing.  Root certs
are issued once, given a lifetime of 20-40 years, and then never touched again
for fear of breaking things).

The real problem here is that a server should never, ever initiate outgoing
connections under the control of an external agent, which is what a lot of the
PKIX protocols expect them to do.  Other examples (just off the top of my
head) are the logotypes and qualified certs/biometrics RFCs, which define an
extension containing a URI that you're supposed to go to for further
information.  So a server, when seeing one of these certs, is supposed to go
to whatever arbitrary location and port is specified and poke around there
(I'm not sure what would happen if you entered, for example, an SSH URI
instead of the more obvious HTTP one, but if the implementation is general
enough you could use it for password-guessing attacks on internal SSH
servers).  It's just a really, really bad idea to build a capability for HTTP
bounce scans into a (supposedly) passive protocol mechanism, and in particular
turning a system that's supposed to provide security into a security hole just
doesn't seem a winning long-term strategy to me.

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

---

From: Mike <[email-masked]>
Date: Mon, 14 Apr 2008 07:52:10 -0700

> And then you look up that URL in your trusted DNS... oops.

Sure it's a potential attack, but consider the relative difficulty.  If
you do nothing and use the client certificate URL extension as it is
today, all an attacker has to do is follow the protocol and specify a
bogus URL in the client hello.  Such a program could be written in a
matter of hours and widely distributed for the amusement of script
kiddies the world over.

With the addition of URL constraints embedded in CA certificates, an
attacker would have to actively modify DNS packets or mess with routes
or whatever to launch an attack.  This is a risk that some server
operators are probably willing to take, while they would probably not
accept the problems without the constraints, except in tightly
controlled environments.

> for fear of breaking things).

You can plan for change by putting something like:

    http://*.client-cert-url-repo.some-ca.com

in the root certificate and then assigning subdomains for each
intermediate CA.  The DNS would point to the particular machine with
the certificates.  If a server moves, you just change the DNS record.
Of course with this an attacker can proxy attack the repository
machines, so that needs to be considered.

> PKIX protocols expect them to do. 

I have no stake in it, so I don't care one way or the other if the
client certificate URL extension is removed.  I just had an idea for
how to improve the situation.

Mike

---

From: Mike <[email-masked]>
Date: Mon, 14 Apr 2008 07:58:59 -0700

> bogus URL in the client hello.

Sorry, I meant the CertificateURL message.

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Apr 2008 10:12:23 -0500

On Tue, Apr 15, 2008 at 01:35:42AM +1200, Peter Gutmann wrote:
>       [...].  So a server, when seeing one of these certs, is supposed to go

I agree.  I think AIA can be useful -- to the client.

Servers should ignore AIA, and clients should always send enough of
their certificate chain to servers, and/or PKIX-based protocols should
allow for additional round-trips when a client didn't send enough of its
chain initially.

I think that allowing for multiple round-trips here (e.g., in TLS) is
the better answer, but I suspect that's also hard to pull off now, which
leaves us with clients sending their whole chains (to some TA selected
by the client, which hopefully will be good enough for the server to
build its view of the client's cert validation path).

Nico
--

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 15 Apr 2008 18:49:47 +1200

Mike <[email-masked]> writes:

>With the addition of URL constraints embedded in CA certificates, an attacker
>would have to actively modify DNS packets or mess with routes or whatever to
>launch an attack.

This may be worth the effort though.  Someone pointed out (off-list) something
I hadn't thought about much, that internal servers are patched/updated a lot
less often than web-facing ones (after all, they're behind the firewall so
there's no need to risk breaking things with constant patching).  So you could
end up with a network full of older Red Hat machines that are out of
subscription and no longer get updates, or masses of flaky internal-use-only
web scripts and whatnot which are OK to use because they're beind the firewall
(in fact has anyone who's ever worked at any sort of sizeable organisation
*not* run into flaky hacked-together web scripts/apps for internal use only?).
So your AIA contains a location of:

  http://192.168.1.1:8080/timesheet.asp?userid=1234;DROP%20TABLE%20USERS

I'll bet there are a lot of people out there who'd be willing to poke with the
DNS for a chance to do that to <insert favourite big corporate target>.  We
know, from years of experience, that it's hard enough to
filter/whitelist/protect hardened web-facing servers, what AIA does is expose
totally vulnerable, unpatched, poorly-written apps and internal servers to the
same level of attack.

Peter.