Re: [TLS] Summarizing identity change discussion so far

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> Marsh Ray wrote:
> > [e-mail] wrote:
> > >
> > > The security considerations section of this draft has to describe the
> > > fact that even with this fix, renegotiation does things that will
> > > surprise application developers,

I fully agree.

> > 
> > Does it? This fix ensures that the same party is on each end for the
> > entire connection. This rules out a MitM switching connections around.

The secure TLS renegotiation _ONLY_  assures that the TLS endpoint
can not be tranferred among different peers without their _consent_
during renegotiation.  An MitM attacker is someone acting without consent.

As long as switching of the identity is permitted during renegotiation
(which it currently is), there is only a vague concept of
"party" at the other end.


> 
> > If we make any recommendations for TLS libraries it should be to
> > not do renegotiation unless the application asks for it by
> > registering a callback.

Clients usually do _not_ want renegotiation, but they have no say
in the TLS handshake.  It is the Server which decides whether to
ask for a certificate on the initial handshake or whether the
server wants to make up his mind only after having seen the clients
request.

The issue is often usability / user-experience.  If you ask a Browser
for a certificate on the initial connect, it will result in a popup
windows to the user, even if that user has no certificate.  It
is possible to configure the browser to suppress this popup,
but often the browser has only a single configuration option
that says "select automatically", and that does actually two
different things, i.e. use a client certificate when the request
from the server matches exactly one client cert -- an the latter
is something one might want _not_ to happen automatically--in
contrast to automatic reply that no client cert is available.


> 
> I think the fact that "getPeerCertificate()" and similar API calls
> can return a different value each time they're called would be a
> surprise to most app developers.

Definitely.


> 
> Well, although the example in James Manger's email is not real (in the
> sense that it's not from real code), I think it's plausible, and it
> doesn't involve an app already coded for switching identities
> intentionally.
> 
> I guess an even worse example would be something like this:
> 
>   conn = openTlsConnection(host, port)
>   if not verifyCertChain(conn.getPeerCert()):
>      raise "Not a valid cert"
>   if conn.getPeerCert().getName() != expected_name:
>      raise "Name in certificate doesn't match"
>   # continue...
> 
> Most TLS libraries seem to support both callback and get() style
> functions for accessing/checking certificates.
> 
> Although using the callback-style APIs might be more common (and in
> some sence nicer, since it allows you to abort the handshake 
> a bit earlier -- but an app developer might not care about this very 
> much), I think it would be a surprise to most app developers that 
> using the get-style APIs might not be secure.
> 
> (And I wouldn't be surprised at all if real applications using
> those get() style APIs are found...) 

The get-style API is _the_only_ API that I provide to our applications.
Besides, I'm coming from the GSS-API world, and there never was
a callback API.

If you think that get-style API is dangerous, then you seem to be
quite unaware about the risks involved with some of the callback APIs
(besides being difficult to use in distributed architectures).

TLS peers should check the peer's ID before they start sending
or receiving any data over the newly established TLS session.

Apps protocols that infer from a successful TLS handshake that
previously received plaintext data is authenticated suffer from
a serious apps-level design flaw.

Abusing GSS-API or TLS as an OTP plaintext authentication scheme
is IMHO a severe APPS design flaw.  The ability to complete a
TLS handshake (or to establish a gssapi security context)
does not, by itself, convey any kind of intent.
Apps that infer intent from this, should really rethink their
flawed architecture.


-Martin