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

[Martin Rex <Martin.Rex at sap.com>]

Pasi.Eronen at nokia.com wrote:
> 
> 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).

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

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

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
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls