Tim Berners-Lee: TLS Everywhere, Not Https: URIs | Hacker News Reader

Tim Berners-Lee: TLS Everywhere, Not Https: URIs

w3.org

20 pointscpeterso4 comments

I think timbl has some good points here, but they're mixed in with FUD. Also, phasing out the https namespace is a bad an idea as moving everything to https.

I think the best bet would be to allow TLS over port 80, call it http. Mark any sites that don't upgrade to TLS on port 80 as insecure, like unsigned certs are now. Allow unsigned certs on port 80. Enforce key pinning on port 80 and warn users when the pins don't match. Keep 443 for TLS with valid certs.

This leaves port 80 as untrusted traffic and explicitly marks trivially exploited traffic as broken. It protects against many attacks as any http traffic that's MITMed will show up as being intercepted as long as it's not the first time the user makes that connection. https can stay as the secure one that non-technical users are trained to look for when they need security.

I get the sense that this article is saying something both simple and important, but I'm having a difficult time getting it.

Here is what I think it might be saying. Critique, please.

1. Web security is increasingly important, both in terms of data being delivered securely, and users knowing what has been done securely and what has not.

2. The move to use HTTPS as much as possible is a problem, since, if some resources involved in a web app can be fetched via HTTPS, but some cannot, then all-or-nothing browser security policies break the app.

3. An alternate solution is:

A. Regular HTTP should fetch things securely as much as possible, using Transport Layer Security (TLS).

B. Browsers should give the user a clear indication of whether all data related to the current display are being handled securely.

----

And my response:

I don't see why SSL vs. TLS is an issue.

What matters is, first, whether any given bunch of data can be handled securely, second, whether a fallback is used if it cannot be, third, whether the browser clearly and reliably informs the user of the security situation, and fourth, whether the user gets information they can understand and use.

Why then, is TBL concerned about which protocol is used? I don't see it.

What I got from this piece is that TBL's top priority is to not want to "break the web." His beef seems to be that, for a variety of reasons, "transmit this content securely" was codified into part of the URL for a resource. So if someone made a hyperlink to http://www.example.com, and as owner of the www.example.com website tomorrow you switched to HTTPS only to "secure" the contents of www.example.com, that all those old http:// style hyperlinks will break. TBL talks about how, if security was implemented on top of HTTP, instead of being a separate protocol, then deciding "use security for this" would not break hyperlinks.

This seems like a pedantic argument to make and it pushes the burden on users, who consistently make terrible choices regarding security. TBL's idea that content owners should not define that something must be accessed security, but that the users should seems to fly in the face of security best practices. Additionally, there are severe technical challenges in upgrading an insecure communications channel (http) to a secure one (https). Look at the problems with STARTTLS. You need some extra data or side channel or configuration so the client know when it should not keep using a channel, unless it is secure. Otherwise you are screwed. So you are back to the problem of how does an owner communicate to a client, in a hyperlink, to access something only with security.

TBL also ignores that shifting to HTTPS does not necessarily "break the web". There are many mechanisms that can be used to the hyperlinks don't break, and redirect you where you need to go.

1) SSL and TLS are basically the same thing. We just changed the name when we reached SSLv4. TLSv1 == SSLv4

2) TBL is concerned that changing the URI by appending an 's' to 'http' it breaks web links. He considers it a mistake made 20 years ago to indicate the use of encryption in the URI prefix.

This scenario:

1) Resource located at 'http'

2) Operator in charge of resource enforces HTTPS

3) Link from #1 no longer works because URI is now 'https'

Reply on news.ycombinator.com