Re: Reasonable proposal for migrating to 2.0

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" <mike@belshe.com> wrote:

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