Re: [TLS] Simple way to drop re-negotiation in HTTP (Re: draft-rescorla-tls-renegotiate.txt)

[Marsh Ray <[e-mail]>]

Nicolas Williams wrote:
> The simplest way to drop re-negotiation in web servers is this (based on
> an idea by Nelson Bolyard):
> 
>  - start two instances of the web server, one on an alternate port
>    number, with the same contents
> 
>  - the primary instance will accept TLS user authentication, but will
>    not require it
> 
>  - the instance on the alternate port will always require TLS user
>    authentication
> 
>  - neither instance accepts TLS re-negotiations
> 
>  - whenever the primary instance of the web server would request user
>    authentication via TLS do this instead: re-direct to client to the
>    same resource on the alternate port.
> 
> That's almost entirely automatic.

> The only thing a webmaster must do is
> pick a suitable port number for the instance that requires user
> authentication.

Wow that does make it sound easy. All we need to do for HTTPS is get a
new port number assigned and the entire burden of the solution passes
from the TLS specs to server implementors and site admins?

Think of what this is proposing: all sites that currently depend on
renegotiation have to adjust their configuration. They have to
reconfigure their server's internal filters to allow the port. They have
to reconfigure their border firewalls to allow the new port. Every web
proxy device has to be reconfigured to support the new port. Web
applications that check for that magic number 443 will need to be
updated. We'll ignore reverse proxies and SSL offload for now.

Say only 5% of sites depend on renegotiation. OK, only 5% admins need to
reconfigure. Well, how well-tested is everything outside of those
admins' networks going to be? How well does the 5% case tend to work
end-to-end?

Every client-side filter that watches outbound connections has to know
what that new port is being used for. Non-browser client code has to be
reviewed and possibly rewritten because it doesn't necessarily follow
HTTP redirects. Same-origin policies for cookies have to be checked for
how they handle the redirect to the new port.

Suppose that some ecommerce retailer is sending free smart-cards and usb
readers to 500K of their best customers this year (I got one in the mail
a few years ago). These cards web-enabled! (I.e. they present client
certs under the hood.) Armies of young, energetic support people will
spend the best years of their careers explaining to end users how to
reconfigure their ZoneAlarm.

>  - neither instance accepts TLS re-negotiations

Oh yes, even with all that...you still need to update every web server
and client and TLS stack in the world!

> The redirects [] can be avoided somewhat
> by re-writing URLs in contents served to point to the right server
> instance.

Oh my.

- Marsh