Not all information needs to be secure, pure and simple, and individual anonymity is more important for the health of internet culture than all the security in the world.<p>This section covers my feelings on the topic:<p>"TLS does not provide privacy. What it does is disable anonymous access to ensure authority. It changes access patterns away from decentralized caching to more centralized authority control. That is the opposite of privacy. TLS is desirable for access to account-based services wherein anonymity is not a concern (and usually not even allowed). TLS is NOT desirable for access to public information, except in that it provides an ephemeral form of message integrity that is a weak replacement for content integrity."
<i>TLS everywhere is great for large companies with a financial stake in Internet centralization. It is even better for those providing identity services and TLS-outsourcing via CDNs. It's a shame that the IETF has been abused in this way to promote a campaign that will effectively end anonymous access, under the guise of promoting privacy.</i><p>I think he makes a very good point here: if browsers did not support plaintext HTTP at all, and only CA-verified TLS, it would be practically impossible for those who want to run a server somewhere, to anonymously serve a site containing public information. If everyone has to obtain a certificate from a CA, that is another way they can be tracked by a central authority.
> Roy Thomas Fielding (born 1965) is an American computer scientist,[1] one of the principal authors of the HTTP specification, an authority on computer network architecture[2] and co-founder of the Apache HTTP Server project.<p><a href="http://en.wikipedia.org/wiki/Roy_Fielding" rel="nofollow">http://en.wikipedia.org/wiki/Roy_Fielding</a><p>A good read, and he's not just blowing smoke.<p>> If the IETF wants to improve privacy, it should work on protocols that provide anonymous
access to signed artifacts (authentication of the content, not the connection) that is
independent of the user's access mechanism.<p>But it seems to me that there is basically no way to request access to any kind of data, without it being traceable in some manner; at the very least the ISP would still see the traffic. I guess you could argue for TOR, but that still allows vectors and has its own issues to worry about.<p>Funny, we need the same kinda access that radio and TV used to provide; where you could just "tune in" to something and have a listen, and you were more or less untraceable; even if you were to broadcast on that frequency your traceability, while triangulable, is still fairly anonymous. But on the internet, there is no such way to broadcast like that. Maybe that's a design flaw, maybe it's a feature.
100% agree. If you want to ensure the integrity of content, then sign the content. If you want to protect people's interactions with websites when exchanging non-public data then use encryption when that's warranted. But credential-based encryption should never be used across sites or with public data because (as the poster notes) it just becomes another way in which broader interaction with the Internet can be tracked.<p>It's trading yet more liberty for just a little bit more security, and haven't we all done enough of that already?
"authentication of the content, not the connection"<p>Popular websites that hold themselves out as businesses, i.e. "exclusive" sources of content (often generated by users, go figure), they have no reason to support this concept. Because then it does not matter where the user gets the content. But they might have reasons to support TLS.<p>One could argue users want authentic content (signed content), not authentic "websites" (single sources for content trying to serve too many users, all at the same time).<p>Or maybe many users do not know the difference?<p>Van Jacobsen gave a good talk on this at Google:<p><a href="http://www.youtube.com/watch?v=8Z685OF-PS8" rel="nofollow">http://www.youtube.com/watch?v=8Z685OF-PS8</a><p>There is another thread on the HN front page right now about a Blackhat conference talk on x86 CPUs. There is another talk on that page about how TLS relies on the trustworthiness of internet routing.<p>What is the point of securing connections when you have no control over routing?<p>Instead of relying on securing "connections", I think schemes that send out "encrypted blobs" with the hope they arrive at the proper destination make more sense.<p>Encrypting blobs is not something for which an "authority" is needed. This is something over which the user can retain full control without involving third parties. As it should be.<p>TLS might have encryption that works well enough to "secure a connection" but if I am not mistaken it still has no reliable way to verify an endpoint (recipient) is the one you want it to be. Some people call that "authentication".<p>I'm not even sure that TLS can reliably perform "authentication of the connection" as Fielding states.<p>For that, I think SSH is a better protocol.
This doesn't feel right to me. No one can touch this man's credentials, but lets suspend the argument of authority for a second and look at what he is saying critically: Is TLS more private overall than plantext http?<p>If you want to remain private, how could TLS prevent this that plaintext would not? HTTP is not tor.
Can anyone explain what he's referring to with the statement<p>> <i>with TLS in place, it becomes easy and
commonplace to send stored authentication credentials in those requests, without visibility,
and without the ability to easily reset those credentials (unlike in-the-clear cookies).</i>?<p>Cookies are orthogonal to presence of TLS, I thought (unless they're marked as secure, in which case they are only supplied to https hosts?)<p>Is there some other way of identifying a particular user/browser/session[1] other than the quirks & features enumerator along hte lines of Panopticlick?<p>If there is (ISTR some 'session storage' for resuming TLS in nginx), is that cross-trackable across different services (potentially all TLS-terminating in the same place, such as Cloudflare or AWS)?<p>One good point is that I hadn't considered is that the lack of proxyability means every request which can't be filled from the browser cache <i>must</i> hit the actual endpoint, making it easier for them to follow along action-by-action when it might otherwise have been served up before getting to them by a caching middle-proxy.<p>My (limited) understanding is that you're potentially providing more information to the remote service, but are better secured against people snooping on your traffic as it flows between you and them.<p>[1] also not including client certificates, because exactly 1 site on the internet actually uses them :P
I found the title a bit misleading.<p>He's arguing that viewing public information over HTTPS is no more private than doing so without encryption.<p>Sure, insofar as an entire response consists only of public information, this is a tautology, isn't it?
> If the IETF wants to improve privacy, it should work on protocols that provide anonymous access to signed artifacts (authentication of the content, not the connection) that is independent of the user's access mechanism.<p>He basically wants a better version of Freenet. Fine. However, that's orthogonal to the effort to make all channels secure channels. IETF can do <i>both</i>, if people are interested. Plaintext TCP needs to die, and building the infrastructure to move everyone to HTTPS is a step in that direction.<p>He shouldn't obstruct HTTPS just because it's not Freenet(bis). To use his Freenet(bis) vaporware, people will need to become familiar with managing private keys. HTTPS has a similar requirement, so HTTPS Everywhere is a step in the direction he wants to go.
> TLS is NOT desirable for access to public information, except in that it provides an ephemeral form of message integrity that is a weak replacement for content integrity.<p>TLS both encrypts and authenticates the response. Is TLS authentication a "weak replacement" for some other, better "content integrity" system that's widely available in browsers?<p>Roy suggests content signatures... but is there a web mechanism to authenticate <i>those</i>? Or is he just wishing there were something better than TLS? (Don't we all?)
<p><pre><code> > If the IETF wants to improve privacy, it should work on protocols
> that provide anonymous access to signed artifacts (authentication
> of the content, not the connection) that is independent of the
> user's access mechanism.
[...]
> It would be better to provide content signatures and encourage
> mirroring, just to be a good example, but I don't expect eggs to
> show up before chickens.
</code></pre>
If I wanted to have the eggs before the chickens, what would I do?
Sign my content with PGP? Sign the HTML file? Offer it as separate signed download? Are there examples of pages doing this?
This sounds like complete PR reality distortion.<p>How exactly is TLS different to plaintext in anonymity? - There is no client-cert.<p>Also HTTPs everywhere does not necessarily mean "real" CAs. Self signed certs, even without pinning, would raise the bar of snooping from monitoring (easy) to traffic manipulation (hard). In this case there would not be a green lock in the address bar of course.<p>This whole thread feels like one propaganda attempt to sway the techinal community. And yes, here is where the people to manipulate are.
I would wager that absolutely no one has ever become uniquely identifable as a result of using TLS. People have MAC and IP addresses tied to their real identities. People have social media profiles and run scripts from dozens of places on every page load.<p>Can someone please describe a situation in which someone reasonably wouldn't have been trackable to Google or to the NSA, but becomes trackable as a result of HTTPS?<p>I can't think of one. Screw this guy and his politics.
The thing being commented on is here: <a href="https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere" rel="nofollow">https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEveryw...</a>
Is there a way I can view this with line wrapping in Firefox or in Chrome?<p>EDIT: Using Firefox Dev Ed, there's a little "Reader View" icon on the right hand side of the address bar that seems to do the trick.
Https for everything is worthy for at least one reason: to shut up the scum operators who insert their ads. Privacy and confidentiality are of a much less importance.
agree also<p>tls is not https3.<p>tls already has been broken 3+ times.<p>this is an open ticket for 1 year in the TLS repo for an exploit.<p>and the author of TLS released a MITM exploit on TLS he wrote (not that other protocols are not vulnerable to MITM)<p>theres no reason to put this in SSH/SSL/HTTP and run all internet communication over it.
Roy is a wannabe industry shill who plays politics at a very amateur level. Roy could care less about your privacy, as long as ads and tracking work. He fundamentally thinks that ad blocking is theft and that you have no right to privacy.<p>- an ex-tracking protection working group member.