5 ms·

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 s

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 12y ago
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.
smutticus 12y ago
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'

billyhoffman 12y ago

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.

smutticus 12y ago

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'