Subject: HTTPS, proxying, and all that...

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 11 Jan 2013 09:10:22 +0000

Here's a bit of relevant, real-time news, which should have great
impact on the long term reality of HTTP/2.0:

http://gigaom.com/2013/01/10/nokia-yes-we-decrypt-your-https-data-but-dont-worry-about-it/

-- 
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: Ilya Grigorik <[email-masked]>
Date: Fri, 11 Jan 2013 10:57:07 -0800

> http://gigaom.com/2013/01/10/nokia-yes-we-decrypt-your-https-data-but-dont-worry-about-it/

How does this impact the "long term reality of HTTP/2.0"? The underlying
issue in the above article is that any browser/accelerator which relies on
server-side rendering will either have to skip any HTTPS page and resource,
or it will have to run as a MITM, which is what Nokia browser and Opera
Mini are doing. This has nothing to do with HTTP itself, it's a limitation
of the chosen browser technology (and not the only limitation.. limited or
no JS is another huge problem, rendering this type of browser useless for
much of the modern web).

ig

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 11 Jan 2013 19:20:56 +0000

--------
In message <[email-masked]>
, Ilya Grigorik writes:

>How does this impact the "long term reality of HTTP/2.0"?

Quite simple:

Right now HTTPS is designed to implement end-to-end crypto, but while
that is a nice ideal, it is not possible for IETF to enforce this in
practice.  The result is that people circumvent the design of HTTPS,
with a host security issues as a result of broken design assumptions.

HTTP/2.0 should be designed so that such intrusions of the "end-to-end
argument" does not cause more than the minimally necessary loss of
security.

Or if you will: "Graceful degradation"

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Jan 2013 19:44:19 +0000

On 01/11/2013 07:20 PM, Poul-Henning Kamp wrote:
> that is a nice ideal, 

That's not an ideal. Its how HTTPS is designed. I don't think
anyone thought then or now that HTTPS was an idealistic
endeavour.

> it is not possible for IETF to enforce this in
> practice.  

The IETF doesn't enforce anything like this, nor try to, nor
want to try to.

If someone abuses our protocols (which from reports is what
seems to have happened here) there's nothing we can do to
stop them. I would expect that the market and increasing
security awareness might do that. For example. I'd be quite
surprised if any banks were particularly happy to see these
recent reports.

We can and are working on ways to allow for better detection
of such MITM attacks, but that's different.

> The result is that people circumvent the design of HTTPS,

Feel free to document a design that is not trivially insecure
and that's acceptable to e.g. the likes of banks and educated
end users and the IETF as a whole. FWIW, I've never seen such
a design. All I've seen so far is the precursor arm-waving for
such a design;-)

You can require that a circle be squared as much as you
like and complain when that doesn't happen, but that's not
particularly helpful IMO.

> Or if you will: "Graceful degradation"

I look forward to reading your I-D.

Stephen.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 11 Jan 2013 19:57:10 +0000

--------
In message <[email-masked]>, Stephen Farrell writes:

>stop them.

The reason they "abuses your protocol" is that the protocol has
been designed such that it does not support a surprisingly
big class of legitimate usecases.

Theirs may or may not be legit, but the example clearly
illustrates the security failure you so often see, when
a protocol does not degrade gracefully.

>of such MITM attacks, but that's different.

Yes, fine, cool.

But how about allowing for them, for instance where they are mandated
by law ?

(Pornfilters at schools, inmates communications in high security
prisons.  Parental control filters in homes.)

---

From: Yoav Nir <[email-masked]>
Date: Fri, 11 Jan 2013 20:04:30 +0000

> argument" does not cause more than the minimally necessary loss of

Define "minimally necessary".

The issue described in the link is described as a MitM attack. But that's misleading. The browser is not the victim here, but a willing participant. I think the term "main in the browser" is more appropriate. And I don't think you can ever get a protocol specification to overcome your browser participating in an attack.

With real MitM attacks, the browser detects the attack. You get the warning screen about untrusted signers. This gives the browser (and by extension, the user) a choice of accepting the decrypting proxy, or avoiding use of the browser as long as network conditions are such. 

An improvement would be to give the server the same choice, but I don't see how that can be done for servers that do not require client authentication.

Anyway, I don't see how HTTP/2 could do any better than that without becoming some kind of cross-layer monstrosity.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Jan 2013 20:07:17 +0000

> The reason they "abuses your protocol" is that the protocol has

Its your protocol as much as mine. We're both IETF participants.

> prisons.  Parental control filters in homes.)

Again, feel free to post your I-D that meets whatever laws you
prefer to pick from whatever countries you prefer, and that is
not trivially insecure. We're not interested you telling us
about the laws of course, but only the engineering design.

And if you're picking legal things on which to base your
design, don't forget to include the right to be forgotten. No
point making it too easy for you;-)

The problem you have IMO is that you're posing a requirement
that's beyond the state of the art at least. (To be able to
sensibly mix e2e and hbh security in a very general context.)
It might be easy to state the requirement, but that doesn't
mean there's a practical solution.

S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 11 Jan 2013 20:20:00 +0000

--------
In message <[email-masked]>
, Yoav Nir writes:

>The issue described in the link is described as a MitM attack. 

Which is the only option available with HTTPS.

It is surprisingly more common than you'd think in $bigcorp settings.

>Anyway, I don't see how HTTP/2 could do any better than that without
>becoming some kind of cross-layer monstrosity.

It could offer per-hop encryption as an alternative to end-to-end
encryption, while keeping the user reliably informed about the
level of security.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 11 Jan 2013 20:24:26 +0000

--------

>that's beyond the state of the art at least.

There is nothing "state of the art" about mixing p2p and e2e
trust and security, PTT's and banks have been doing it for
centuries.

The problem the HTTPbis effort has, is that it's trying to
improve on one of the worlds most popular and used protocols[1].

Addressing some of its actual user-perceived shortcomings would
be a very smart move from a marketing point of view.

Poul-Henning

[1] Yes, I'm lumping HTTP and HTTPS here, and that is administratively
wrong in IETF, but very common in the rest of the world.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 11 Jan 2013 20:29:04 +0000

> prisons.  Parental control filters in homes.)

Where were you when we proposed http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 ?

Anyway, in all those cases, wouldn't spyware on the (school-, parent-, or prison-provided) computer do the trick just as well as trusting them to go through a particular proxy?

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Jan 2013 20:34:18 +0000

> trust and security, PTT's and banks have been doing it for

Feel free to post details. I at least don't know what
you mean.

(I'm also not aware of how 16th century PTT's operated
to be honest. RFC 1149 perhaps?:-)

> be a very smart move from a marketing point of view.

Yes, but this isn't a marketing exercise.

If you're moving from impossible-to-meet requirements
towards marketing, may I suggest you're heading in the wrong
direction?

S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 11 Jan 2013 20:44:19 +0000

--------

>Feel free to post details. I at least don't know what

I'm sure you do, you just don't know that you know it.

If you are working in a big organization, I'm sure you don't
go to the post-office yourself, you have an intern mail-service
that will do so for you, and thanks to the separation of
envelope from message, they can do so, without opening your
letter.

>to be honest. RFC 1149 perhaps?:-)

Amongst other technologies.

I'm sure the chinese and the romans would beg to differ, but
read for instance:

http://www.scotsman.com/lifestyle/heritage/the-oldest-post-office-in-the-world-1-465812

>Yes, but this isn't a marketing exercise.

Ask the IPv6 people if they still think that was a smart
position to take.

Catering to your users needs is a good way to win adoption.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 11 Jan 2013 20:48:39 +0000

--------
In message <[email-masked]>, Yoav Nir writes:

>Where were you when we proposed http://tools.ietf.org/html/draft-mcgrew-tls=
>-proxy-server-01 ?

No idea, but I have previously expressed my appreciation for that idea.

The bit I feel is missing is to tell the user, reliably, how far he can
expect privacy ensured by crypto, and who the party he must trust from
there on out claims to be.

As far as I can tell, you have the information in the protocol, but if
there were anything about how/when or even why it should be presented
to the user, I failed to spot it when I read the draft last year.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Jan 2013 21:46:15 +0000

Ok I think this has wandered far enough for me. Send me a link to your draft when it's ready.
S

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Jan 2013 22:52:36 +0100

> a design. All I've seen so far is the precursor arm-waving for

How does this differ from what we have today?

Eliot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 11 Jan 2013 22:03:59 +0000

--------

>How does this differ from what we have today?

Today HTTP and HTTPS does not offer the concept of a (grudingly!)
trusted proxy:  There is no way to have security from your browser
to a proxy which implements your companys IT policies, and from
that proxy to your banks net-bank service.

Either your proxy gives up implementing the policy, and let you
connect HTTPS (via CONNECT) end-to-end, or your proxy denies
you access, since it cannot implement its policy.

The problem is that people have found a workaround for this HTTPs
shortcoming:  They (make you) install a bogo-certificate on your
machine, which terminates your HTTPS on the proxy, so it can implement
its policy, and God knows what happens from there...

And with that, I'm signing off for tonight.

We've dicussed this issue previously, people doubted it happened
in the real world, I have now pointed to a news-item that settles
that question, and we can each continue our crusades against our
respective windmills.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 14 Jan 2013 14:23:09 +0100

On Fri, Jan 11, 2013 at 08:20:00PM +0000,
 Poul-Henning Kamp <[email-masked]> wrote 
 a message of 22 lines which said:

> encryption, while keeping the user reliably informed about the level
> of security.

Outside of the charter of the working group
<http://tools.ietf.org/wg/httpbis/charters>, I think ("Explicitly
out-of-scope items include...")

But there are three bigger problems:

1) It complicates the protocol, and complexity is the worst ennemy of
security.

2) I fail to see how it could be possible without introducing a lot of
new attack entry points.

3) [Warning: a citizen expresses a political opinion] I have zero
sympathy for the mentioned use-cases.

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Jan 2013 10:28:39 -0600

The only way to degrade gracefully that I can see is to have one more
layer of end-to-end security (key exchange, authentication,
per-message security) that provides at least integrity protection that
survives any MITM at lower layers.  That way you can a) detect MITMs,
b) let them at most see the plaintext.

And if you want you could further encrypt data and let the MITMs at
lower layers eat cake.  But this would merely set off a race to MITM
the new protocol.  Also we'd be accused of trying to replace TLS,
re-inventing the wheel, ...

Nico
--

---

From: James M Snell <[email-masked]>
Date: Mon, 14 Jan 2013 08:52:55 -0800

Well.. jumping into in a bit.. there is this draft:

  http://tools.ietf.org/html/draft-snell-httpbis-keynego-00

In it, I define an experimental in-session key negotiation mechanism built
around SPDY's framing mechanism. The way it's defined, it would allow for
both hop-by-hop and end-to-end encryption scenarios and provides a much
more flexible model than what exists today with TLS... for one, security
can be negotiated and renegotiated on the fly without tearing down and
reestablishing the tcp connection. Within a single SPDY session you could
actually have multiple layers of encryption going on, with the SYN_STREAM
and the DATA frames each being encrypted using distinct keys negotiated
with different entities involved in the connection.

I will stress that, for now, this is entirely theoretical and experimental,
but something like this would address the use case.

- James

---

From: Roberto Peon <[email-masked]>
Date: Mon, 14 Jan 2013 10:05:22 -0800

And this one too.
https://datatracker.ietf.org/doc/draft-rpeon-httpbis-exproxy/

But, isn't all this a non-starter and outside the scope?
-=R

On Mon, Jan 14, 2013 at 8:52 AM, James M Snell <[email-masked]> wrote:

> I will stress that, for now, this is entirely theoretical and
> experimental, but something like this would address the use case.
>
> - James
>
>
> On Fri, Jan 11, 2013 at 1:46 PM, Stephen Farrell <
> [email-masked]> wrote:
>

---

From: James M Snell <[email-masked]>
Date: Mon, 14 Jan 2013 12:25:05 -0800

Possibly outside the scope for the core of http/2 but definitely something
that is worth investigating orthogonally. At the very least, we ought to
keep this in mind so we don't end up completely precluding the possibility
of a solution here in the design of http/2.

On Mon, Jan 14, 2013 at 10:05 AM, Roberto Peon <[email-masked]> wrote:

>> In it, I define an experimental in-session key negotiation mechanism
>> built around SPDY's framing mechanism. The way it's defined, it would allow
>> for both hop-by-hop and end-to-end encryption scenarios and provides a much