Subject: Re: [TLS] About encrypting SNI

From: David Holmes <[email-masked]>
Date: Mon, 12 May 2014 18:01:53 +0000

➢ so a server under load can, in the initial opportunistic encryption phase, push back to a client and ask for a puzzle to be solved?

I was describing this idea to a colleague, and the first thing he said was "could you have the client mine some bitcoin for you? As a show of good faith?"

Two problems sprung to mind with a bitcoin mining solution - unethical servers would be gaming clients to do computation for them. Second, this would also a cause a problem for mobile handsets where CPU = battery life.

But I think the puzzle idea has merit, especially if it's not a required challenge = that is, only issued when server is under load.

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, April 17, 2014 2:20 PM
To: Brian Sniffen
Cc: [email-masked]; Andy Lutomirski
Subject: Re: [TLS] About encrypting SNI

On Thu, Apr 17, 2014 at 12:59 PM, Brian Sniffen <[email-masked]> wrote:
I hesitate to ask, but: is it plausible to re-open the proof-of-work
conversation, so a server under load can, in the initial opportunistic
encryption phase, push back to a client and ask for a puzzle to be
solved?

I don't think it's implausible (though I'm not completely sold yet).

One concern I would have is whether we understand the problem well
enough to actually specify this. I'm not an expert in this area, but weren't
there a bunch of concerns about designing puzzles that were effective
without being prohibitively expensive for mobile devices? How would
we design a new kind of puzzle (As opposed to messing with the puzzle
work factor) and then roll it out?

-Ekr

> I wonder if there's a way to test a large number of private keys at
> once.  If so, then the cost drops to O(log N).  Off the top of my
> head, I can't think of a cryptosystem with that property.
I certainly don't expect to find any *pair* of cryptosystems with that
property, and continue to maintain that in 3 years we won't find two big
organizations willing to use exactly the same crypto.

-Brian

--
Brian Sniffen
Information Security
Akamai Technologies
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Brian Sniffen <[email-masked]>
Date: Mon, 12 May 2014 14:22:34 -0400

> I was describing this idea to a colleague, and the first thing he said was "could you have the client mine some bitcoin for you? As a show of good faith?"

Bitcoin's also hard to check: if the client says it found no bitcoin in
a particular region, how do you know?  And a whole bitcoin's too much to
ask.

An identity scheme tied to giving away bitcoin---much like a credit
rating ties to many transactions profitable for the counterparty---has a
lot in its favor.  It would make a great (research) extension on top of
TLS 1.3, and I hope that any puzzle mechanism will be flexible enough to
support that.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Marsh Ray <[email-masked]>
Date: Mon, 12 May 2014 18:26:08 +0000

From: TLS [mailto:[email-masked]] On Behalf Of David Holmes
> I was describing this idea to a colleague, and the first thing he
> said was "could you have the client mine some bitcoin for you? As a show of good faith?"

Even better, ask the client to perform some computation which will usefully offload work from the server somehow.

E.g., a ridiculous naïve strawman idea would be for the client to perform the server-side modular exponentiation needed for another client's DHE connection. Obviously this would not be secure, but perhaps some 21st century cryptosystem could do it securely. Nevertheless, there would still be issues about reliability and latency.

- Marsh
------------------------
My own personal opinions, boilerplate disclaimers apply.

---

From: Marsh Ray <[email-masked]>
Date: Mon, 12 May 2014 18:31:03 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Brian Sniffen
>
> Bitcoin's also hard to check: if the client says it found no bitcoin in a
> particular region, how do you know?  And a whole bitcoin's too
> much to ask.
> 
> rating ties to many transactions profitable for the counterparty---
> has a lot in its favor.  It would make a great (research) extension
> on top of TLS 1.3, and I hope that any puzzle mechanism will be
> flexible enough to support that.

Years back, Microsoft was looking into a proof-of-work scheme for antispam sender-pays email.
http://research.microsoft.com/en-us/projects/pennyblack/

One challenge is that botnets (that are conduits for most of the spam) also have plenty of spare CPU capacity.

- Marsh
------------------------
Boilerplate disclaimers apply.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 May 2014 19:38:53 -0500

On Wed, Apr 16, 2014 at 8:53 AM, Tom Ritter <[email-masked]> wrote:
> ....But... There once was a thing called DNSSEC Stapled Certs
> (https://www.imperialviolet.org/2011/06/16/dnssecchrome.html) where a
> SSL certificate had a chain of DNSSEC signatures in it, validating it
> via DANE (or at that time, a DANE-like mechanism.)  It violates a

I've been thinking of this for a while...

> layering principal that people hold dearly, shoving DNS information in
> other corners it shouldn't be.  But I think it would be necessary for
> the wildcard approach to be reliable for clients like browsers.

Layers aren't pure though.  Some things show through the various
layers' interfaces, sometimes several layers through.

For example, many apps have to deal with all of DNS and TCP/IP, with
IP addresses and TCP port numbers used together in socket APIs.  It
might have been a lot better if the sockets APIs had deal with
hostnames from the start, but here we are.  Abstractions are leaky.

Now in this case I think saving a client a number of DNSSEC lookups
could be convenient.  We should -of course- make sure that this works
out securely -- we don't want to end up with a cache poisoning attack
here.

Nico
--

---

From: Andy Lutomirski <[email-masked]>
Date: Mon, 12 May 2014 17:45:30 -0700

> out securely -- we don't want to end up with a cache poisoning attack

I think that we could get a lot of mileage out of the idea of having
some kind of DNSSEC-backed service binding.  There are all kinds of
interesting fields we could stick in there if we had such a thing and,
if we do it right, clients that can't read the service binding would
just fall back to normal (plaintext SNI, PKIX) TLS.

I'm planning on talking about this at the meeting this week.

--Andy

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 12 May 2014 18:53:44 -0700

David Holmes wrote:
> I was describing this idea to a colleague, and the first thing he said was
> "could you have the client mine some bitcoin for you? As a show of good faith?"

Sure!  After we get rid of TLS compression, RSA key transport, non-AEAD ciphers,
and all the other crud, let's plug in Bitcoin!  ;-)

Mike

---

From: Watson Ladd <[email-masked]>
Date: Mon, 12 May 2014 19:40:46 -0700

On Mon, May 12, 2014 at 6:53 PM, Michael D'Errico <[email-masked]> wrote:
> David Holmes wrote:
>>
>> ➢ so a server under load can, in the initial opportunistic encryption
>> phase, push back to a client and ask for a puzzle to be solved?
>>

We're not getting rid of these things because they are needless
complexity (although they are) but because they are horrifically
broken.

Plugging in a puzzle consisting of doing some SHA-256 evaluations
doesn't open up any holes. It seems to solve a real security issue,
but might not be that effective: botnets have CPU to burn. I'm mildly
for it. And if someone makes it into an altcoin somehow we might
accidentally fix web micropayments.

I think bigger issues are ensuring the security properties in TLS 1.3
are what we want them to be (sine qua non), making it clear what you
have to implement to implement TLS, possibly letting alternatives to
X509 be of equal standing, tightening up the language to make the
first goal and second easier. Puzzles are a nice way to ensure DOS is
hard.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Erik Nygren <[email-masked]>
Date: Mon, 12 May 2014 23:40:23 -0400

> I'm planning on talking about this at the meeting this week.

I agree that if we go down the road of wanting to encrypt the handshake
that a DNS-based DNSSEC-backed service binding with plaintext SNI fallback
is probably the best path.  It's also on my list to discuss this week.
Especially given that there's little value in encrypting SNI with
encrypting/securing DNS, associating the two has some nice
mutually-motivating properties.

          Erik

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 May 2014 09:07:08 -0400

>  Especially given that there's little value in encrypting SNI with[out] encrypting/securing DNS, associating the two has some nice mutually-motivating properties.
The “[out]” is the important missing part, I think.
But this now becomes a variant of the kiddie game: you don’t show me yours, I won’t show you mine. ☺
            /r$
--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]<mailto:[email-masked]>; Twitter: RichSalz

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 13 May 2014 13:53:56 -0400

> The “[out]” is the important missing part, I think.

yes, indeed :)  But that's what the dns-privacy discussion is about.

  https://www.ietf.org/mailman/listinfo/dns-privacy

If we don't offer a standard mechanism for protecting the
confidentiality of SNI (at least against passive monitors) in upcoming
versions of TLS, then the dns-privacy discussion is going to have
serious trouble sustaining its work by an analgous "little value
unless..." argument.  We shouldn't sabotage that work.

The TLS WG needs to fix the SNI leak, and DNS confidentiality needs to
be addressed by the DNS folks if we want to protect this information
against passive eavesdropping.

	--dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 May 2014 13:56:15 -0400

> The TLS WG needs to fix the SNI leak, and DNS confidentiality needs to be addressed by the DNS folks if we want to protect this information against passive eavesdropping.

I've already written why I think encrypting SNI is not worth the trade-offs.  Yoav, I think, added the point that the traffic analysis will give it away, anyway.

It hurts more than it helps.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Michael StJohns <[email-masked]>
Date: Tue, 13 May 2014 15:57:52 -0400

On 5/13/2014 1:53 PM, Daniel Kahn Gillmor wrote:
> y If we don't offer a standard mechanism for protecting the 
> unless..." argument. We shouldn't sabotage that work. The TLS WG needs 
> to fix the SNI leak, and DNS confidentiality needs to be addressed by 
> the DNS folks if we want to protect this information against passive 
> eavesdropping. --dkg

One of the things missing from this discussion is whether or not 
encrypting the SNI is sufficiently resistant to traffic analysis 
techniques to make it worthwhile:  E.g.  A trivial attack is where there 
are a 100 web sites at a particular IP address, but only one of them has 
a name that is 28 characters in length and that's the one eavesdroppers 
care about.  A non trivial attack is where the web sites can be 
characterized via their patterns of traffic (a web page with 28 items, 
of which 16 are pictures with known fixed lengths).

Random padding can mitigate some of this (but will require some changes 
to TLS) and random reordering of HTTP requests can also help a bit 
(mostly a client side change), but transaction based protocols like HTTP 
(e.g. most of the time I'm pretty sure that the client is sending some 
sort of GET even if I don't know exactly what its asking for) tend to 
reveal the underlying patterns, even if the actual data is protected.

Mike

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 May 2014 15:20:16 -0500

On Tue, May 13, 2014 at 2:57 PM, Michael StJohns <[email-masked]> wrote:
> One of the things missing from this discussion is whether or not encrypting
> the SNI is sufficiently resistant to traffic analysis techniques to make it
> worthwhile:  E.g.  A trivial attack is where there are a 100 web sites at a
> particular IP address, but only one of them has a name that is 28 characters
> in length and that's the one eavesdroppers care about.  A non trivial attack
> is where the web sites can be characterized via their patterns of traffic (a
> web page with 28 items, of which 16 are pictures with known fixed lengths).

Well, and for the many cases where there are many fewer than 100 sites
at one IP address...  the IP address will reveal plenty.

> Random padding can mitigate some of this (but will require some changes to
> TLS) and random reordering of HTTP requests can also help a bit (mostly a
> client side change), but transaction based protocols like HTTP (e.g. most of
> the time I'm pretty sure that the client is sending some sort of GET even if
> I don't know exactly what its asking for) tend to reveal the underlying
> patterns, even if the actual data is protected.

HTTP has infinitely extensible headers just for this purpose ;)

We can address some of the traffic analysis problems.  I think if we
don't now, we will eventually.  It's just a question of when.  Sooner
would be better.  It might not be feasible at this time; we should
find out if it is.

So far it looks like we'd need:

a) confidentiality protection in DNS,

b) leverage DNSSEC/DANE to get zero-round-trip SNI encryption in TLS,

c) apply care to avoid leaking information via payload sizes.

What else?

Sounds like a lot to get right for 1.3!  Even if we defer (a) but make
some assumptions about it so we can ship 1.3 and enable (a) later, we
might get it wrong.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 May 2014 22:15:36 +0100

Hiya,

Just some thoughts on this... no hats and all that.

> HTTP has infinitely extensible headers just for this purpose ;)

HTTP/2.0 is also adding padding, so it could be that a good
solution here for web sites depends on some or all of TLS1.3
and HTTP/2.0 and DNS-priv. That is quite a lot of moving parts,
but if we don't fully examine the SNI part of that story now,
then I can't see it happening again for a long time to be
honest.

I also don't like the "DNS is clear, so why not SNI" argument.
Because that goes on to "if SNI is clear, then why not ALPN?"
And if ALPN, then why not the server cert? Etc. etc. And
then in the end we lose out on lots of chances to counter
traffic analysis. (Not that we know so well how to do that,
but nonetheless...)

If the argument ends up being that nobody wants to implement
SNI encryption, then that's important, but I don't believe we
have a proposal so far that'd allow folks to decide that. (Or
maybe I missed it, I just saw some sketches in mails.) That
does however put the onus on those who would like to see this
done to write down how. If nobody does that, then I'd say
Rich's argument will win by default since he's pointing out
a real difficulty. I think that'd be a pity but doing better
depends on those who want to do better figuring out and
writing down how.

One other thought, maybe more optimistic: could it be that
there might be ways to protect things like SNI used for
routing the 2nd and later times you visit a web site, even
if TLS had to put the DNS name in clear (or close-to) first
time around? If one gets that property via some mechanism
or other, and if the hosts at which there's any point in
trying to hide SNI (those with lots of VirtualHost equivalents)
get lots of non-first time visits maybe even from the same
clients, and if DNS-priv happened, then maybe that'd be a
sufficiently useful answer. I'm not sure, but that's the
kind of analysis that needs to be done by someone interested
in countering traffic analysis. I really hope someone's up
for doing that kind of work.

S.

---

From: [email-masked] (Martin Rex)
Date: Wed, 14 May 2014 04:20:07 +0200 (CEST)

Stephen Farrell wrote:
> time around?

The latter looks like a contradiction to SNI being used for routing
to me.  When SNI is used for routing, then it MUST be present
on the initial ClientHello on every new connection, or routing
(to other than the default credential) will be impossible.
It doesn't really matter whether that routing is physical
(to a different backend server) or just logical (to a different
server credential on the same host.

The session_id that is normally used for the abbreviated handshake
is no suitable substitute here.  These sessions may expire quickly
and randomly (like depending on server load and cache contention),
within a few minutes, and the session cache is not necessarily
shared among TLS clients or among TLS servers involved in the
communication.

E.g. a while ago I observed an unfavorable behaviour of a browser on
a platform after an OS minor version upgrade with respect to browser
plugins.  The OS upgrade seems to have seperated the browser's TLS session
cache from the TLS session cache used by the plugins, and the plugins
were not prepared to do their own promptin "server cert warning--do you want
to continue anyway",  but instead just silently failed (resulting in
a blank/white area where the plugin should have rendered the contents).

Hiding the server hostname by encrypting SNI looks extremely silly for
anything that operates like a web browser.  Those beasts spill
HTTP-Referers all over the place, keep bookmarks, keep histories,
keep cookies and do lots of other stuff to spread hostnames from URLs
all over the place.

The hostname horse has left the barn 25 years ago.  Closing the barn
door today is going to be futile.  IF you have anything to hide,
then you MUST ensure, that it is not vitally dependend on the
hostname of the server remaining secret.

I do not believe that it would be a good idea to create the
provably false impression that TLS is a panacea and hiding of SNI
would provide any security or any privacy benefit vaguely similar
to characteristics that TOR tries to provide -- because it doesn't,
and can't.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 14 May 2014 09:44:57 +0200

> against passive eavesdropping.

Fixing the SNI leak is easy, just don't use SNI. The main issue is in
the TLS handshake which sends the certificates in plain. A fix for
passive eavesdroppers would require a new IPSec-style handshake. It
comes at a cost though. Load balancers and redirectors will need to
terminate TLS in order to redirect the traffic to the proper host.
Terminating TLS there would mean (a) the encrypted session isn't
terminated on the intended server but somewhere else, (b) user
authentication with TLS will be pretty much unusable for hosts behind
that type of systems, (c) software redirection of sessions (e.g.,
because a different process handles a different host or protocol - see
ALPN) will also become very difficult.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 14 May 2014 11:13:33 -0400

>  Load balancers and redirectors will need to terminate TLS in order to redirect the traffic to the proper host.

Which we know have been interdicted by various national security adversaries.

	/r$

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 May 2014 16:25:48 +0100

On 14/05/14 16:13, Salz, Rich wrote:
>> Load balancers and redirectors will need to terminate TLS in order
>> to redirect the traffic to the proper host.
> 

True. However, there's also tempora as well, so there may be
benefits even if not all adversaries are countered. I'm not
saying we have a good enough way to do that yet, but increasing
the costs to the adversary and forcing what was covert to be
more overt is part of the game too. Something that only worked
against passive things like tempora could in principle be
worthwhile if it forced the adversary to have to get their
stuff into the CDN/data-center. If we could do better that'd
be great. If we can only counter a tempora-like attack and
the costs for doing so are quite high then there would be a
case to be made for living with tempora perhaps, but I'd
rather not myself.

S.

> 
> /r$
> 
> -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM:
> [email-masked]; Twitter: RichSalz 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
>

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 14 May 2014 09:13:00 -0700

> case to be made for living with tempora perhaps, but I'd

My argument is that the cost of countering attacks that don't involve
compromising an endpoint should be quite low if done sensibly, and I
think that this type of protection could be quite valuable.

I agree that having the client cache some kind of public key will be a
mess and might not offer any protection, but I don't think that's
necessary.

If done right, exactly the same protocol change could also counter
active attacks based on forging certificates.

--Andy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 May 2014 09:52:03 -0700

On 13 May 2014 19:20, Martin Rex <[email-masked]> wrote:
> When SNI is used for routing, then it MUST be present

I think that this is a little too strong as a statement.

If routing requires a round trip between the router and the client,
that still enables routing, albeit at a higher cost.

---

From: Tom Ritter <[email-masked]>
Date: Wed, 14 May 2014 23:31:04 -0400

I have a lot of points on Encrypted SNI, so I'm looking forward to
tomorrow, but I wanted to start putting some into email.  I'd like to
start with the notion that HTTPS fingerprinting makes it useless.

One of the best surveys of the literatre is Roger Dingledine's blog
post at https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-attacks.
 (It does not include the most recent paper "I know why you went to
the Clinic" by Miller et al.) There are lots of scenarios for HTTPS
fingerprinting, and it's important to note that he concerns himself
with Tor's use case: the adversary is trying to do fingerprinting when
the client is potentially accessing the entire Internet.  Some of the
other scenarios considered in literature are a) determining which
webPAGE is visited in a specific webSITE and b) determining which
webPAGE you are visiting among many webPAGES on many (but finite)
webSITES.

An arguement that Encrypted SNI or Server Certificate (taken together,
Encrypted Handshake) is not useful is absolutely correct if there is
only one webSITE hosted on an IP address. The IP gives it away,
regardless of DNS Privacy, Encrypted Handshake, etc (so long as the
attacker can index the site, and we assume they can.)  So I'd like to
instead talk about the case when there is multiple webSITEs hosted at
an IP, and an attacker wishes to determine which webSITE in a set of
webSITEs the user is visiting - because that is the metadata that
Encrypted Handshake protects against.

Unfortunetly, there are no studies that attempt this, of course.  But
we can still talk about some stuff.

First off, because we assume that the attacker knows all the websites
hosted on an IP, it's a closed world study, an advantage to the
attacker, they're much easier.  However, even a 'closed world' is not
truly closed. For a true closed world, an attacker must be able to
train their classification engine on all the pages in the site.
Dynamic content that changes via authentication, and just general
additional data added to the page since classification (think
comments, posts, etc) make this impossible.  All of the studies do not
attempt to deal with this problem. The attacker's advantage is not
taken away, but it is ever so slightly reduced. But there are other
things that make the closed world less closed: client beahvior.
Caching, AdBlocking, Plugin Click-To-Play, Third-PArty Cookies
Enabled/Disabled, Ads, Javascript Disabled and so on.  Advantaged
reduced a little bit again, although Miller attempts to address the
caching one.

Next off: False Positives Matter. A Lot. I'm basically just going to
point you to the same section in Roger's blog post. Summed up and
applied to us, it states that if your goal is to determine if a user
is visiting Site A on IP X, instead of Site B - the false positive
rate keeps adding up on each page load. You're not going to get a
binary answer, you're more likely to get an answer that looks like
"Well, we had 8 hits for SiteA, 10 for SiteB, 3 for SiteC".  Advantage
to the Defender.

Finally, there are defenses a website concerned about this can employ.
There are a number of different padding mechanisms for defenders to
deploy, collected from many papers and outlined in Section 7 of the
Miller paper. All of these defenses can be deployed unilaterally by
the server (no client changes needed), inside of the TLS protocol,
with the simple ability to insert random padding ignored by the
client. I've seen this topic come up before, and I hope people are not
opposed to this optional feature being present.

So at this point I'd like to talk about the most recent paper, "I know
why you went to the Clinic" by Miller et al.  At a high level, they
attempt to identify which webPAGE you are viewing inside a known
webSITE. Different from our goal, but we're not speaking different
languages. I'm going to liberally take excepts from it that in the
real world will reduce their impressive claim of 89% accuracy.
 - They don't operate on whole sites, they took a subset of the site,
500 'labels' (unique pages), followed redirections, and ran it off
that
 - They didn't operate on single loads, they visited 75 pages in a
session and each page they collected 16 times.
 - They discover and remark that "caching significantly decreases the
number of unique packet sizes observed for samples of a given label"
and that "A reduction in the number of unique packet sizes reduces the
number of non-zero features and creates difficulty in distinguishing
samples." - said another way: caching makes it harder
 - They also find that visiting webPAGEs on a webSITE (as opposed to
different webSITEs) causes decreased traffic volume, which also makes
it harder.  This is our scenario.
 - Their accuracy went from 72% to 89% by using a Hidden Markov Model.
While this is not bad, strictly speaking, it assumes that the user
follows the link structure of the site strictly. No bookmarks.  They
also don't factor in the possibility of 'Back' buttons (Although I
suspect most websites that link A->B also link B->A so it's probably
accounted for most of the time.)
 - They used 500 labels for their subset, the 4 sites whose
redirections ballooned that up (to ~1000 labels) had the worst
accuracy. Logical, but nice to see confirmation that the larger the
site, the worse accuracy.
 - They do not factor in browser differences, OS differences, or user
configuration of the browser
 - They present a defense that takes their own accuracy from 89% to
27%, with only 9% traffic overhead

 Perhaps most unrealistic: They assume users browsing with a single
tab and easily delineated page requests.  No mashing the refresh
button, no multiple tabs, no opening in a background tab, no
background tab that's doing AJAX polling, etc.

There are some very sexy presentations on HTTPS Traffic
Fingerprinting, probably the sexiest of which is watching you load
Google Map Tiles over HTTPS, and detecting where you're zooming in on.
 But that presentation, and the papers, all assume a very unrealistic
operating environment.  Which is not to denigrate them, I think
they're generally excellent work and foundations for further research.
 But you can't point to them and say the situation is hopeless.  At
this point, I'm actually pretty optimistic that attacks in the real
world will be quite difficult.

Trying to defeat Encrypted Handshake using HTTPS Traffic Analysis has
a lot of things going against it:
1) The adversary's determination of Site A vs Site B is made
significantly more difficult by cumulative false positives
2) The greater number of sites hosted at an address, the more
difficult his job becomes.
3) The attacker has to do a considerable amount of work to train their
classifier for the specific user preference that matches the user
they're attacking
4) And factor in the current cache state of the user
5) A site can actively try and defend against it, and we have
indications this would be very effective

To put a point on active defenses: I think a lot of people assume that
would never happen, but Twitter is currently padding profile images to
resist traffic analysis. In the future, I expect more sites will start
to care, and more people will ask them to.

One of the things I think would be awesome was if a research project
was done on this exact problem.  I think that a CDN could provide
accurate numbers for the characteristics and numbers of sites hosted
on an IP address, which would be much better than arbitrarily chosen
numbers. However negative results, that is results that say "We
couldn't get good accuracy" often are not published, so we'd want to
see those too ;)

-tom

---

From: Brian Sniffen <[email-masked]>
Date: Thu, 15 May 2014 09:05:45 -0600

> http://research.microsoft.com/en-us/projects/pennyblack/

Thanks!  I hadn't remembered the name, but that work was surely on my
mind as I wrote.

> One challenge is that botnets (that are conduits for most of the spam) also have plenty of spare CPU capacity.

Yes, but each bad node's CPU capacity only outstrips many good node's
capacities by a little bit---compared to network bandwidth, where very
often botnets outstrip good nodes' capacity by orders of magnitude.  Of
course the bad nodes will beat out cell phone CPUs; a client puzzle
scheme has to be about, in some part, "acceptable losses."  If we can
drop new mobile nodes and the botnet, but keep service up for (say)
established connections and "real" computers, that may be okay.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Fabrice <[email-masked]>
Date: Tue, 20 May 2014 09:56:45 -0700

> On May 15, 2014, at 8:05, Brian Sniffen <[email-masked]> wrote:
> 

I don't have hard data at hand, but my guess is that these days TLS connections from mobile devices far outnumber TLS connections from "real" computers. So that may not be okay.

---

From: Brian Sniffen <[email-masked]>
Date: Wed, 21 May 2014 14:18:53 -0400

>>> One challenge is that botnets (that are conduits for most of the
>>> spam) also have plenty of spare CPU capacity.
>> 
>> capacities by a little bit---compared to network bandwidth, where
>> very often botnets outstrip good nodes' capacity by orders of
>> magnitude.  Of course the bad nodes will beat out cell phone CPUs; a
>> client puzzle scheme has to be about, in some part, "acceptable
>> losses."  If we can drop new mobile nodes and the botnet, but keep
>> service up for (say) established connections and "real" computers,
>> that may be okay.
>
> I don't have hard data at hand, but my guess is that these days TLS
> connections from mobile devices far outnumber TLS connections from
> "real" computers. So that may not be okay.

That doesn't seem to be the case.  See
<http://www.akamai.com/html/io/io_dataset_v2.html#stat=browser&top=5&type=bar&start=20140305&end=20140405>.
That's not for TLS alone, but Chrome + IE + FF is far greater than Mobile
Safari + Android Webkit + all Others.  Given that, it would be
surprising if Mobile TLS far outnumbered Desktop TLS.

And even if so, the number of connections that can get through if you
sacrifice some class of connections is still much greater than the
number of connections that get through if you let the attacker suppress
them all.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 May 2014 22:20:07 +0300

> surprising if Mobile TLS far outnumbered Desktop TLS.

That page you linked allows you to group by device OS, which shows 58.8% Windows and 8.4% for Mac OS X. There may be some 1% of desktop linux in those “Unknown” or “Other” categories.  So about 2/3 desktop computers.

But this data is for percentage of requests, not connections. I think mobile sites tend to be simpler and contain less resources than full sites,  Also mobile phones tend to run a lot of little apps that keep querying servers in the background, much more than desktop computers do, so it’s possible that in number of handshakes the score is more even. 

There’s also some skew in that an Intel processor running Android is counted as “mobile” but a tablet running Windows RT is counted as “desktop”, but those are still too rare to alter the results.

Yoav