Re: draft-ietf-tls-http-upgrade reissued

Hi,

John Stracke wrote:

> Julien Pierre wrote:
>
> > John Stracke wrote:
> >
> > > Just because a client always asks to upgrade doesn't mean the server has to obey.
> >
> > So how does that make the draft useful if the upgrade is never allowed ?
>
> Who said never?
>
> A client that wants to use the draft can ask for an upgrade on every HTTP request.
> Servers that aren't willing to spend cycles on TLS for a particular request can just
> ignore the Upgrade: header.

That still does not solve the problem !!!

If the client tries to upgrade to TLS on every request, it will fail 99% of the time,
because servers don't support it. Suppose in 1% of the cases it will actually work.

Now, suppose that in 2% of the cases, the request data was intended to be confidential
and the user really didn't want to submit the data unsecured, but the server didn't
negotiate TLS. The only way for a user to make sure he does not mistakenly submit data
unencrypted is to setup his browser to prompt him on every single HTTP request that
didn't successfully negotiate TLS.

In other words, a waste of time 98% of requests. Do you really find that to be acceptable
?

The whole point I'm trying to make is that there should be a way for a web application
that is intended to be secure to enforce that fact and reasonably function on a server
running on a common port with HTTP and TLS upgrade support. The draft does not propose a
way to do that.

It would be as simple as a new type of "httpt" URL - which would tell the user-agent to
connect insecurely with the server, and immediately negotiate a TLS connection; and
otherwise not to proceed if the TLS upgrade fail. This cannot be a global user-agent
setting for reasons explained before - security is not always required nor desirable.

If you really want to get ISPs to stop wasting IP addresses on multiple secure servers,
as well as separate the ports, then you need to make it possible to create new secure web
applications that will work with the new user-agents and servers proposed in the new
draft, without incurring a high risk of falling back to non-secure connections. The draft
is currently too vague in the way that the security is enforced and makes it way too easy
to shoot yourself in the foot and end up with a non-secure connection if the negotiation
fails, rather than aborting.

--
for a good time, try kill -9 -1