Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)

[Marsh Ray <[e-mail]>]

On 11/11/2010 10:41 AM, t.petch wrote:
>
> To return to (what I see as) the main purpose of the thread, I too
> think that StartTLS is a good, if not an excellent idea; I see no
> difference in the vulnerabilities (although my cryptanalysis is weak).

Well, that's the thing. In theory there is no difference, in practice 
however...

Look at HTTP/HTTPS as an example. It doesn't use STARTTLS to negotiate 
an optional security upgrade. Well there is an RFC for it but I've never 
heard of anyone using it, if that functionality is latent, no one is 
depending on it.

The first thing users learn about web security is to put the 's' on the 
end of HTTPS.

The first thing web developers/admins do when setting up a secure site 
is to bind it to port 443. They can set port 80 to redirect port 443. 
The web developer can easily test that this is working in his web 
browser. The web site publishes 'https:' links and the user bookmarks 
them. If the TLS isn't working, no data is transferred. The TLS isn't 
optional. (You might raise the point that most users don't know the 
difference, but consider all the programmatic SOAP/web service clients 
which do.)

On the other hand, my email program gives me an option to use 
"STARTTLS". Even after I took packet captures of the connection process 
and observed it correctly negotiating the use of encryption, I still 
cannot tell if my email is vulnerable to a downgrade attack. The only 
way to find out is by performing exhaustive testing with an attack tool, 
or by direct inspection of the source code!

There are certainly a lot of things we could say about HTTPS security, 
but I believe that in this case has something valuable which 
STARTTLS-based protocols typically do not.

- Marsh