Reasonable proposal for migrating to 2.0

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

Received on Sunday, 17 November 2013 20:49:51 UTC