11 ms·

Re: Proposed Statement on "HTTPS everywhere for the IETF"

147 points by glenscott1 11y ago

deleted 11y ago
[deleted]
Aloha 11y ago
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. This section covers my feelings on the topic: "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."
- asperous 11y ago
  If authorities wanted control, couldn't they disable caching? How is TLS any less private than standard http? You aren't associating your session keys to your browser any more than a standard cookie.
- kijin 11y ago
  How does TLS disable anonymous access? My identity and/or location is not a single bit more exposed than it already is when I access a site either with or without TLS. There are indeed authority and centralization issues with the current CA system, but again, it has nothing to do with my anonymity. Meanwhile, caching is such an overused and undersubstantiated argument that it's not even funny anymore. How many websites you recently visited was served by a cache operated by anyone other than the same party who owns the website, or a CDN that the website owner trusts enough to let them have the TLS keys? Are untrusted proxies (read: MITM as a service) such an integral part of the web that we must keep them alive at any cost? There are decent reasons to eschew TLS for public information -- for example, PGP signatures that can be verified out-of-band are much cheaper for large blobs of static data such as .deb packages -- but anonymity and caching are not among them.
  - cm2187 11y ago
    Perhaps he is referring to TLS Session Resumption which might be a form of cookie (as it identifies the user across sessions). But it still hides what you are transferring from anyone observing the traffic.
    - frankchn 11y ago
      Maybe, but currently some site today can set a cookie in your browser and track you anyway -- a lot simpler than fiddling with the TLS stack. I assume that if you browse in "Private Browsing" or "Incognito" mode, then the TLS Session Resumption data is wiped once you exit that mode (similar to how cookies and local storage is wiped).
      - cm2187 11y ago
        The site you visit yes. But I am referring to a MITM. A cookie would be hidden by the secure tunnel. But the TLS resemption parameters might be visible as it happens before the tunnel is established. I am not familiar enough with the protocole to know if it is the case.
        frankchn 11y ago
        Ah, I see. Yes, from a cursory glance at RFC 5077, it seems that the SessionTicket is sent as part of ClientHello, which is not encrypted (page 6). This is still no worse than plain unencrypted HTTP at worst, and server admins or clients could well choose not to support this if they do not wish to.
        kijin 11y ago
        The resumption parameters might be used to uniquely identify a person... that's an interesting point. But is that a big enough flaw to justify throwing out the baby of TLS with the bathwater of tiny details like that? I'm sure there are people who are much smarter than both of us who can fix that without giving up on TLS altogether.
- espadrine 11y ago
  > individual anonymity is more important for the health of internet culture than all the security in the world. TLS provides exactly as much anonymity as HTTP (ie, none), so it is not trading that away. It only wins security without losing anything. Mr Fielding suggests a hypothetical system that would keep the same amount of privacy as HTTP while ensuring the integrity of the content. But without a proof that it works (or even a full design — how does it prevent a MITM from substituting the signature too?), we can't know that it has any potential. And it certainly doesn't have value now, since it doesn't exist yet. Even if it did exist, the same amount of privacy as HTTP is still the same amount of privacy as TLS. And integrity is not something we can overlook. Imagine that, say, the Chinese government changed a set of RFCs inside its border by MITM them, in such a way as to suggest a different but compatible implementation of cookies that allows them to read them. Then chinese implementors would create insecure tools, and weaken privacy tremendously!
  - skrebbel 11y ago
    > TLS provides exactly as much anonymity as HTTP (ie, none), so it is not trading that away. It only wins security without losing anything. This is simply not true. If I request a resource from a server that is cached by my ISP, my request never reaches the source server and they'll never be able to measure that I requested that resource.
    - frankchn 11y ago
      Hypothetically that is true, but do any ISPs do these sort of large-scale caching of resources any more? Also, if the site wants to track you that way, couldn't they (or anyone in the middle of your connection) just send no-cache headers with everything and a well behaved transparent cache will retrieve from origin every time anyway? In any case, personally I am inclined to trust the operators of the websites I visit more than Comcast, my ISP. I do not want my ISP to do anything to my traffic except to forward it on to the intended recipient.
    - pdkl95 11y ago
      So you want your ISP to MITM-attack your requests? (transparent proxy of your outgoing plaintext HTTP) Outside of unusual local/niche applications, are ISPs even doing this? (with Verizon doing their MITM to add their deplorable X-UIDH head, I suppose this is possible) It would probably be a huge copyright violation for any ISP to cache without some sort of negotiated agreement with the website. If such negotiations did happen, that just moves the anonymity problem from the website to the ISP, ascting as the website's agent. Local ISP caching in traditional Akamai-style was a DNS trick where your browser makes an explicit reqest to the local cache. You would still make the same requests into the cache no matter the transport.
- frik 11y ago
  HTTP/2 based on the work of SPDY is upcoming protocol. http://en.wikipedia.org/wiki/HTTP/2 http://en.wikipedia.org/wiki/HTTP/2 HTTP/2 a binary protocol whereas all other major internet protocols are text based (HTTP0.x, HTTP1.x, POP3, SMTP, IMAP, etc.). https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD... HTTP/2 requires an SSL certificate. HTTP/2 specification contains a "prioritisation" of data as a hint for the server, instead of the idea of caching data on the client. With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritize certain packets for parties who pay extra. I am not into this debates, but it would be certainly a disadvantage for startups over established parties. Given the many problems with SSL (heartbeat, broken/outdated certs, hijacked cert vendors) an HTTP/2 without SSL would be a nice fallback scenario - wildcard certs for new startups are still a bit expensive, especially if one will have to replace (=costs) the certs every few months due security concerns. Even the largest commerce website Amazon.com only uses HTTPS for a tiny little fraction, the payment dialog page (which requires with its separate login). It seems HTTP/2 is good for big companies that operate centralized services to save traffic. Whereas the current HTTP 0.x and HTTP 1.x is proven to be good enough for everyone. There is a threat that some popular web services might get HTTP/2-only access in a few years. Maybe the Firefox forks Iceweasel/Fennec/etc and Chromium forks can make the HTTP/2 protocol support an opt-in (and not the other way around).
  - quonn 11y ago
    > With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritize certain packets for parties who pay extra FUD. There is nothing like that in HTTP/2 and indeed that can't be, because packet routing happens several layers below. If anything, the fact that it's encrypted makes deep packet inspection and content-based routing decisions more difficult. By the way, Amazon.com fully supports HTTPS. I'm using a browser extension to enforce this whenever possible and have browsed Amazon HTTPS-only for years.
    - frik 11y ago
      FUD is on your side. Check slide 37 and 38: https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.gae999cde7_0_86 https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD... "With HTTP/2 browsers prioritize requests based on type/context, and immediately dispatch the request as soon as the resource is discovered. The priority is communicated to the server as weights + dependencies. [...] Responsibility is on the server to deliver the bytes in the right order!" With HTTP/2 a malicious website may send you the advertisement and tracking code first, then wait and later send you the actual content data. With HTTP/1 a browser plugin can decide to not download a advertisement related tracking JS file, simple and effective. Correct me if I am wrong or misunderstood HTTP/2 - but with constructive arguments and sources. Edit: I believe in ads sponsored websites. Ads about the topic of websites are great, though like many I dislike personalized invasive ads that follow me around websites about things I already bought anyway or never will. I would like an "fair"-AdBlocker that only blocks invasive ads and allow the good ads.
- jsingleton 11y ago
  Let's take the argument that news sites are public information and should not be encrypted. This argument breaks down pretty quickly if someone wants to inject bad things into public WiFi but there is another, more subtle, problem. TLS stops a passive snooper (like GCHQ or a coffee shop) from seeing exactly what content you are reading as only the host is sent in the clear and not the full path. For example, it would be difficult to see exactly what articles I am reading on HN but trivial to see what I like to look at on BBC or The Guardian. You can build up quite a profile of someone from what they choose to read. This could be used for national "security" or advertising purposes. It can also have a chilling effect if people think twice before clicking on a controversial headline.
- josteink 11y ago
  > Not all information needs to be secure, pure and simple It seems most HTTPS proponents across this thread seems to ignore this very thing. Not everything needs to be secure. Pure and simple. Don't argue about what part of TLS does that with what cookie. We're not even listening to this, as it's not interesting to us. If you want us to listen, you should try to argue why you think we need TLS for everything. We don't. So why are you so hellbent on making our lives more complicated than they need to be?
  - mhurron 11y ago
    What is the downside of having it all secured? On top of that, having only data that must be secure makes it very apperent to anyone looking that 'hey this is totally important information.' Having everything encrypted makes all encrypted traffic seem perfectly normal.
    - josteink 11y ago
      HTTPS brings complexity. In lots of cases I dont want that complexity. Sometimes that complexity gives rise to (heartbeat) bugs, problems and stability issues. When it doesn't, it always leads to more work. I want to be able to setup a website, access that website instantly without having to meddle with getting SSL-certs, or creating my own self-signed certs. Sometimes you want consumers to be software, components (IoT thingies) which doesn't always have an up to date crypto-stack or have a crypto-stack at all. Getting them to accept the HTTPS website can result in all kinds of issues (ref wget --no-check-certificate, even on modern Linux systems)... In general, getting HTTPS up and running is about an order of magnitude more work than plain HTTP. And if you don't need it, why should you be forced to put in the effort? The answer is obvious: You shouldn't. Because you don't need HTTPS everywhere. You don't. That's a purely factual statement. I cannot for the life of me see how anyone has a problem accepting that.
  - pdkl95 11y ago
    You may be ok with the world eavesdropping on some of your communications with third parties. That is your opinion, and you can use whatever protocols you want. What you don't get to do is force the rest of us to make the same choices. What has become very clear in recent years is that far too much usable data can be extracted out of noisy channels. Any amount of identifying bits leaked where an eavesdropper can hear them can effectively remove the privacy you thought you had elsewhere. Also, keep in mind that the ISP itself is often the enemy. Are you cool with Verizon editing ALL of your HTTP to add X-UIDH identifiers? What about if they do the same trick in a side channel, keying to a hash of your HTTP request and IP? The problem here is that the idea that there exists a subset of HTTP requests that do no "need to be secure" is really just a restatement of the "but I"m not a target" fallacy. Targeting presumes a human with intent, when the threat is a computer that builds a database of all the traffic it can see. So yes, data needs to be secured, and that means all that we possibly can. > If you want us to listen If you want US to listen, you will need to wake up to the brave new world of pattern-of-life analysis and stop trying to keep the world in plaintext. I don't like a lot of things about TLS, but it is the crypto we have right now; I would love having better, less complicated options in the future. If you find it complicated, that's your problem. What you apparently see as a technical discussion some of us see as a human rights problem, and stopping the surveillance-as-a-business-model industry (and the occasional overly-ambitious government agency) ranks quite a bit higher than complaints about a few standards becoming a bit more work to implement.
thwd 11y ago
I found the title a bit misleading. He's arguing that viewing public information over HTTPS is no more private than doing so without encryption. Sure, insofar as an entire response consists only of public information, this is a tautology, isn't it?
- perokreco 11y ago
  No, because you would want to keep the fact that you read something private.
  - thwd 11y ago
    Fair enough, the HTTP request path can be hidden through TLS. I'm not sure if privacy is a goal of HTTPS, though. On the internet layer, IP packets can still be traced from origin to client. I'm probably not involved enough to formulate an educated opinion, however.
  - Confusion 11y ago
    Yes, and Roy's claim is that TLS doesn't provide that privacy, so is still basically useless for public content.
    - quonn 11y ago
      His argument is mostly based on analysing the size of the data transferred. Let's assume HTTP/2 for the moment. You have a single encrypted channel to a particular website that contains multiple interleaved opaque streams. It's not easily possible to extract the exact size of a single request from this. Furthermore, for a typical news website, for example, there will be an huge number of pages, they are dynamic and constantly changing and they will all have a very similar size. You do get privacy. If anyone claims otherwise, he should go and prove that it's possible and easy by providing a firesheep-like tool. It would make for a nice research paper.
      - jrnvs 11y ago
        Here's an article describing how to find out what someone is watching on Google Maps by analyzing the encrypted traffic. http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-goo...
empressplay 11y ago
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. It's trading yet more liberty for just a little bit more security, and haven't we all done enough of that already?
- quonn 11y ago
  > But credential-based encryption TLS does usually not use client-certificates, so it is not credential-based for the user.
- Animats 11y ago
  "100% agree. If you want to ensure the integrity of content, then sign the content." That's what "subresource integrity"[1] is about. For static data, a cryptographic hash of the linked content is attached to links. This detects any modifications of the document. Now you can use a CDN without trusting it. A big problem with "HTTPS Everywhere" is that it encourages termination of the secure connection at a CDN. The CDN can then tamper with the content. Some do, adding ads and trackers. Subresource integrity will detect such tampering, but HTTPS Everywhere will not. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
  - realityking 11y ago
    As the name implies, this only works for subresources (scripts, stylesheets, images, etc.) and is mainly useful for cross origin requests. HTTPS on the other hand also gurantees that the article I'm reading hasn't been modified. And that no one has injected ads into the site.
    - Animats 11y ago
      If you're using a CDN, you don't know if the CDN has injected ads or spyware. If you use Cloudflare's RocketLoader, what the user gets is not what you sent. Once a CDN is involved in "HTTPS Everywhere", it's security theater.
meesterdude 11y ago
> 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. http://en.wikipedia.org/wiki/Roy_Fielding http://en.wikipedia.org/wiki/Roy_Fielding A good read, and he's not just blowing smoke. > 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. 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. 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.
- aidos 11y ago
  ....And the guy that came up with REST https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
  - nbevans 11y ago
    REST was more just a clarification and formal study to describe the intended way of using HTTP.
- weland 11y ago
  I do believe such a protocol could be devised (after all, you can broadcast IP packets), but those are trivial to block through wires. It's hard not to think that volunteers' mesh networks are a better choice here.
dfabulich 11y ago
> 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. 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? Roy suggests content signatures... but is there a web mechanism to authenticate those? Or is he just wishing there were something better than TLS? (Don't we all?)
- URSpider94 11y ago
  I think his point is not that TLS is not good at securing information from the host to the viewer, his point is that in doing so, it leaks information about the viewer to the host and potentially to third parties. For public information, TLS effectively asks each viewer to sign the guest register in return for seeing the page. Contrast this with the case where you could download one giant file with hashes for millions of public sites. Once you have a copy of that file, you can now fetch a copy of any of those pages from any source you like, and still validate that your copy is authentic without losing any trace that you accessed that file.
shabble 11y ago
Can anyone explain what he's referring to with the statement > 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).? 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?) Is there some other way of identifying a particular user/browser/session[1] other than the quirks & features enumerator along hte lines of Panopticlick? 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)? 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 must 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. 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. [1] also not including client certificates, because exactly 1 site on the internet actually uses them :P
- somethingnew 11y ago
  Besides Session IDs and Session Tickets[1] which already exist in the TLS protocol. He could be referring to the Token Binding Protocol Draft[2] which, quoting from it's summary, "allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections". [1] https://en.wikipedia.org/wiki/Transport_Layer_Security#Resumed_TLS_handshake https://en.wikipedia.org/wiki/Transport_Layer_Security#Resum... [2] https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01 https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01
mc_hammer 11y ago
agree also tls is not https3. tls already has been broken 3+ times. this is an open ticket for 1 year in the TLS repo for an exploit. and the author of TLS released a MITM exploit on TLS he wrote (not that other protocols are not vulnerable to MITM) theres no reason to put this in SSH/SSL/HTTP and run all internet communication over it.
asperous 11y ago
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? If you want to remain private, how could TLS prevent this that plaintext would not? HTTP is not tor.
- JulianMorrison 11y ago
  I think the argument is "HTTP is edge cached (by your ISP, etc) and so a request need not imply a connection received at the remote end. HTTPS is not subject to caching or other benign man-in-the-middle operations so knowledge of who clicked what is centrally available." This feels like a weak objection to me, since the government will just snoop at the ISP level.
sklogic 11y ago
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.
dlitz 11y ago
> 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. 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 both, if people are interested. Plaintext TCP needs to die, and building the infrastructure to move everyone to HTTPS is a step in that direction. 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.
- daily_dose 11y ago
  >Plaintext TCP needs to die, and building the infrastructure to move everyone to HTTPS is a step in that direction. Why does it need to die?
userbinator 11y ago
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 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.
- kijin 11y ago
  > if browsers did not support plaintext HTTP at all, and only CA-verified TLS That's a very big "if", and it reeks of FUD. Show me a browser that has any plan to drop support for plaintext HTTP any time in the foreseeable future. Firefox ain't one of them. Last time I checked, their plan was to reserve some of the more dangerous features (such as access to the camera) for secure websites. Hardly a plan to drop support for plaintext HTTP. If you still aren't convinced that the current controversy is just a bunch of FUD, I'll bet $100 that 10 years from now, I'll still be able to post public information (say, the full text of RFC 2616) on a plain HTTP site and have you access it with a mainstream browser.
  - iopq 11y ago
    Firefox is moving in that direction. Maybe by 2020 you'll have to click a lot of prompts to see an "insecure" site.
    - kijin 11y ago
      Classic slippery slope argument. When abortion was legalized, some people argued that we'd be murdering children soon. Has that happened? If something is moving in the right direction, but if you're worried that it will go too far, the solution is to get involved and stop it at the right time, not to spread FUD about the hypothetical doom of the world.
donottrack2010 11y ago
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. - an ex-tracking protection working group member.
- cactusface 11y ago
  Can you say more about that?
- revelation 11y ago
  It certainly seems that hes more obsessed with some hypothetical potential political economic scenario than the tech aspects of it. Stick to the tech.
nchelluri 11y ago
Is there a way I can view this with line wrapping in Firefox or in Chrome? 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.
tvvocold 11y ago
>It would be better to provide content signatures and encourage mirroring. What does it mean? Mirror Site?
nickysielicki 11y ago
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. 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? I can't think of one. Screw this guy and his politics.
ysleepy 11y ago
This sounds like complete PR reality distortion. How exactly is TLS different to plaintext in anonymity? - There is no client-cert. 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. This whole thread feels like one propaganda attempt to sway the techinal community. And yes, here is where the people to manipulate are.
weinzierl 11y ago
> 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. 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?
JulianMorrison 11y ago
The thing being commented on is here: https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEveryw...
gwu78 11y ago
"authentication of the content, not the connection" 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. 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). Or maybe many users do not know the difference? Van Jacobsen gave a good talk on this at Google: http://www.youtube.com/watch?v=8Z685OF-PS8 http://www.youtube.com/watch?v=8Z685OF-PS8 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. What is the point of securing connections when you have no control over routing? 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. 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. 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". I'm not even sure that TLS can reliably perform "authentication of the connection" as Fielding states. For that, I think SSH is a better protocol.
tveita 11y ago
HTTPS link: https://www.ietf.org/mail-archive/web/ietf/current/msg93416.html https://www.ietf.org/mail-archive/web/ietf/current/msg93416....

147 points by glenscott1 11y ago

deleted 11y ago

[deleted]

Aloha 11y ago

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. This section covers my feelings on the topic: "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."

asperous 11y ago
If authorities wanted control, couldn't they disable caching? How is TLS any less private than standard http? You aren't associating your session keys to your browser any more than a standard cookie.
kijin 11y ago
How does TLS disable anonymous access? My identity and/or location is not a single bit more exposed than it already is when I access a site either with or without TLS. There are indeed authority and centralization issues with the current CA system, but again, it has nothing to do with my anonymity. Meanwhile, caching is such an overused and undersubstantiated argument that it's not even funny anymore. How many websites you recently visited was served by a cache operated by anyone other than the same party who owns the website, or a CDN that the website owner trusts enough to let them have the TLS keys? Are untrusted proxies (read: MITM as a service) such an integral part of the web that we must keep them alive at any cost? There are decent reasons to eschew TLS for public information -- for example, PGP signatures that can be verified out-of-band are much cheaper for large blobs of static data such as .deb packages -- but anonymity and caching are not among them.
- cm2187 11y ago
  Perhaps he is referring to TLS Session Resumption which might be a form of cookie (as it identifies the user across sessions). But it still hides what you are transferring from anyone observing the traffic.
  - frankchn 11y ago
    Maybe, but currently some site today can set a cookie in your browser and track you anyway -- a lot simpler than fiddling with the TLS stack. I assume that if you browse in "Private Browsing" or "Incognito" mode, then the TLS Session Resumption data is wiped once you exit that mode (similar to how cookies and local storage is wiped).
    - cm2187 11y ago
      The site you visit yes. But I am referring to a MITM. A cookie would be hidden by the secure tunnel. But the TLS resemption parameters might be visible as it happens before the tunnel is established. I am not familiar enough with the protocole to know if it is the case.
      - frankchn 11y ago
        Ah, I see. Yes, from a cursory glance at RFC 5077, it seems that the SessionTicket is sent as part of ClientHello, which is not encrypted (page 6). This is still no worse than plain unencrypted HTTP at worst, and server admins or clients could well choose not to support this if they do not wish to.
      - kijin 11y ago
        The resumption parameters might be used to uniquely identify a person... that's an interesting point. But is that a big enough flaw to justify throwing out the baby of TLS with the bathwater of tiny details like that? I'm sure there are people who are much smarter than both of us who can fix that without giving up on TLS altogether.
espadrine 11y ago
> individual anonymity is more important for the health of internet culture than all the security in the world. TLS provides exactly as much anonymity as HTTP (ie, none), so it is not trading that away. It only wins security without losing anything. Mr Fielding suggests a hypothetical system that would keep the same amount of privacy as HTTP while ensuring the integrity of the content. But without a proof that it works (or even a full design — how does it prevent a MITM from substituting the signature too?), we can't know that it has any potential. And it certainly doesn't have value now, since it doesn't exist yet. Even if it did exist, the same amount of privacy as HTTP is still the same amount of privacy as TLS. And integrity is not something we can overlook. Imagine that, say, the Chinese government changed a set of RFCs inside its border by MITM them, in such a way as to suggest a different but compatible implementation of cookies that allows them to read them. Then chinese implementors would create insecure tools, and weaken privacy tremendously!
- skrebbel 11y ago
  > TLS provides exactly as much anonymity as HTTP (ie, none), so it is not trading that away. It only wins security without losing anything. This is simply not true. If I request a resource from a server that is cached by my ISP, my request never reaches the source server and they'll never be able to measure that I requested that resource.
  - frankchn 11y ago
    Hypothetically that is true, but do any ISPs do these sort of large-scale caching of resources any more? Also, if the site wants to track you that way, couldn't they (or anyone in the middle of your connection) just send no-cache headers with everything and a well behaved transparent cache will retrieve from origin every time anyway? In any case, personally I am inclined to trust the operators of the websites I visit more than Comcast, my ISP. I do not want my ISP to do anything to my traffic except to forward it on to the intended recipient.
  - pdkl95 11y ago
    So you want your ISP to MITM-attack your requests? (transparent proxy of your outgoing plaintext HTTP) Outside of unusual local/niche applications, are ISPs even doing this? (with Verizon doing their MITM to add their deplorable X-UIDH head, I suppose this is possible) It would probably be a huge copyright violation for any ISP to cache without some sort of negotiated agreement with the website. If such negotiations did happen, that just moves the anonymity problem from the website to the ISP, ascting as the website's agent. Local ISP caching in traditional Akamai-style was a DNS trick where your browser makes an explicit reqest to the local cache. You would still make the same requests into the cache no matter the transport.
frik 11y ago
HTTP/2 based on the work of SPDY is upcoming protocol. http://en.wikipedia.org/wiki/HTTP/2 http://en.wikipedia.org/wiki/HTTP/2 HTTP/2 a binary protocol whereas all other major internet protocols are text based (HTTP0.x, HTTP1.x, POP3, SMTP, IMAP, etc.). https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD... HTTP/2 requires an SSL certificate. HTTP/2 specification contains a "prioritisation" of data as a hint for the server, instead of the idea of caching data on the client. With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritize certain packets for parties who pay extra. I am not into this debates, but it would be certainly a disadvantage for startups over established parties. Given the many problems with SSL (heartbeat, broken/outdated certs, hijacked cert vendors) an HTTP/2 without SSL would be a nice fallback scenario - wildcard certs for new startups are still a bit expensive, especially if one will have to replace (=costs) the certs every few months due security concerns. Even the largest commerce website Amazon.com only uses HTTPS for a tiny little fraction, the payment dialog page (which requires with its separate login). It seems HTTP/2 is good for big companies that operate centralized services to save traffic. Whereas the current HTTP 0.x and HTTP 1.x is proven to be good enough for everyone. There is a threat that some popular web services might get HTTP/2-only access in a few years. Maybe the Firefox forks Iceweasel/Fennec/etc and Chromium forks can make the HTTP/2 protocol support an opt-in (and not the other way around).
- quonn 11y ago
  > With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritize certain packets for parties who pay extra FUD. There is nothing like that in HTTP/2 and indeed that can't be, because packet routing happens several layers below. If anything, the fact that it's encrypted makes deep packet inspection and content-based routing decisions more difficult. By the way, Amazon.com fully supports HTTPS. I'm using a browser extension to enforce this whenever possible and have browsed Amazon HTTPS-only for years.
  - frik 11y ago
    FUD is on your side. Check slide 37 and 38: https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.gae999cde7_0_86 https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD... "With HTTP/2 browsers prioritize requests based on type/context, and immediately dispatch the request as soon as the resource is discovered. The priority is communicated to the server as weights + dependencies. [...] Responsibility is on the server to deliver the bytes in the right order!" With HTTP/2 a malicious website may send you the advertisement and tracking code first, then wait and later send you the actual content data. With HTTP/1 a browser plugin can decide to not download a advertisement related tracking JS file, simple and effective. Correct me if I am wrong or misunderstood HTTP/2 - but with constructive arguments and sources. Edit: I believe in ads sponsored websites. Ads about the topic of websites are great, though like many I dislike personalized invasive ads that follow me around websites about things I already bought anyway or never will. I would like an "fair"-AdBlocker that only blocks invasive ads and allow the good ads.
jsingleton 11y ago
Let's take the argument that news sites are public information and should not be encrypted. This argument breaks down pretty quickly if someone wants to inject bad things into public WiFi but there is another, more subtle, problem. TLS stops a passive snooper (like GCHQ or a coffee shop) from seeing exactly what content you are reading as only the host is sent in the clear and not the full path. For example, it would be difficult to see exactly what articles I am reading on HN but trivial to see what I like to look at on BBC or The Guardian. You can build up quite a profile of someone from what they choose to read. This could be used for national "security" or advertising purposes. It can also have a chilling effect if people think twice before clicking on a controversial headline.
josteink 11y ago
> Not all information needs to be secure, pure and simple It seems most HTTPS proponents across this thread seems to ignore this very thing. Not everything needs to be secure. Pure and simple. Don't argue about what part of TLS does that with what cookie. We're not even listening to this, as it's not interesting to us. If you want us to listen, you should try to argue why you think we need TLS for everything. We don't. So why are you so hellbent on making our lives more complicated than they need to be?
- mhurron 11y ago
  What is the downside of having it all secured? On top of that, having only data that must be secure makes it very apperent to anyone looking that 'hey this is totally important information.' Having everything encrypted makes all encrypted traffic seem perfectly normal.
  - josteink 11y ago
    HTTPS brings complexity. In lots of cases I dont want that complexity. Sometimes that complexity gives rise to (heartbeat) bugs, problems and stability issues. When it doesn't, it always leads to more work. I want to be able to setup a website, access that website instantly without having to meddle with getting SSL-certs, or creating my own self-signed certs. Sometimes you want consumers to be software, components (IoT thingies) which doesn't always have an up to date crypto-stack or have a crypto-stack at all. Getting them to accept the HTTPS website can result in all kinds of issues (ref wget --no-check-certificate, even on modern Linux systems)... In general, getting HTTPS up and running is about an order of magnitude more work than plain HTTP. And if you don't need it, why should you be forced to put in the effort? The answer is obvious: You shouldn't. Because you don't need HTTPS everywhere. You don't. That's a purely factual statement. I cannot for the life of me see how anyone has a problem accepting that.
- pdkl95 11y ago
  You may be ok with the world eavesdropping on some of your communications with third parties. That is your opinion, and you can use whatever protocols you want. What you don't get to do is force the rest of us to make the same choices. What has become very clear in recent years is that far too much usable data can be extracted out of noisy channels. Any amount of identifying bits leaked where an eavesdropper can hear them can effectively remove the privacy you thought you had elsewhere. Also, keep in mind that the ISP itself is often the enemy. Are you cool with Verizon editing ALL of your HTTP to add X-UIDH identifiers? What about if they do the same trick in a side channel, keying to a hash of your HTTP request and IP? The problem here is that the idea that there exists a subset of HTTP requests that do no "need to be secure" is really just a restatement of the "but I"m not a target" fallacy. Targeting presumes a human with intent, when the threat is a computer that builds a database of all the traffic it can see. So yes, data needs to be secured, and that means all that we possibly can. > If you want us to listen If you want US to listen, you will need to wake up to the brave new world of pattern-of-life analysis and stop trying to keep the world in plaintext. I don't like a lot of things about TLS, but it is the crypto we have right now; I would love having better, less complicated options in the future. If you find it complicated, that's your problem. What you apparently see as a technical discussion some of us see as a human rights problem, and stopping the surveillance-as-a-business-model industry (and the occasional overly-ambitious government agency) ranks quite a bit higher than complaints about a few standards becoming a bit more work to implement.

thwd 11y ago

I found the title a bit misleading. He's arguing that viewing public information over HTTPS is no more private than doing so without encryption. Sure, insofar as an entire response consists only of public information, this is a tautology, isn't it?

perokreco 11y ago
No, because you would want to keep the fact that you read something private.
- thwd 11y ago
  Fair enough, the HTTP request path can be hidden through TLS. I'm not sure if privacy is a goal of HTTPS, though. On the internet layer, IP packets can still be traced from origin to client. I'm probably not involved enough to formulate an educated opinion, however.
- Confusion 11y ago
  Yes, and Roy's claim is that TLS doesn't provide that privacy, so is still basically useless for public content.
  - quonn 11y ago
    His argument is mostly based on analysing the size of the data transferred. Let's assume HTTP/2 for the moment. You have a single encrypted channel to a particular website that contains multiple interleaved opaque streams. It's not easily possible to extract the exact size of a single request from this. Furthermore, for a typical news website, for example, there will be an huge number of pages, they are dynamic and constantly changing and they will all have a very similar size. You do get privacy. If anyone claims otherwise, he should go and prove that it's possible and easy by providing a firesheep-like tool. It would make for a nice research paper.
    - jrnvs 11y ago
      Here's an article describing how to find out what someone is watching on Google Maps by analyzing the encrypted traffic. http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-goo...

empressplay 11y ago

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. It's trading yet more liberty for just a little bit more security, and haven't we all done enough of that already?

quonn 11y ago
> But credential-based encryption TLS does usually not use client-certificates, so it is not credential-based for the user.
Animats 11y ago
"100% agree. If you want to ensure the integrity of content, then sign the content." That's what "subresource integrity"[1] is about. For static data, a cryptographic hash of the linked content is attached to links. This detects any modifications of the document. Now you can use a CDN without trusting it. A big problem with "HTTPS Everywhere" is that it encourages termination of the secure connection at a CDN. The CDN can then tamper with the content. Some do, adding ads and trackers. Subresource integrity will detect such tampering, but HTTPS Everywhere will not. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
- realityking 11y ago
  As the name implies, this only works for subresources (scripts, stylesheets, images, etc.) and is mainly useful for cross origin requests. HTTPS on the other hand also gurantees that the article I'm reading hasn't been modified. And that no one has injected ads into the site.
  - Animats 11y ago
    If you're using a CDN, you don't know if the CDN has injected ads or spyware. If you use Cloudflare's RocketLoader, what the user gets is not what you sent. Once a CDN is involved in "HTTPS Everywhere", it's security theater.

meesterdude 11y ago

> 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. http://en.wikipedia.org/wiki/Roy_Fielding http://en.wikipedia.org/wiki/Roy_Fielding A good read, and he's not just blowing smoke. > 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. 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. 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.

aidos 11y ago
....And the guy that came up with REST https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
- nbevans 11y ago
  REST was more just a clarification and formal study to describe the intended way of using HTTP.
weland 11y ago
I do believe such a protocol could be devised (after all, you can broadcast IP packets), but those are trivial to block through wires. It's hard not to think that volunteers' mesh networks are a better choice here.

dfabulich 11y ago

> 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. 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? Roy suggests content signatures... but is there a web mechanism to authenticate those? Or is he just wishing there were something better than TLS? (Don't we all?)

URSpider94 11y ago
I think his point is not that TLS is not good at securing information from the host to the viewer, his point is that in doing so, it leaks information about the viewer to the host and potentially to third parties. For public information, TLS effectively asks each viewer to sign the guest register in return for seeing the page. Contrast this with the case where you could download one giant file with hashes for millions of public sites. Once you have a copy of that file, you can now fetch a copy of any of those pages from any source you like, and still validate that your copy is authentic without losing any trace that you accessed that file.

shabble 11y ago

Can anyone explain what he's referring to with the statement > 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).? 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?) Is there some other way of identifying a particular user/browser/session[1] other than the quirks & features enumerator along hte lines of Panopticlick? 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)? 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 must 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. 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. [1] also not including client certificates, because exactly 1 site on the internet actually uses them :P

somethingnew 11y ago
Besides Session IDs and Session Tickets[1] which already exist in the TLS protocol. He could be referring to the Token Binding Protocol Draft[2] which, quoting from it's summary, "allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections". [1] https://en.wikipedia.org/wiki/Transport_Layer_Security#Resumed_TLS_handshake https://en.wikipedia.org/wiki/Transport_Layer_Security#Resum... [2] https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01 https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01

mc_hammer 11y ago

agree also tls is not https3. tls already has been broken 3+ times. this is an open ticket for 1 year in the TLS repo for an exploit. and the author of TLS released a MITM exploit on TLS he wrote (not that other protocols are not vulnerable to MITM) theres no reason to put this in SSH/SSL/HTTP and run all internet communication over it.

asperous 11y ago

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? If you want to remain private, how could TLS prevent this that plaintext would not? HTTP is not tor.

JulianMorrison 11y ago
I think the argument is "HTTP is edge cached (by your ISP, etc) and so a request need not imply a connection received at the remote end. HTTPS is not subject to caching or other benign man-in-the-middle operations so knowledge of who clicked what is centrally available." This feels like a weak objection to me, since the government will just snoop at the ISP level.

sklogic 11y ago

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.

dlitz 11y ago

> 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. 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 both, if people are interested. Plaintext TCP needs to die, and building the infrastructure to move everyone to HTTPS is a step in that direction. 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.

daily_dose 11y ago
>Plaintext TCP needs to die, and building the infrastructure to move everyone to HTTPS is a step in that direction. Why does it need to die?

userbinator 11y ago

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

kijin 11y ago
> if browsers did not support plaintext HTTP at all, and only CA-verified TLS That's a very big "if", and it reeks of FUD. Show me a browser that has any plan to drop support for plaintext HTTP any time in the foreseeable future. Firefox ain't one of them. Last time I checked, their plan was to reserve some of the more dangerous features (such as access to the camera) for secure websites. Hardly a plan to drop support for plaintext HTTP. If you still aren't convinced that the current controversy is just a bunch of FUD, I'll bet $100 that 10 years from now, I'll still be able to post public information (say, the full text of RFC 2616) on a plain HTTP site and have you access it with a mainstream browser.
- iopq 11y ago
  Firefox is moving in that direction. Maybe by 2020 you'll have to click a lot of prompts to see an "insecure" site.
  - kijin 11y ago
    Classic slippery slope argument. When abortion was legalized, some people argued that we'd be murdering children soon. Has that happened? If something is moving in the right direction, but if you're worried that it will go too far, the solution is to get involved and stop it at the right time, not to spread FUD about the hypothetical doom of the world.

donottrack2010 11y ago

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. - an ex-tracking protection working group member.

cactusface 11y ago
Can you say more about that?
revelation 11y ago
It certainly seems that hes more obsessed with some hypothetical potential political economic scenario than the tech aspects of it. Stick to the tech.

nchelluri 11y ago

Is there a way I can view this with line wrapping in Firefox or in Chrome? 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.

tvvocold 11y ago

>It would be better to provide content signatures and encourage mirroring. What does it mean? Mirror Site?

nickysielicki 11y ago

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. 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? I can't think of one. Screw this guy and his politics.

ysleepy 11y ago

This sounds like complete PR reality distortion. How exactly is TLS different to plaintext in anonymity? - There is no client-cert. 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. This whole thread feels like one propaganda attempt to sway the techinal community. And yes, here is where the people to manipulate are.

weinzierl 11y ago

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

JulianMorrison 11y ago

The thing being commented on is here: https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEveryw...

gwu78 11y ago

"authentication of the content, not the connection" 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. 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). Or maybe many users do not know the difference? Van Jacobsen gave a good talk on this at Google: http://www.youtube.com/watch?v=8Z685OF-PS8 http://www.youtube.com/watch?v=8Z685OF-PS8 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. What is the point of securing connections when you have no control over routing? 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. 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. 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". I'm not even sure that TLS can reliably perform "authentication of the connection" as Fielding states. For that, I think SSH is a better protocol.

tveita 11y ago

HTTPS link: https://www.ietf.org/mail-archive/web/ietf/current/msg93416.html https://www.ietf.org/mail-archive/web/ietf/current/msg93416....