Subject: Reasonable proposal for migrating to 2.0

From: Willy Tarreau <[email-masked]>
Date: Sun, 17 Nov 2013 21:49:28 +0100

Hi,

on friday I had some time in commuting to work on what I think a
smooth multi-step migratino path to 2.0 could look like. I've just
seen that James sent a proposal as well, but since this one is quite
different, I prefer not to mix the threads to avoid adding confusion.

1) browser: make the root and/or cert issuer on HTTPS sites for the main
   page visible all the time, just like the page's title is currently
   visible (add it next to the title or at the bottom ?)

   => End users now start to see when they're MITMed with a valid root
      cert. If a browser detects a change in the cert chain compared to
      a previous connection, it can also emit a warning. The goal is to
      restablish trust with the user.

2) protocol: add a new "httpe://" scheme to support non-authenticated
   encryption (eg for configuring a new WiFi device, or whatever would
   make better use of such low-end protection against passive monitoring
   despite not being in position of easily showing a valid cert) ; the
   lack of security must be very visible to the user (eg: blinking lock
   or modified url background color) so that there is no incentive to
   remain in this situation by accident.

   => that removes the only legitimate need for self-signed or invalid
      certs. If you want to use a self-signed cert, you're doing it
      wrong and should use httpe:// instead.

3) browser: get rid of the ability to bypass the cert error for HTTPS
   (except maybe for developers using a config option). Just like it is
   not possible at all to connect to port 25 in most browsers right now
   even if you want to insist.

   => at this step, we reach a situation where the TLS-enabled Internet
      is either visibly clean or MITMed with a visible valid cert. There
      is no way anymore to connect to a site with invalid SSL certs nor
      to an MITMed site without clearly seeing who issued the cert. The
      user also knows who he's expected to trust in this chain.

4) make HTTP/2 be used by default by the browser when https:// or
   httpe:// is used. The protocol must still be specified to support
   clear text and to work over any stream of bytes like HTTP/1 currently
   does, though the choice of its implementation and/or activation by
   default will be left to the browser.

I think this plan permits HTTP/2 to be used with the same level of
security as the underlying transport provides, which is one advantage
of making it work over a stream of bytes.

Comments ?

Willy

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 13:08:52 -0800

I think we discussed the idea of a new protocol scheme in the other thread.
 It's a huge problem.

Mike

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 13:26:33 -0800

It would only be a "huge problem" if the new scheme was required to
implement for the common case...  Which,  in my proposal at least,  it
wouldn't be.  The idea is to specifically make it the less common case,  on
purpose.  The very reasons you suggest that the new scheme would be bad are
precisely why I feel it would be good...  It makes plaintext http2 possible
but at a cost.
On Nov 17, 2013 1:10 PM, "Mike Belshe" <[email-masked]> wrote:

> I think we discussed the idea of a new protocol scheme in the other
> thread.  It's a huge problem.
>
> Mike
>
>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Nov 2013 21:57:22 +0000

>   visible (add it next to the title or at the bottom ?)

That could work for open-source browsers.  For closed source browsers
of US origin, there's no telling what they can or will tell the user
or what relationship that might have with the truth.

>2) protocol: add a new "httpe://" scheme

Anything which tries to add another scheme is going to be serious
uphill work, so it had better be for a reason which amounts to
more than some cryptographic mumbo-jumbo 99.9% of webmasters
are not entirely sure what means.

I don't think your idea clears that hurdle.

I think it is a better idea to just stick with "https:" and leave
it to the server side to negotiate as much security as they want,
and hope that user-agents faithfully indicates this to the user.

>   (except maybe for developers using a config option). 

See above.

At least 50% of the pervassive surveillance problem is software we
cannot trust on the client side.

-- 
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: Willy Tarreau <[email-masked]>
Date: Sun, 17 Nov 2013 23:47:34 +0100

> I think we discussed the idea of a new protocol scheme in the other thread.

Note that this one is *only* for the few cases where the "site" author
explicitly wants this behaviour (eg: to configure your WiFi device). We
should not see this over the internet. We might at most see it among
developers who want to more easily test HTTP/2 without having certs.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 17 Nov 2013 23:51:03 +0100

> or what relationship that might have with the truth.

You can say the same about their TLS libs anyway, so that's not an
issue we can cover using a protocol.

> are not entirely sure what means.

Note I'm not talking about sites, but more the rare use cases where
we currentl expect a self-signed cert to be OK (basically your WiFi
router's setup page, or for developers to test HTTP/2 without having
to request a cert for each host:port combination they work on).

> cannot trust on the client side.

I dont think it's that high if we're talking about surveillance. If
we're talking about information leaks, it might be much higher however.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Nov 2013 22:56:58 +0000

>to request a cert for each host:port combination they work on).

Those are also "sites" in the sense that somebody has to write
the HTTP server and the HTML.

No, let us stick with "http://" and "https://", people have a
hard enough time to understand and deploy those two correctly, 
adding another will not help.

>I dont think it's that high if we're talking about surveillance. 

One word:  Smartphones.

Between Microsoft, Apple and Google/Android, I doubt it is as low
as 50%.  (I'm assuming we're not just talking NSA here ?)

---

From: Martin Thomson <[email-masked]>
Date: Sun, 17 Nov 2013 16:20:42 -0800

On 17 November 2013 14:51, Willy Tarreau <[email-masked]> wrote:
>> For closed source browsers

It's not like you could say... check or anything.  Given that it only
takes one reasonably-aware user to discover a lie, I don't think a
closed source browser is really going to take those sorts of risks.

I don't know about you, but I sleep in my AFDB.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 18 Nov 2013 01:32:05 +0100

>I don't know about you, but I sleep in my AFDB.

http://web.archive.org/web/20051124011725/http://people.csail.mit.edu/rahimi/helmet/
(THEY have since had it deleted, but apparently forgot the archive.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Martin Thomson <[email-masked]>
Date: Sun, 17 Nov 2013 16:37:00 -0800

> (THEY have since had it deleted, but apparently forgot the archive.)

Now you have to decide if I knew about that study before I posted.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 18 Nov 2013 07:53:27 +0000

In message <[email-masked]>
>closed source browser is really going to take those sorts of risks.

I think your game-theory calculus is wrong.

Your one "reasonably-aware" user can indeed spend his time disassembling
a closed source browser, and audit the rather hard to read and
understand result for security "features".

And he also needs to disassemble the entire kernel as well, in order
to be sure the brower you disassembled is the one getting actually
getting executed.

... or he can grab an open-source browser and audit the source code and
compile it himself.

Guess what:  I have yet to hear about anybody who did the former
massive amount of work, who were not looking to gain a competitive
advantage in the browser-attack business.

So no, Ken Thompson is still spot on:  The Question of Trusting Trust
is still unanswerable.