- From: Adrien W. de Croy <adrien@qbik.com>
- Date: Mon, 02 Apr 2012 23:11:07 +0000
- To: "Robert Collins" <robertc@squid-cache.org>, William Chan (陈智昌) <willchan@chromium.org>
- Cc: "Roberto Peon" <grmocg@gmail.com>, "Mike Belshe" <mike@belshe.com>, "Amos Jeffries" <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
------ Original Message ------ From: "Robert Collins" <robertc@squid-cache.org> To: "William Chan (陈智昌)" <willchan@chromium.org> Cc: "Adrien W. de Croy" <adrien@qbik.com>;"Roberto Peon" <grmocg@gmail.com>;"Mike Belshe" <mike@belshe.com>;"Amos Jeffries" <squid3@treenet.co.nz>;"ietf-http-wg@w3.org" <ietf-http-wg@w3.org> Sent: 3/04/2012 11:04:08 a.m. Subject: Re: multiplexing -- don't do it >On Tue, Apr 3, 2012 at 10:38 AM, William Chan (陈智昌) ><willchan@chromium.org> wrote: > >> >>Hypothetically speaking, if HTTP/2.0 were TLS only, then either vendors >>would have to move to explicit proxies or to SSL MITM... >> > > >You say 'move to', but the reality has been for years that vendors >*have* SSL MITM up and running. Hell, a CA was busted a month or so >back for issuing wildcard certs (top level wildcard no less!) to >organisations that wanted to MITM all their traffic... nevermind that >they could then issue a cert for *any* domain which would be in >default browsers cert list... > >SSL MITM isn't something we need to work hard to *avoid*, its >something we have to deal with today. > >The best we can do is setup an environment where there is less or even >no need for SSL MITM, where folk that are doing SSL MITM today can >migrate to something a little less toxic tomorrow. > > completely agree. MITM is a PITA for vendors, you have to ship your signing cert, and real-time generate spoofed signed certs to fool the browsers. So providing explicit support would make life a fair bit easier. I'm pretty sure everyone who wrote MITM was holding their nose at the time. Adrien > >-Rob > >
Received on Monday, 2 April 2012 23:11:33 UTC