On Fri, Nov 14, 2014 at 8:00 PM, Patrick McManus mcma...@ducksong.com wrote:
On Thu, Nov 13, 2014 at 11:16 PM, Henri Sivonen hsivo...@hsivonen.fi
wrote:
The part that's hard to accept is: Why is the countermeasure
considered effective for attacks like these, when the level of how
active the MITM needs to be to foil the countermeasure (by
inhibiting the upgrade by messing with the initial HTTP/1.1 headers)
is less than the level of active these MITMs already are when they
inject new HTTP/1.1 headers or inject JS into HTML?
There are a few pieces here -
1] I totally expect what you describe about signalling stripping to happen
to some subset of the traffic, but an active cleartext carrier based MITM is
not the only opponent. Many of these systems are tee'd read only dragnets.
Especially the less sophisticated scenarios.
I agree that http+OE is effective in the case of mere read-only fiber
splitters when no hop on the way inhibits the upgrade. (The flipside
is, of course, that if you have an ISP inhibiting the upgrade as a
small time attack to inject ads, a fiber split at another hop gets
to see the un-upgraded traffic.)
1a] not all of the signalling happens in band especially wrt mobility.
The notion that devices move between networks that change the contents
of IP packets and networks that deliver IP packets without changing
their contents and upgrade signals seen in the latter kind of network
getting remembered for the first kind makes sense, yes. But this isn't
really about whether there exist some cases where OE works but about
whether OE distracts from https.
2] When the basic ciphertext technology is proven, I expect to see other
ways to signal its use.
I casually mentioned a tofu pin yesterday and you were rightly concerned
about pin fragility - but in this case the pin needn't be hard fail (and pin
was a poor word choice) - its an indicator to try OE. That can be downgraded
if you start actively resetting 443, sure - but that's a much bigger step to
take that may result in generally giving users of your network a bad
experience.
And if you go down this road you find all manner of other interesting ways
to bootstrap OE - especially if what you are bootstrapping is an
opportunistic effort that looks a lot like https on the wire: gossip
distribution of known origins, optimistic attempts on your top-N frecency
sites, DNS (sec?).. even h2 https sessions can be used to carry http schemed
traffic (the h2 protocol finally explicitly carries scheme as part of the
transaction instead of making all transactions on the same connection carry
the same scheme) which might be a very good thing for folks with mixed
content problems. Most of this can be explored asynchronously at the cost of
some plaintext usage in the interim. Its opportunistic afterall.
There is certainly some cat and mouse here - as Martin says, its really just
a small piece. I don't think of it as more than replacing some plaintext
with some encryption - that's not perfection, but I really do think its
significant.
I think the idea that there might be other signals is a bad sign: It's
a sign that incrementally patching up OE signaling will end up taking
more and more effort while still falling short of https that is
already available for adoption and available even in legacy browsers.
Also, it's a bad sign in the sense that some of the things you mention
as possibilities are problems in themselves: While DNSSEC-based
signaling to use encryption in a legacy protocol whose baseline is
unencrypted makes some sense for protocols where the connection
latency is not an important part of the user experience, such as
server-to-server SMTP, it seems pretty clear that with all the focus
on initial connection latency, browsers won't start making additional
DNS queries--especially ones that might fail thanks to
middleboxes--before connecting. (Though, I suppose when the encryption
is *opportunistic* anyway, you could query DNSSEC lazily and let the
first few HTTP requests go in the clear.) As for prescanning your
top-N frecency, that's a privacy leak it itself, since an eavesdropper
could tell what the top-N frecency is by looking at the DNS traffic
the browser generates (DNSSEC infamously not providing
confidentiality...). (Also, at least if you don't have a huge legacy
of third-party includes that would become mixed content, https+HSTS is
way easier to deploy than DNSSEC in terms of setting it up, in terms
of keeping it running without interruption and in terms of not having
middleboxes mess with it.)
But I think the fundamental problem is still opportunity cost and
sapping the current momentum of https. The idea this is effective
against read-only dragnet some of the time, therefore let's do it to
improve things even some of the time might make sense if it was an
action to be taken just by the browser without the participation of
server admins and had no effect on how server admins perceive https in
