Re: [TLS] Implementation survey: Client Certificate URL extension
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Implementation survey: Client Certificate URL extension
Pasi.Eronen at nokia.com wrote:
>
> Martin Rex wrote:
> > 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).
>
> 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?
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
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.