On 10 Jun 2015, at 10:24 am, Roy T. Fielding <fielding(_at_)gbiv(_dot_)com>
wrote:
[…]
Furthermore, 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).
Yes. This is a concern that I talked through with Balachander Krishnamurthy
(who said his cookie research would have been much more difficult with
pervasive HTTPS) and others when SPDY came around. I think we need much
better tooling here. There has been a bit of progress, but it's been very
slow...
I don't think you appreciate the impact of authenticated requests on the
overall system.
It isn't just that the sites you intend to visit now have the ability to
uniquely identify
you at no additional infrastructure cost. It is that every https reference
on every page
has the same ability, and is no longer hindered by limitations on Referer or
"privacy"
concerns (again, because people like the IETF claim that encrypted data sent
over TLS is
private even when we have no control over the CAs, the recipient, and the
data sent).
Or perhaps you just weren't explaining what you meant very well. Thanks for
doing so below.
I agree that there are aspects of TLS that could be abused into tracking users
(e.g., session tickets), and that this is a concern. However, the same can be
said for HTTP (ETags, anyone?), URIs, JavaScript, and many other parts of the
Web.
Maintaining truly anonymous, untracked Web access is really, really hard — to
the point that if you're serious about it, each time you want to use a Web
site, you'll use a different physical machine (think side channel attacks; this
is a fun sampler: <http://arxiv.org/pdf/1502.07373v2.pdf>).
As such, equating TLS to "authenticated requests" confuses the matter more than
it helps explain what's happening. If TLS has the potential for adding entropy
to a browser fingerprint, we can and should look at ways to mitigate that. But,
it's not like people who want to track users using things other than cookies
are over the moon about HTTPS Everywhere; they already have a buffet of choices
to do that on the modern Web.
And yes, HTTPS does hide what happens on the wire. However, the techniques used
are still apparent in the endpoints, and we have a growing galaxy of
privacy-aiding browser plugins to find at least some of them, as well as more
hardened approaches like TorBrowser. The ones that can't be found in the
browser by a plugin probably can't be detected on the wire either.
Don't get me wrong - many people (including me) are very concerned about this
problem, and we're talking about it in the TAG right now. I just don't see any
reason to recommend that people NOT deploy HTTPS based upon these specific
concerns — they're dwarfed by other (very real) concerns about cookieless
tracking as well as pervasive monitoring.
[…]
What it does is disable anonymous access to ensure authority.
Please explain?
The https scheme relies on the notion of authority in the URI combined with
direct or
tunneled connection to that authority to establish a trusted exchange of
information
between the user and that authority (assuming that the user trusts that
authority).
For various performance reasons, a great deal of state is held on the user
agent to
ensure that its next connection to the same authority isn't depressingly slow.
Recipients are discouraged from shared caching or mirroring of the content,
since
the authority is vested only in the connection that delivered it, not in the
bits
that were delivered, and the user agent doesn't know why the bits were
secured.
Anonymous access, in contrast, does not presume that the user trusts the
authority.
Very little state is maintained on the user agent, since it doesn't actually
help.
Recipients are encouraged to cache or mirror the content, especially if the
content itself is signed, which means other users can access the content
without
making a request to the authority. Information can be replicated and
accessed at
locations the user does trust, perhaps even offline.
The other advantage that replication has over https, aside from not requiring
a connection to the authority, is that the information cannot be personalized.
If you can go to a public library to see a copy of the tax code, or legal
code,
or some other document of public interest, it makes it much harder for that
code
to be changed without people noticing, or for certain viewers of the code to
see
a different version than others.
Thanks again.
I think the combination of how HTTP is defined and Web browsers' specific
usage patterns of HTTP over TLS does that. We're already seeing some
background discussion of how to offer caching without sacrificing security.
We can't have a reasonable comparison of the effect of HTTPS-everywhere based
on
proposals that are deployed nowhere. Deploy them first, advocate later.
Well, exactly. You seem to be arguing that we should stop advocating
for/improving HTTPS (for all of the reasons that led us to this) while we wait
for a new proposal/protocol to be developed and deployed, because it might be a
better overall solution.
It indeed might be better in many aspects — and I'd love to get such a thing
going. Let's do a Bar BoF in Prague.
In the meantime, we have a deployed Web that needs maintenance and evolution.
It needs to be secured from a variety of attacks — pervasive monitoring being
just one — that HTTPS can help mitigate.
"HTTPS Everywhere" is not an edict from the IESG (or IAB, TAG or anyone else);
it's at most an aspirational goal shared by many. Pretty much all of the actual
activity has been focused on making sure that it's easy / possible to deploy,
and that it is used when a new feature is powerful / privileged enough to
warrant it (e.g., ServiceWorker).
Stopping that on the basis that we hope something better will come along
doesn't make sense.
If you are going to conduct a political campaign, I expect to see reasonable
and
responsible disclosures of the profit motive even if it has no personal
relevance
to the person disclosing. Readers can reach their own conclusions.
OK.
I don't know if I'm "conducting a political campaign" (which seems like a
pejorative phrase already), but regardless: I'm employed by a CDN, Akamai. They
make money by running a lot of servers on the Internet and doing interesting
things with them, including serving TLS.
Your turn, Roy from Adobe and Apache.
[…]
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.
How does HTTPS "end anonymous access"?
Because https-everywhere eliminates anonymous access; not just in the
technical
leaks that result from all that authenticating the authority, but also in the
social
effects it has on the overall ecosystem. It excludes the features of HTTP
that encouraged shared caching (by default) and removes social and technical
barriers associated with persistently identifying each user.
If we are going to make grand recommendations that change the way the Web
works,
we should at least understand the consequences. If we are going to tell
people
that something will improve privacy, then it had better improve privacy to the
same degree that we say it does.
So, the start of this thread was about using HTTPS to serve IETF.org sites. We
seem to be veering off-topic; I don't see a "grand recommendation" of any sort
in <https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere>. What
exactly are you arguing against *here*?
Cheers,
--
Mark Nottingham https://www.mnot.net/