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

http://www.ietf.org/mail-archive/web/ietf/current/msg93416.html

by glenscott1 • 11 years ago

147 83 11 years ago

Aloha• 11 years 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."

asperous2• 11 years 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.

kijin5• 11 years 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.

cm21873• 11 years 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.

espadrine3• 11 years 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• 11 years 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.

Buge• 11 years ago

I think a more realistic example of a MITM by China is their recent injecting botnet code to DDOS github.

Also ISPs and wifi hotspots inject ads fairly often.

frik3• 11 years ago

HTTP/2 based on the work of SPDY is upcoming protocol. 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/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).

quonn4• 11 years 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.

frankchn6• 11 years ago

I don't see how the stream priority feature of HTTP/2 affects "net neutrality" at all, since it only affects stream prioritization behavior within one TCP connection.

If ISPs decided to slow down or speed up certain traffic, they would just modify the QoS for the entire TCP connection based on source and destination IPs -- no need for Layer 7 parsing. Also, since HTTP/2 requires TLS, ISPs can't read the stream priority (or anything else within the stream) even if they wanted to.

Also, HTTPS costs should be minimal for startups (in fact, they should be more significant if you are the size of Amazon). For instance, if you use Amazon Cloudfront, the price difference between serving one million requests over HTTPS vs one million requests over regular HTTP is at most 60 cents in any AWS region.

jsingleton• 11 years 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.

josteink4• 11 years 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• 11 years 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.

pdkl953• 11 years 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.

thwd2• 11 years 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• 11 years ago

No, because you would want to keep the fact that you read something private.

thwd2• 11 years 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• 11 years ago

Yes, and Roy's claim is that TLS doesn't provide that privacy, so is still basically useless for public content.

myhf• 11 years ago

I found the title a bit misleading.

Don't worry, someone will be along shortly to change the title to something even more misleading.

empressplay• 11 years 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?

quonn4• 11 years ago

But credential-based encryption

TLS does usually not use client-certificates, so it is not credential-based for the user.

Animats2• 11 years 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/

realityking2• 11 years 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.

meesterdude• 11 years 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

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• 11 years ago

....And the guy that came up with REST https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

nbevans• 11 years ago

REST was more just a clarification and formal study to describe the intended way of using HTTP.

weland• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years 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#Resum...

[2] https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01

mc_hammer• 11 years 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.

asperous2• 11 years 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.

JulianMorrison2• 11 years 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• 11 years 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• 11 years 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.

userbinator• 11 years 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.

kijin5• 11 years 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• 11 years ago

Firefox is moving in that direction. Maybe by 2020 you'll have to click a lot of prompts to see an "insecure" site.

weinzierl2• 11 years ago

A very big "if" indeed, but not a completely unrealistic assumption in my opinion. It will not happen at once but gradually.

Neither Firefox nor Chrome intend to support plain HTTP/2 without encryption. Google already favors pages with TLS, my bet is they will also favor HTTP/2 sometime soon. Like you said: Browser will "reserve some of the more dangerous features (such as access to the camera) for secure websites.". They might even show a red bar for HTTP instead of a green one for HTTPS.

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

I'm sure you are right. We will be able to use HTTP in 10 years much in the sense that we are still able to use RSS today.

I don't know whether to laugh or cry about this but it is what I see coming.

espadrine3• 11 years ago

If everyone has to obtain a certificate from a CA, that is another way they can be tracked

They have to be tracked just as much even without that. They have to give their credentials to the hosting provider and to the DNS provider. Even if they didn't and plugged their server directly to the backbone, their IP address and traceroute would leak information about their location.

That said, your point is valid in a parallel universe where anyone could run an anonymous server without registering for DNS or contacting an ISP or a hosting provider or anything at all.

But in that universe, clients would have no way to know if that server contains valid information or data that was substituted on-the-fly. Imagine WWII-style Radio Londres, but one day the broadcast is substituted by one that looks like it comes from Charles de Gaulle, and gives the wrong instructions.

josteink4• 11 years ago

They have to give their credentials to the hosting provider and to the DNS provider.

Back in the real world you don't need a hosting provider nor DNS to serve a website.

The following is a real address: http://123.234.34.56 (although it doesn't currently point to any real webserver)

You can probably trace the ISP it belongs to, but if that ISP is in another country than the regime you want to hide from, they need to launch a cross-country, international police-investigation, and possibly defend their claims through a trial, to get authorities in that country to force that ISP to divulge the identify of the customer at the other end of that IP.

Being able to serve websites anonymously, through plain HTTP and no hosting-partner DNS is a very real option. With today's high-speed internet connections it's a more real option than ever before.

Pretending this option doesn't exist doesn't lend your arguments any favour.

Sanddancer• 11 years ago

This is why the people advocating this are also advocating alternative CAs like letsencrypt, where the process is automated, only requires proof you control the domain (no real world info needed), and is free. Thus, the CA model is used, but only at a bare minimum.

Then again, I'd like to see browsers support an encryption model based on DNS records, using one of the many unused crypto record types, like KEY, for delivering the private key's fingerprint. For basic use, there would be no need for an outside party to verify its validity, just that the connection isn't being tampered with. This way, there's no tracking by a central authority unless one wants or needs further verification.

donottrack2010• 11 years 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• 11 years ago

Can you say more about that?

revelation• 11 years 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• 11 years 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• 11 years ago

It would be better to provide content signatures and encourage mirroring.

What does it mean? Mirror Site?

nickysielicki• 11 years 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• 11 years 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.

weinzierl2• 11 years 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?

JulianMorrison2• 11 years ago

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

gwu78• 11 years 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

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• 11 years ago

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

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

Related Stories