Re: Reasonable proposal for migrating to 2.0

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

Mike



On Sun, Nov 17, 2013 at 12:49 PM, Willy Tarreau <w@1wt.eu> wrote:

> 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
>
>
>