
Tim Berners-Lee: TLS Everywhere, Not Https: URIs - cpeterso
http://www.w3.org/DesignIssues/Security-NotTheS.html
======
MatthewWilkes
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.

------
ggchappell
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.

~~~
billyhoffman
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](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://](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.

