- From: James M Snell <jasnell@gmail.com>
- Date: Fri, 15 Nov 2013 11:07:09 -0800
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Nicolas Mailhot <nicolas.mailhot@laposte.net>, Bruce Perens <bruce@perens.com>, Ryan Hamilton <rch@google.com>, David Morris <dwm@xpasc.com>, HTTP Working Group <ietf-http-wg@w3.org>, Julian Reschke <julian.reschke@gmx.de>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Perhaps a compromise approach? Allow for Non-TLS HTTP/2, but require it to use a new (non-80) default port. HTTP/2 over TLS would still use 443 by default. This would make is trivially simple to block insecure HTTP/2 wherever it is unwanted and easier to make secure HTTP/2 the default option. This doesn't solve all of the issues, but it allows us to move beyond the plaintext on port 80 concern (it also ought to greatly simplify protocol upgrade... that is, on port 80, there wouldn't be any protocol upgrade...) - James On Fri, Nov 15, 2013 at 9:31 AM, Roberto Peon <grmocg@gmail.com> wrote: > Nicolas, you're absolutely right. Deploying something that isn't part of the > commonly accepted subset of HTTP/1.1 over port 80 doesn't work. > > As an example, if you attempt to use a different entity-body compression, > for instance (something explicitly part of the HTTP/1.1 protocol), you will > find that the internet will have occasionally transform either the headers > or the entity-body or both, resulting in an uninterpretable and broken > resource received at the client. > Yes, this really happened, and oh my was it a pain to debug. In the end, > despite being far better for the user, this feature was disabled for port 80 > because it was not deployable. > > And yes, you are also right that people have attempted to use other > protocols over port 80, and that proved problematic: The most interesting of > which is probably WebSockets. As mentioned previously this essentially > doesn't work. > > That leaves us with either using a new port (infeasible, failure rate still > in high 10%s) or doing something else so as to be able to deploy. > What is the something else would you suggest? > > -=R > > > On Fri, Nov 15, 2013 at 8:02 AM, Nicolas Mailhot > <nicolas.mailhot@laposte.net> wrote: >> >> >> Le Ven 15 novembre 2013 08:25, Roberto Peon a écrit : >> > You are saying that we should use a port other than :443 for https >> > traffic? >> > ... why? >> > What backdoor are we talking about? >> >> I'm saying that your whole problem with intermediaries in clear stems >> directly from your attempts to push a new different protocol on a port >> already used for something else (ie trying to enter through the back-door >> like a juvenile delinquent because the guard on the main entry may object, >> ensuring that he will consider you a suspicious character) >> >> -- >> Nicolas Mailhot >> >
Received on Friday, 15 November 2013 19:07:56 UTC