5 ms·

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

• 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.
          • cm2187 11y ago
• 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.