Subject: Re: Re[6]: HTTP2 Expression of Interest

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 18 Jul 2012 15:24:08 +0200

> Lets not get personal.

> It does not go without notice from me that the battle lines are drawn
> around which type of developer you are.  Browser developers and social
> content providers are all in the protect-the-users camp (encrypt
> everything).  Proxy vendors, which have an uncertain role in an encrypted
> future, are unilaterally against it.  This is a power struggle of products.
> Are the endpoints in charge?  Or is the 3rd party middleman in charge?

Disclaimer:
1. I am not a developer. I am an operator
2. I am tasked to secure a minimum the Internet accesses from my employer,
parters and subsidiaries networks
3. I don't care a bit about any of the actors that you mention. They all
collectively failed to provide a working and secure HTTP solution to us in
the past decade. I don't like how I have to manage a pile of workarounds
because browsers do not play nice with intermediaries and the protocol is
full of loopholes that let them do it so. I don't like how web site
developers think playing nice with their users tools (and I am part of
those tools) is being held in hostage and how they strive to bypass it. I
don't like the bugs in the proxy systems we bought.
4. there are enough users behind my systems one of the major airlines of
the continent blacklisted our public ips for a while because its
equipments decided we were performing a DOS against its ticketing system
(and buying air-plane tickets is not our core business, though like
everywhere our users do need to travel occasionally). Some traditional
out-of-band negotiation fixed this.
5. I am paid to help those users (WRT Internet accesses). I don't live by
feeding them spam, adds or reselling their private info to third parties
6. unlike a consumer ISP, I am supposed to provide always-on connectivity
and can not just issue reimbursements or promotional offers when capacity
planning mistakes (or other mistakes, including bored users misbehaviours)
result in broken Internet accesses

That being said:

1. I don't read the bank (or other correspondence) of my users

2. I'm not asked to read the bank (or other correspondence) of my users,
either by management or a police state (divulging it would take a legal
injunction I think, never had to deal with those)

3. When confidential (company or user) data leaks it's always at the
server endpoints, usually because those endpoints didn't care a bit about
user data confidentiality. The typical profile of such an endpoint is the
kind of social content providers you claim is in the protect-the-users
camp. Well they aren't. They're in the
pump-as-much-user-data-as-we-can-and-figure-how-to-monetize-it-later camp.
They don't like intermediaries because 1. they force them to invest
resources in something else than monetizing user data 2. we understand IT
and are not fooled by some pretty graphics and animations 3. we are on the
users' side, not theirs (I'm pretty sure *they* get served injunctions to
divulge user data and *they* are not shy to oblige police forces, who are
quite happy others do free data collection for them)

4. the alert is raised not by some evil spying on our part but by users
that belatedly realise they've been had by the glossy social (or other)
web site they wrongly assumed cared enough about them to secure their info
(and *that* unlike requests to spy on users, happens all year round)

5. Users ask operations to fix those leaks and remove the job-endangering
or social-life-endangering data those web sites published everywhere
(another common scenarii is unscrupulous contractors that attempt to
deliver business apps on the cheap by pushing processing of company data
in the 'cloud' via web services, without checking the other side can be
trusted)

6. Users ask operations to figure their computers got infected or spammed
and to fix it magically so they can get on with their life without
bothering with IT problems. They would do the same at home except no one
is mad enough to propose the kind of service we perform here at a price
they'd be willing to pay, and we can only perform it here thanks to a few
restrictions they don't like much

7. Users complain to us how come browsers still do not play well with
proxies after all those years. They actually believe the 'browsers care
about users' party line and think we're withholding some magic
browser-supported secure proxy login tech that was standardised a long
time ago. They rely on us to fill browser problem reports in their stead
(boring uninteresting IT work).

8. we can't perform the missions users ask of us without at minima seeing
the full http routing envelopes (to block dangerous web sites, to diagnose
problems, to alert users something on their computer accesses URL
associated with malware)

9. we can't perform the missions users ask of us if browsers refuse to
display the errors and messages we generate when a user stumbles on
something forbidden for its safety

10. we'd much prefer that any traffic that didn't present any
confidentiality issue was sent in clear so we could scan it for malware
and avoid to our users the unpleasantness of having their computer broken
by hostile, infected or breached web sites

11. we'd much prefer that any traffic that didn't present any
confidentiality issue was sent in clear so it could be cached and the user
experience improved by speedier browsing

12. we absolutely do *not* want to eavesdrop on bank accesses,
e-government forms, etc. We'd much prefer if such a traffic could be send
in encrypted payloads with in-clear routing metadata (there I differ a bit
from Willy, but I accept he has customers with stricter requirements than
ours)

(Sorry if I've been a bit long, but there has been enough misinformation
about intermediaries on this list)

Sincerely,

-- 
Nicolas Mailhot

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Jul 2012 17:03:20 +0300

Wow. It's like I have to run to the other side of the table to argue for the other side…

> injunction I think, never had to deal with those)

It's a good thing that you don't read bank transactions and that you don't get asked to. But you could read the bank transactions if you wanted to (or were asked to). If the data goes over HTTP you can do it with something as simple as TCPDUMP. If it goes over SSL, you'll need a TLS proxy.  The security issue is not that you want to do it, but that you and others with similar jobs to yours can do it.

> user data confidentiality.

Well, we know that some countries monitor traffic for censorship and to discover dissidents. Most would call this data leakage, and it's not at the endpoints.

> from Willy, but I accept he has customers with stricter requirements than

Does "we" include the no such agency?  Does it include its counterparts in Iran and Syria? There are all sorts of people installing middleboxes.

Yoav

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 18 Jul 2012 21:37:39 +0200

Le Mer 18 juillet 2012 16:03, Yoav Nir a écrit :
> It's a good thing that you don't read bank transactions and that you don't
> get asked to. But you could read the bank transactions if you wanted to
> (or were asked to).

No one is going to ask me to do so. Much simpler to hire some shady
character to deploy a keylogger on the target user computer, and no need
to involve an honest general-purpose network joe like me. Your threat
assessment is faulty.

> If the data goes over HTTP you can do it with
> something as simple as TCPDUMP. If it goes over SSL, you'll need a TLS
> proxy.  The security issue is not that you want to do it, but that you and
> others with similar jobs to yours can do it.

The security issue is that the protocol is not well behaved and does not
let users negotiate the level of protection they deem necessary and which
is possible to negotiate in a particular social setting. The protocol is
an absolute god-awful under-specified mess that leaves users at the mercy
of web sites, intermediaries and browser writers. Instead of giving users
the tools to assess and control connexion state, so they are able to
perform this negotiation (which they are the *only* ones legitimate to
perform) browsers and big sites have embarked in an anal blind quest to
apply TLS everywhere and *that* is the reason there are MITM ssl
interception boxes sprouting right and left today.

In an all-or-nothing world users get *nothing* on networks where they are
guests if the protocol and tools do not provide them the means to behave
like guests.

In an all-or-nothing world me and other intermediary operators get total
control because there is no middle knob between no control and total
control, and no control is not acceptable to the network owner who has
veto power by definition.

It's no use advertising the triply iron-clad TLS door to a social site
when said social site leaks user information like a sieve, often
deliberately. Not only it is not helping the user it's actively deceiving
him.

The day the protocols and tools help user check what is send in clear,
what had been integrity checked, what has been crypted, by whom and to
whom (and whom send the various error pages), and decide themselves what
they want (to they allow middlemen to accelerate or malware-check some
elements ; do they insist that others must be totally opaque even at the
cost of losing connection on networks they do not control) then people can
claim they are pro-users.

(it's not rocket science, it's just defining a protocol that permits
different compromise levels, providing means to users to tag accesses as
belonging to one category or the other, and having the web client
negotiate automatically the best compromise it can on the available
networks. And yes that would also permit users to bloc collection of data
by advertisers and other commercial entities if they wish so)

All the mashup, sharding, clouding, ajaxy stuff while convenient for web
site and browser developers has resulted in a mess no normal user could
identify any trust domain in. No amount of TLS-ing is going to fix the
trust problem. Multiplexing will make the situation worse, not better. So
please instead of continuing to make choices for the users please make
http connexions simpler to understand by users so they can make educated
security decisions (and putting grocery shopping on the same level as bank
account accesses is no making connexions simpler to understand it shows
users you don't give a fig about their actual needs).

I defy any of the pro-crypto people here to poll random people in the
street and make them say they'd rather have the internet become even more
complex and opaque, to provide total confidentiality, instead of being as
simple to use as a wired phone (even if everyone knows governments can
wiretap wired phones)

> Well, we know that some countries monitor traffic for censorship and to
> discover dissidents. Most would call this data leakage, and it's not at
> the endpoints.

I'm quite sure those countries also read dissident blogs and social sites
and that they get more info this way than by monitoring traffic.

> Does "we" include the no such agency?

The no such agency has backdoors in all the big US web sites that want to
save people in other countries from spying with TLS. It does not even need
to profile people anymore those sites are doing it openly and for free in
its stead. With likedin it can downsize its economic intelligence arm too
(or even peek directly at data processed in the clouds of Amazon &
friends)

This is spook paradise

> Does it include its counterparts in Iran and Syria?

I'm sure they will catch up on the new way of offloading intelligence to
web site operators soon if they haven't yet. The Chinese certainly did a
long time ago.

>There are all sorts of people installing middleboxes.

And there are all sorts of people that do not want to be made targets
because their technology provider decided it was smart to make them go
dark and behave like enemies of the state.

You don't solve political problems with simplistic binary technical
changes (especially when you focus on the element which is not the worst
problem today). Governments and populations adapt either way. And just
because some populations do not like their government does not necessarily
mean they prefer to give the keys of their lives to facebook or google
(which is what will happen with a system too complex to control by anyone
but first-rank websites)

-- 
Nicolas Mailhot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 18 Jul 2012 19:56:06 +0000

>save people in other countries from spying with TLS. 

If I were appointed director of NSA, I would have to invent FaceBook
if it didn't already exist.

The tinfoil-hat brigade can take it from there without further help :-)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Werner Baumann <[email-masked]>
Date: Wed, 18 Jul 2012 23:35:12 +0200

+1 especially the part about user control, from a user.
I'm tired of data miners that pretend to care for my privacy.

Werner

Am Wed, 18 Jul 2012 21:37:39 +0200
schrieb "Nicolas Mailhot" <[email-masked]>:

> >> 2. I'm not asked to read the bank (or other correspondence) of my
> >> users, either by management or a police state (divulging it would
> >> take a legal injunction I think, never had to deal with those)
> >
> > It's a good thing that you don't read bank transactions and that
> > you don't get asked to. But you could read the bank transactions if
> > you wanted to (or were asked to).
> 
> character to deploy a keylogger on the target user computer, and no
> need to involve an honest general-purpose network joe like me. Your
> threat assessment is faulty.
> 
> > something as simple as TCPDUMP. If it goes over SSL, you'll need a
> > TLS proxy.  The security issue is not that you want to do it, but
> > that you and others with similar jobs to yours can do it.
> 
> The security issue is that the protocol is not well behaved and does
> not let users negotiate the level of protection they deem necessary
> and which is possible to negotiate in a particular social setting.
> The protocol is an absolute god-awful under-specified mess that
> leaves users at the mercy of web sites, intermediaries and browser
> writers. Instead of giving users the tools to assess and control
> connexion state, so they are able to perform this negotiation (which
> they are the *only* ones legitimate to perform) browsers and big
> sites have embarked in an anal blind quest to apply TLS everywhere
> and *that* is the reason there are MITM ssl interception boxes
> sprouting right and left today.
> 
> In an all-or-nothing world users get *nothing* on networks where they
> are guests if the protocol and tools do not provide them the means to
> behave like guests.
> 
> In an all-or-nothing world me and other intermediary operators get
> total control because there is no middle knob between no control and
> total control, and no control is not acceptable to the network owner
> who has veto power by definition.
> 
> deliberately. Not only it is not helping the user it's actively
> deceiving him.
> 
> whom (and whom send the various error pages), and decide themselves
> what they want (to they allow middlemen to accelerate or
> malware-check some elements ; do they insist that others must be
> totally opaque even at the cost of losing connection on networks they
> do not control) then people can claim they are pro-users.
> 
> different compromise levels, providing means to users to tag accesses
> as belonging to one category or the other, and having the web client
> networks. And yes that would also permit users to bloc collection of
> data by advertisers and other commercial entities if they wish so)
> 
> All the mashup, sharding, clouding, ajaxy stuff while convenient for
> web site and browser developers has resulted in a mess no normal user
> could identify any trust domain in. No amount of TLS-ing is going to
> fix the trust problem. Multiplexing will make the situation worse,
> not better. So please instead of continuing to make choices for the
> users please make http connexions simpler to understand by users so
> they can make educated security decisions (and putting grocery
> shopping on the same level as bank account accesses is no making
> connexions simpler to understand it shows users you don't give a fig
> about their actual needs).
> 
> street and make them say they'd rather have the internet become even
> more complex and opaque, to provide total confidentiality, instead of
> being as simple to use as a wired phone (even if everyone knows
> governments can wiretap wired phones)
> 
> >> 3. When confidential (company or user) data leaks it's always at
> >> the server endpoints, usually because those endpoints didn't care
> >> a bit about
> > Well, we know that some countries monitor traffic for censorship
> > and to discover dissidents. Most would call this data leakage, and
> > it's not at the endpoints.
> 
> I'm quite sure those countries also read dissident blogs and social
> sites and that they get more info this way than by monitoring traffic.
> 
> The no such agency has backdoors in all the big US web sites that
> want to save people in other countries from spying with TLS. It does
> not even need to profile people anymore those sites are doing it
> openly and for free in its stead. With likedin it can downsize its
> economic intelligence arm too (or even peek directly at data
> processed in the clouds of Amazon & friends)
> 
> This is spook paradise
> 
> I'm sure they will catch up on the new way of offloading intelligence
> to web site operators soon if they haven't yet. The Chinese certainly
> did a long time ago.
> 
> changes (especially when you focus on the element which is not the
> worst problem today). Governments and populations adapt either way.
> And just because some populations do not like their government does
> not necessarily mean they prefer to give the keys of their lives to
> facebook or google (which is what will happen with a system too
> complex to control by anyone but first-rank websites)
>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 19 Jul 2012 14:21:22 +1200

On 19.07.2012 02:03, Yoav Nir wrote:
>> users,
> It's a good thing that you don't read bank transactions and that you
> don't get asked to. But you could read the bank transactions if you
> wanted to (or were asked to). If the data goes over HTTP you can do 
> it
> with something as simple as TCPDUMP. If it goes over SSL, you'll need
> a TLS proxy.  The security issue is not that you want to do it, but
> Well, we know that some countries monitor traffic for censorship and
> to discover dissidents. Most would call this data leakage, and it's
> not at the endpoints.
>
> Does "we" include the no such agency?  Does it include its
> counterparts in Iran and Syria? There are all sorts of people
> installing middleboxes.

Quite right. There are. Please stop grouping all of them into the 
"spies" category. We aren't.

There *is* information REQUIRED to be in the clear for regular 
networking delivery. One would not encrypt the src/dst IP addresses in 
TCP and expect routers to deliver the packet successfully. So why insist 
on doing it for the whole HTTP connection pipeline?
  Encrypting the entity (or even just user-specific header data) is 
sufficient.

I've been quietly reading for the last day all these posts pretty much 
advocating TLS as the be-all and end-all of security. Quietly because I 
can't figure out whether to rant or ROFL for several hours.

So Rant it is...

TLS is *broken*, has been for just over two years now. MITM is 
happening. It is routinely done by the spy camp, down to and including 
home-users spying on their childrens Facebook habits.

Today we can for the most part identify who they are by the self-signed 
certificates inserted into the stream in unexpected places.

Mandating TLS across the board will only force the law-abiding and 
conscientious White-hat admins like Nicolas and many, MANY others to 
become MITM decryptors. Security is *guaranteed* to be lower when that 
happens. We will no longer be able to identify the White-hats doing what 
they are forced to, and the Black-hats vacuuming up private information.

If this goes much further we may not even be able to tell encrypted and 
non-encrypted data streams apart anymore.

/rant

We already have TLS in the form of port 443. It would be a trivial 
protocol matter to mandating HTTP/2 only be sent over that port.

However, we need something *better* than simple TLS wrappers to meet 
the current and future security needs in HTTP/2 on port 80. Which is 
where I believe the WG effort needs to design for.

AYJ