Subject: 2 questions

From: Glen <[email-masked]>
Date: Sat, 28 Mar 2015 14:43:45 +0000

Hi,

I have 2 questions, if I may.

1. What were the reasons for HTTP/2 not requiring TLS?

Is there a significant performance consideration, is it related to the cost of certificates (which is now fairly low or even free), or are there other technical reasons?

It would be nice if the web was just "secure by default", and I would have thought that now would be the right time to move in that direction.

Also, at least 2 of the major browser vendors have said that they won't be supporting HTTP/2 without TLS, so surely no one is going to want to run their website without it?

2. Are the BREACH and CRIME exploits still applicable, especially with regard to content (body) compression? If so, does that mean that it's not possible to compress content (with gzip, for example) and still maintain security?

Please respond as if I were a layman, as my knowledge on these subjects is somewhat limited.

Thanks.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 29 Mar 2015 00:32:09 +0300

> On Mar 28, 2015, at 5:43 PM, Glen <[email-masked]> wrote:
> 
> Hi,
> 

Right now, about a third of web requests use TLS. Clearly there is a constituency for the web in the clear, although there is a definite trend towards more TLS. If HTTP/2 is supposed to replace HTTP/1 entirely, it should support both. Two vendors said they would not support, one said they would. Using the UPGRADE mechanism, an in-the-clear website can support both HTTP/1 and HTTP/2.

As you say, it would be nice if the web was secure by default, but it is not up to you or me to force the web in that direction, or to withhold better performance in HTTP until they fit my definition of “nice”. This is the first rule of the Internet: you are so not in charge.

TLS has a significant cost in processing power, and there are a few cases where its use is inappropriate. Those cases can probably be served nicely by HTTP/1, but we aim to replace HTTP/1.

> 2. Are the BREACH and CRIME exploits still applicable, especially with regard to content (body) compression? If so, does that mean that it's not possible to compress content (with gzip, for example…

CRIME was specific to retrieving cookie information by having a shared compressed state for resource name (which was under attacker control) and the cookie (which was constant).
HTTP/2 does not compress headers like that, so this is gone.

BEAST relies on content encryption, and on the attacker being able to inject stuff into the response, discovering pieces of static content such as CSRF tokens. There are ways to foil this attack that worked for HTTP/1, and they should apply similarly to HTTP/2. HTTP/2 itself does nothing to solve this.

HTH

Yoav

---

From: Cory Benfield <[email-masked]>
Date: Sat, 28 Mar 2015 21:36:43 +0000

> On 28 Mar 2015, at 14:43, Glen <[email-masked]> wrote:
> 

The shortest answer to this is that there was not much extra cost in allowing plaintext HTTP/2, and it was requested by several WG members for specific use cases where TLS may not be appropriate.

In practice, most of HTTP/2 in the open web will be deployed using TLS because by and large plaintext intermediaries are likely to misunderstand or mangle HTTP/2. Chrome and Firefox have no plans to support HTTP/2 in plaintext, which in practice means most websites won’t bother either.

> It would be nice if the web was just "secure by default", and I would have thought that now would be the right time to move in that direction.

We are. =) Check out the opportunistic encryption draft[0] for examples of how we’re moving in that direction. Firefox already supports this draft, so websites can today start offering opportunistic HTTP-over-TLS if they would like to.

> 2. Are the BREACH and CRIME exploits still applicable, especially with regard to content (body) compression? If so, does that mean that it's not possible to compress content (with gzip, for example…

Yes with regard to body compression, no with regard to headers. As I understand it this can be somewhat mitigated by the use of padding in HTTP/2, but it cannot be entirely removed.

It is possible to compress content without harming security *in certain cases* with well-crafted algorithms (see HPACK), but it may not be possible to do it with gzip. I’m not an expert in this area, so I won’t say more: I’ll let someone who knows more than me dive in.

Cory

[0]: https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-01

---

From: "Constantine A. Murenin" <[email-masked]>
Date: Sat, 28 Mar 2015 18:19:30 -0700

> Is there a significant performance consideration, is it related to the cost of certificates (which is now fairly low or even free), or are there other technical reasons?

This is incorrect.  The cost of certificates for webmasters is not 
"fairly low or even free".

If you have one single domain and you disregard the opportunistic costs 
you have to repeatedly endure in order to renew the certificate at least 
once per year (for the rest of the life of the web-site), sure, the cost 
may indeed be "fairly low or even free".

However, that is not the case if you have a few dozen domains (or even 
subdomains), have had all of them on a single IPv4 address prior to the 
HTTPS considerations, have requirements to support fairly recent 
hardware with Android 2.3 (which has no SNI), want all of your users, 
including Android 2.x ones, to be able to navigate to your web-site when 
clicking the (https://) links posted outside of your control etc.

Think of all the consumer electronic devices like the 15 USD 802.11n 
wireless routers -- who's going to be paying for their certificates? 
Who will be renewing them every year at the "fairly low or even free" cost?

 > It would be nice if the web was just "secure by default", and I would 
have thought that now would be the right time to move in that direction.

Yes, but mandating a mandatory "https://" address scheme is not a 
solution.  As has been mentioned, Opportunistic Encryption through the 
"http://" address scheme is what would help here instead.

Cheers,
Constantine.

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 29 Mar 2015 18:23:02 +1000

On 29 March 2015 at 00:43, Glen <[email-masked]> wrote:

> [...]
> It would be nice if the web was just "secure by default", and I would have
> thought that now would be the right time to move in that direction.
>
>
It's worth remembering that HTTP also exists outside the web. I know this
is the *I*ETF, and we're specifying *internet* standards, but it behooves
us to think outside the big grey cloud if we can do something that benefits
the entire worldly computer community, even those parts not on the open
net/web -- especially when it's a protocol as big as HTTP.

I'd rather not run TLS on my firewalled/airgapped home network when there's
no real reason, especially if that required an insecure cert to be
firm-coded into the web server in my intelligent switch, or my printer, or
my smart-fridge (if I had one of those). The counter-argument was that I
could just use HTTP/1 there, but that's either lame ("H2 isn't as useful as
HTTP/1") or snobbish ("you're not good enough to use H2"), depending on how
you interpret it. It would also disappoint me if I were to take part in the
WG and help (in a small way) to define this awesome new protocol, and even
work on my own implementation, only to discover that I couldn't use it in
some circumstances.

And on costs: I'm personally not keen on paying extra (ongoing) for my web
hosting to have a unique IP address, and then pay every year for a SAN
certificate for my vhosts (I'd need to cover both foo.net and www.foo.net
at the least).

Those were my main motivations for pushing back. And as others have said,
there are other ways to get "secure by default" than requiring "TLS
everywhere."

​Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: "Walter H." <[email-masked]>
Date: Sun, 29 Mar 2015 13:24:32 +0200

Hello,

On 28.03.2015 22:36, Cory Benfield wrote:
>> On 28 Mar 2015, at 14:43, Glen<[email-masked]>  wrote:
>>
these use cases are any websites for the public without any access 
restrictions ...
> In practice, most of HTTP/2 in the open web will be deployed using TLS
the wrong way ...
> Chrome and Firefox have no plans to support HTTP/2 in plaintext, ...
this doesn't make any sense, because in case every website is encrypted 
the sensitivity for invalid x509 certificates becomes less ...
and so it makes it easier faking banking sites - the most sensitive part 
of encrypted websites;
> We are. =) Check out the opportunistic encryption draft[0] for examples of how we’re moving in that direction. Firefox already supports this draft, so websites can today start offering opportunisti…
as said above: the wrong way;

just think of the fact why transports of money are escorted by police 
and not everything else, too.

Greetings,
Walter

---

From: "Walter H." <[email-masked]>
Date: Sun, 29 Mar 2015 13:34:43 +0200

On 29.03.2015 03:19, Constantine A. Murenin wrote:
>> Is there a significant performance consideration, is it related to 
>> the cost of certificates (which is now fairly low or even free), or 
>> are there other technical reasons?
>
In fact they are fairly low or even free, because nobody tells you 
buying at the most expensive dealer ;-)

just try e.g. StartCom ;-)
> wireless routers -- who's going to be paying for their certificates?
any cheap routing box, either with WLAN or not does use self-signed 
certificates; and business environments have different use cases and/or 
hardware;
and there they can have their own CA, too ...

> solution.
use TLS with the address scheme "https://", and
>   As has been mentioned, Opportunistic Encryption through the 
not any encryption with the "http://" address scheme;

you don't sell cows as pigs, do you;

Greetings,
Walter

---

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Mar 2015 00:50:06 +0000

You're skipping the discussion about why price of the cert is not the cost of running TLS.  There's admin overhead in renewing the cert for each domain, there's network infrastructure overhead in providing each domain a unique IP address (because you can't guarantee every client supports SNI, much as we'd like to), and that additional network infrastructure cost means hosting becomes more expensive.  Free certs don't mean free TLS, though obviously they're a nice step in that direction.

But fundamentally, the argument was that if HTTP/2 needed to cover the same scenarios as HTTP/1.1, that set of scenarios included traffic that, by operator choice for whatever reason, is not encrypted.  We're not trying to judge why the operator does it that way, and there will be obvious practical barriers to using HTTP/2 across the internet in plaintext for a while, but the scenario exists and was in-charter, so we continue to support it.  (The same reason we didn't take beneficial-but-breaking changes to Cookies or other semantics, for example.)

-----Original Message-----
From: Walter H. [mailto:[email-masked]] 
Sent: Sunday, March 29, 2015 4:35 AM
To: Constantine A. Murenin
Cc: [email-masked]
Subject: Re: 2 questions

Greetings,
Walter

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 30 Mar 2015 03:15:47 +0000

I can buy that 1/3 of web requests use TLS.

however that does not apply to 1/3 of web sites using TLS.  Probably 
just FB and google alone account for 1/3 of web requests.

There are surely hundreds of millions of sites.  That's at least tens of 
millions of administrators who will need to take on the burden of making 
TLS work on their site.  Many will not see any point in this.  Pretty 
much all the sites that felt a need to deploy TLS will have already done 
so, and the others will not thank the IETF or google or the chromium 
project for attempting to force costs on them.

Please people do not conflate %-age of requests with %-age of sites.

------ Original Message ------
From: "Yoav Nir" <[email-masked]>
To: "Glen" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 29/03/2015 10:32:09 a.m.
Subject: Re: 2 questions

>>  Also, at least 2 of the major browser vendors have said that they 
>>won't be supporting HTTP/2 without TLS, so surely no one is going to 
>>want to run their website without it?
>
>Right now, about a third of web requests use TLS. Clearly there is a 
>constituency for the web in the clear, although there is a definite 
>trend towards more TLS. If HTTP/2 is supposed to replace HTTP/1 
>entirely, it should support both. Two vendors said they would not 
>support, one said they would. Using the UPGRADE mechanism, an 
>in-the-clear website can support both HTTP/1 and HTTP/2.
>
>As you say, it would be nice if the web was secure by default, but it 
>is not up to you or me to force the web in that direction, or to 
>withhold better performance in HTTP until they fit my definition of 
>“nice”. This is the first rule of the Internet: you are so not in 
>charge.
>
>TLS has a significant cost in processing power, and there are a few 
>cases where its use is inappropriate. Those cases can probably be 
>served nicely by HTTP/1, but we aim to replace HTTP/1.
>
>>  2. Are the BREACH and CRIME exploits still applicable, especially 
>>with regard to content (body) compression? If so, does that mean that 
>>it's not possible to compress content (with gzip, for example) and 
>>still maintain security?
>
>CRIME was specific to retrieving cookie information by having a shared 
>compressed state for resource name (which was under attacker control) 
>and the cookie (which was constant).
>BEAST relies on content encryption, and on the attacker being able to 
>inject stuff into the response, discovering pieces of static content 
>such as CSRF tokens. There are ways to foil this attack that worked for 
>HTTP/1, and they should apply similarly to HTTP/2. HTTP/2 itself does 
>nothing to solve this.
>
>HTH
>
>Yoav
>
>

---

From: Cory Benfield <[email-masked]>
Date: Mon, 30 Mar 2015 09:26:27 +0100

On 30 March 2015 at 04:15, Adrien de Croy <[email-masked]> wrote:
> however that does not apply to 1/3 of web sites using TLS.  Probably just FB
> and google alone account for 1/3 of web requests.
>
> millions of administrators who will need to take on the burden of making TLS
> work on their site.  Many will not see any point in this.  Pretty much all
> the sites that felt a need to deploy TLS will have already done so, and the
> others will not thank the IETF or google or the chromium project for
> attempting to force costs on them.

No-one is being *forced* to do anything. HTTP/1.1 is not going away.
If you dig back through the archives of this working group you'll
repeatedly find statements from almost all camps that HTTP/1.1 will be
around for the foreseeable future. Website owners that cannot set up
TLS will still find plenty of support for plaintext HTTP.

In this case I think Google and Firefox are probably right: HTTP/2 in
plaintext is likely to break frequently and mysteriously. This is
mostly because of intermediaries that believe they understand HTTP,
but don't do it very well (HAProxy is a good example I can think off
of the top of my head). These intermediaries are usually transparent
to HTTP/1.1 users, but they will likely break HTTP/2 traffic over port
80. Chrome and Firefox are therefore acting in the interest of both
users and operators when they forbid this kind of traffic. They're
saving your users from thinking your website is broken because their
ISP deployed some terrible intermediate 'service' that mangles HTTP/2
(consider Comcast's injection of HTTP headers, for example).

At this point in time, my HTTP/2 implementation does not support
plaintext HTTP/2. I will add support for it in the next few weeks, but
I do not expect it to work in the vast majority of cases, and will be
emitting warning logs to that effect.

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 30 Mar 2015 21:45:15 +1300

> just try e.g. StartCom ;-)

Tried that. Got a far as where their Terms and Conditions forbid me from
getting certs on behalf of my clients.

> and there they can have their own CA, too ...

Go ahead. Try it. The modern browsers will all throw up confusing
looking popups about security thingys, red stop signs, unlocked
padlocks, etc in front of their users on each request using self-signed
certs and Chrome will not even permit the device control pages to be opened.

> you don't sell cows as pigs, do you;

Exactly why http:// is used instead of https://.

Like selling a bull instead of a cow - has many great and similar uses
(meat, better workloads, etc), same breed of beast, but milk supply is
not in the marketing brochure.

If you want milk, pay more for a real cow. I just need something that
will pull a cart.

Dont cull the entire pig population because someone sold you a "beef"
sausage filled with pork. None can save you bacon after that.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 30 Mar 2015 22:27:31 +1300

On 30/03/2015 9:26 p.m., Cory Benfield wrote:
> On 30 March 2015 at 04:15, Adrien de Croy wrote:
>>

So your answer is "Just use HTTP/1.1" ?

Regardless of how long the transition would take one of the goals of
HTTP/2 is to replace it. *Any* network which is forced to stay with
HTTP/1 simply because of a missing protocol capability is a failure of
HTTP/2.

> plaintext is likely to break frequently and mysteriously.

Guesses and supposition. Look at who you are throwing those arguments at
... the very authors of the major middleware implementations.

The Chrome choice was based on SPDY metrics IIRC. Which measured how
many connections over TLS were force to "just use HTTP/1.1" versus
allowed to use SPDY. That was done under conditions where *none* of the
middleware supported SPDY and TLS was able to supply a bypass.

Neither of those measurement conditions are true for HTTP/2. We major
middleware implementations authors participate in the WG and are
actively implementing HTTP/2 already. The growth of TLS interception
will undoubtedly have reduced TLS ability to bypass middleware.

The middlware argument for TLS is a red herring.

> This is
> 80.

Those of us participating in the WG have already ensured that our
software, even legacy installs, interoperates properly with HTTP/2 to
trigger HTTP/1.1 fallback cleanly during the transition. The HTTP/2
protocol is also a lot more strict syntactically so many mistakes and
problems are simply no longer possible once the software is upgraded.

> Chrome and Firefox are therefore acting in the interest of both

Injection of headers is compliant with HTTP (both versions).

One can as easily point at the many millions of users forced to endure
horrible network lag issues and sometimes outright DoS when Chrome
implemented SDCH encoding.

Dont kid yourself about browsers protecting either users or websites -
at least no more than they need to make gains in the browser wars. We
have a loooong laundry list of things they refuse to do that would
vastly improve end users privacy, security, and website efficiency.
Their focus IME is towards their own corporate goals (as one should expect).

> emitting warning logs to that effect.

Are you emitting similar warnings for all HTTP/2-over-TLS failures?
 You will find a lot of middleware out there these days decrypting the
TLS and demanding HTTP/1 inside. The magic PRI prefix "request" works
the same regardless of TLS usage - as it was designed to.

Amos

---

From: Cory Benfield <[email-masked]>
Date: Mon, 30 Mar 2015 12:19:55 +0100

> HTTP/1 simply because of a missing protocol capability is a failure of

What protocol capability would that be? As I said far earlier in this
thread, HTTP/2 supports plaintext: Chrome and Firefox don't support
it. The protocol is capable: the implementations are not.

If the protocol suffers problems from intermediaries not understanding
HTTP/1.1, then yes, there was a failure in the protocol when we chose
to use TCP port 80 for plaintext. We can deal with that problem if and
when it does arise.

> ... the very authors of the major middleware implementations.

I apologise for tarring with the same brush, that was never my
intention. However, I'm talking to authors of *two* of the major
middleware implementations. There are lots of them, some of which do
not support HTTP/2 and may never (varnish leaps to mind). Many
intermediaries will support HTTP/2 in plaintext well and cleanly:
those are not the ones I believe will cause problems. My worry is
*bad* middleware implementations that assume that all port 80 traffic
is HTTP/1.1, and therefore make unexpected modifications to traffic.
It is not unreasonable to want to avoid that problem by preventing
intermediaries seeing HTTP/2.

> The middlware argument for TLS is a red herring.

That is as may be, but you're arguing with the wrong person. I've
already said I plan to support HTTP/2 in plaintext in my
implementation. I'm simply repeating what my concerns are with how
successful it will be, certainly in the short term. My response was to
a question asking why HTTP/2 requires TLS, and I was saying that the
protocol does not, but some implementations do.

> Injection of headers is compliant with HTTP (both versions).

Sure is, but I was talking about doing it *badly*, which is not the
same thing. For every good, up-to-date HTTP intermediary there are two
bad ones (usually written by cowboys like me). The same is true of
servers and clients, of course, but the difference is that bad servers
are under the control of site administrators (incentivised to improve
user experience) and bad clients are under the control of users
(incentivised to change to a working client). Bad intermediaries are
often transparent and under the control of an unrelated third party.

Obviously, this is a generalisation, but it certainly applies quite widely.

> Their focus IME is towards their own corporate goals (as one should expect).

Yes, we can all accept blame here. The difference, as I mention above,
is in what those involved in an HTTP transaction can do. They have
more power over servers and clients than they do over intermediaries.

> the same regardless of TLS usage - as it was designed to.

Actually, I treat HTTP/2-over-TLS failures more aggressively: I throw
exceptions. This is primarily a security-conscious move, attempting to
maintain the semantics of HTTPS. At some stage I'll likely get a
feature request to allow this behaviour, but until that time I'm
holding HTTP/2-over-TLS to a higher standard than plaintext HTTP/2.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 30 Mar 2015 12:29:10 +0000

well from where I stand there is a certain amount of duress being 
applied to move people to TLS.

* browser vendors saying they won't support plaintext (I wonder how long 
that will last)
* not really much effort going into working through issues with 
plaintext version since it's always supposedly assumed that it won't 
really be used and people will stick with 1.1 or go to https, and issues 
will be solved.  Somehow.  Maybe.  Hopefully.

not many other options have been seriously considered for solving the 
presumed problem of bad things happening on port 80.  Like moving to 
another port.  100 is still available.

It is reasonable to want to avoid bad things but there are other ways 
than TLS, but thanks to the push to https everywhere now everyone has a 
MITM that will probably make port 443 just as broken as port 80.  Maybe 
not quite, since I guess ISPs are less likely to do that.  But still a 
lot worse now than 2 years ago.

Not to mention the concerns around moving en masse to TLS and what that 
will do for the security of TLS itself.  I'm not sure it's ready for the 
load.  CA compromises will affect a lot more sites.  They do happen and 
will continue to do so, especially as the bounty goes up by a few orders 
of magnitude.  A lot of eggs going into not many (CA) baskets.

Maybe we should be putting the effort into that first - solving issues 
with PKI before loading the whole internet onto it.  Maybe they are 
already doing that.

Adrien

------ Original Message ------
From: "Cory Benfield" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Yoav Nir" <[email-masked]>; "Glen" <[email-masked]>; 
"[email-masked]" <[email-masked]>
Sent: 30/03/2015 9:26:27 p.m.
Subject: Re: 2 questions

>>just FB

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Mar 2015 16:03:44 +0300

> On Mar 30, 2015, at 3:29 PM, Adrien de Croy <[email-masked]> wrote:
> 
> 
> well from where I stand there is a certain amount of duress being applied to move people to TLS.
> 
> * browser vendors saying they won't support plaintext (I wonder how long that will last)
> * not really much effort going into working through issues with plaintext version since it's always supposedly assumed that it won't really be used and people will stick with 1.1 or go to https, and issues will be solved.  Somehow.  Maybe.  Hopefully.
> 
> not many other options have been seriously considered for solving the presumed problem of bad things happening on port 80.  Like moving to another port.  100 is still available.
> 
> It is reasonable to want to avoid bad things but there are other ways than TLS, but thanks to the push to https everywhere now everyone has a MITM that will probably make port 443 just as broken as port 80.  Maybe not quite, since I guess ISPs are less likely to do that.  But still a lot worse now than 2 years ago.

Not quite. ALPN is carefully engineered to play nice with MitM. The MitM that are installed now (and for the last 8 years) will easily strip the ALPN extension and downgrade client and server to HTTP/1.

Yoav

---

From: Roland Zink <[email-masked]>
Date: Mon, 30 Mar 2015 15:57:33 +0200

> * browser vendors saying they won't support plaintext (I wonder how 
me too as this doesn't seem to be much effort
> really be used and people will stick with 1.1 or go to https, and 
> issues will be solved.  Somehow.  Maybe.  Hopefully.
It is easier to upgrade to an http2 capable server than to switch to 
https. So I would prefer to see plaintext http2 as well.
> another port.  100 is still available.
 From a network perspective this seems to logical thing to do. A 
different port probably means a different URL scheme (http2 lovely), but 
this then shows ossification at the content provider side (not the usual 
middle box claim), so I guess this will not fly.
> than TLS, but thanks to the push to https everywhere now everyone has 
> a MITM that will probably make port 443 just as broken as port 80.  
> Maybe not quite, since I guess ISPs are less likely to do that.  But 
> still a lot worse now than 2 years ago.
TLS is not end to end. It is well adjusted to the content provider side 
which could choose where to terminate TLS and can throw in any number of 
third parties which even gets delivered the original URL through the 
referer header. Servers can impersonate any number of identities and get 
hints how to cheat (SNI). The user on the other side has no choice, she 
doesn't get notified about the third parties and can't deploy any 
infrastructure to protect her.
>
> Not to mention the concerns around moving en masse to TLS and what 
> that will do for the security of TLS itself.  I'm not sure it's ready 
> for the load.  CA compromises will affect a lot more sites. They do 
> happen and will continue to do so, especially as the bounty goes up by 
> a few orders of magnitude.  A lot of eggs going into not many (CA) 
> baskets.
>
Giving the Internet to a small number of CAs seems also to be risky. If 
they don't like your opinion they can just revoke your certificate. 
Currently you can just get a different certificate from somebody else 
but for example with key pinning this may become more difficult.

Encryption costs energy. I heard different numbers and the numbers seem 
to go down over the years but fighting against global warming seems not 
to be an IETF goal.

In my opinion the discussion about using http2 and TLS should be 
separate and luckily http2 has both cleartext and TLS.

Regards,
Roland

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 12:56:10 -0500

> Not quite. ALPN is carefully engineered to play nice with MitM. The MitM that are installed now (and for the last 8 years) will easily strip the ALPN extension and downgrade client and server to HT…

I'm sure that this statement makes some people very sad.

That said, I can't see how a box that is able to MitM TLS can be
prevented from doing more than ALPN stripping.  If the client trusts
it, then it's got carte blanche access.

---

From: "Walter H." <[email-masked]>
Date: Mon, 30 Mar 2015 19:56:48 +0200

> getting certs on behalf of my clients.
can't your clients do this for themselves?
(didn't you think, that when someone offers something really for free, 
that it may not be reselled ...)
> looking popups about security thingys,
I have no problems doing this ...
>   red stop signs, unlocked padlocks, etc in front of their users on each request using self-signed
> certs and
using just a self signed CA cert in e.g. squid is not enough ...
>   Chrome will not even permit the device control pages to be opened.
a default setting, I'm using Chrome because of heavy security bugs in 
newer FF releases ...

---

From: "Walter H." <[email-masked]>
Date: Mon, 30 Mar 2015 21:32:06 +0200

On 30.03.2015 02:50, Mike Bishop wrote:
> You're skipping the discussion about why price of the cert is not the cost of running TLS.  There's admin overhead in renewing the cert for each domain, there's network infrastructure overhead in providing each domain a unique IP address (because you can't guarantee every client supports SNI, much as we'd like to), and that additional network infrastructure cost means hosting becomes more expensive.
that a server needs more cpu, memory and more other resources when 
sending content using TLS in comparison to just send them plain, this is 
true;
also it is true, that you need someone who renews the certs; also that 
you need a unique IP address; but it is not impossible doing so, the 
available resources would be enough;
even IP addresses;
let me explain a little example at the end, why you are right and more 
wrong at the same time;

> But fundamentally, the argument was that if HTTP/2 needed to cover the same scenarios as HTTP/1.1,
not really; or do you really think there is the need of something new 
that is the same as the old?

here the example:

think of someone or company uses Internet for e-commerce; e.g. 
presenting his products is public for anybody; this doesn't need to be 
presented in TLS,
but when someone enters data to order the products, this must be done 
using TLS;
compareable to a bank; the presentation of all products of the bank - 
e.g. interest rates, common terms and conditions, ... - can be presented
for the public without the need of TLS, but the service of electronic 
banking must only be with TLS;

now think of the "next step", the website shows advertising for what the 
company gets money, that reduces the hosting costs;
this can be done in 2 ways: using a 3rd party, this is less efficient, 
compare it to a folder together with a newspaper;
or without, the most efficient way, compare it to a newspaper that has 
printed the advertisings anywhere between
the news and other informations;

now think of the people that do not want see the advertisings; with the 
newspaper it is easy to bring them showing on the advertisings,
just print them anywhere between the news; an enclosed folder with 
advertisings can be thrown away without being really noticed;

a little analogy: a user can easily block 3rd party advertisings by 
blocking just these domains; for this it would not make any difference 
if it is sent plain or encrypted using TLS,
because this blockings are domain/host specific;
if the advertisings are done without 3rd party, then a user might block 
specifics URLs - this and the above steps can be done centrally at a 
proxy server;
but when the whole is only sent encrypted using TLS, anybody can only 
stop the advertisings from being loaded by himself/herself without 
breaking the
end-to-end encryption; a proxy server doesn't help to prevent this, 
except it does man-in-the-middle;

so now the question for you: do you really think, TLS costs you so much 
more that any way of reducing the whole hosting costs isn't it worth of 
doing TLS?

by the way:
can you please read this:
https://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon/
I want this to be a RFC

Thanks,
Walter

---

From: Glen <[email-masked]>
Date: Mon, 30 Mar 2015 18:53:26 +0000

Sending again.

On 2015/03/29 16:50, Glen wrote:
> Thanks for the replies.
> 
> 1. As far as I understand it (which is not very far), opportunistic encryption is neither "by default" (since it requires extra server-side configuration) nor secure (no MITM protection, etc.)
> 
> I'm okay with HTTP/2 without TLS, however (my opinion):
> 
> a) User agents MUST show a security warning before you submit data over HTTP (you could have a "remember this choice" option per-user and per-domain). As far as I know, this is not currently implemented in any browsers (I think if you submit to an HTTP domain from an HTTPS one, you may receive a warning). The main point is, it's more important that users know that they're on an INSECURE domain, than it is that they are on a SECURE one (by then it's too late).
> 
> b) All vendors should support it. If I decide that my site does not require encryption (f.e. it's a read-only website or a website that runs within a LAN [like a router page]), then I should not be forced to use it in order to run over HTTP/2. I think that Mozilla and Google probably have good intentions, but I don't think that they have made the right decision at all. We don't want to go back to the stage where every browser was doing its own thing, and causing massive headaches for developers and even end-users. There are ways (see above) to make the web more secure (by default) without forcing anything on anyone. It's kind of like smoking – it's bad for you, and we should warn against it, but at the end of the day every person reserves the right to do as they please (screw up their lungs, or submit their (possibly) private information over an insecure connection.
> 
> 2. Not being able to safely compress content seems like a big problem. Are there any (content) compression algorithms that are not susceptible to these vulnerabilities, or has there been any discussion regarding the development of a new algorithm to combat these issues? From what I know, compressing content can have a significant (positive) effect on performance, so it would be really unfortunate if this was no longer possible without exposing your website to various security exploits.
> 
> Glen.
> 
> On 2015/03/28 16:43, Glen wrote:
>> Hi,
>>

---

From: Dan Anderson <[email-masked]>
Date: Mon, 30 Mar 2015 15:33:49 -0500

>think of someone or company uses Internet for e-commerce; e.g. presenting
his products is public for anybody; this doesn't need to be presented in
TLS,

Is this still a valid assumption?

I might not particularly, initially, care about confidentiality.  But I
think I would still care about the integrity benefits (Am I talking to the
site I think I am talking to?, is there a man in the middle?, etc.)

I can't think of a case where I would not want this assurance.
And I can think of all sort of nefarious things to do to others when they
don't have this assurance.

So I am disappointed that we are not taking the opportunity to fix this.

Dan

On Mon, Mar 30, 2015 at 2:32 PM, Walter H. <[email-masked]>
wrote:

>> You're skipping the discussion about why price of the cert is not the
>> cost of running TLS.  There's admin overhead in renewing the cert for each
>> domain, there's network infrastructure overhead in providing each domain a
>> unique IP address (because you can't guarantee every client supports SNI,
>> much as we'd like to), and that additional network infrastructure cost
>> means hosting becomes more expensive.
>>
> that a server needs more cpu, memory and more other resources when sending
> content using TLS in comparison to just send them plain, this is true;
> also it is true, that you need someone who renews the certs; also that you
> need a unique IP address; but it is not impossible doing so, the available
> resources would be enough;
> even IP addresses;
> not really; or do you really think there is the need of something new that
> is the same as the old?
>
> here the example:
>
> think of someone or company uses Internet for e-commerce; e.g. presenting
> his products is public for anybody; this doesn't need to be presented in
> TLS,
> compareable to a bank; the presentation of all products of the bank - e.g.
> interest rates, common terms and conditions, ... - can be presented
> blocking just these domains; for this it would not make any difference if
> it is sent plain or encrypted using TLS,
> specifics URLs - this and the above steps can be done centrally at a proxy
> server;
> but when the whole is only sent encrypted using TLS, anybody can only stop
> the advertisings from being loaded by himself/herself without breaking the
> end-to-end encryption; a proxy server doesn't help to prevent this, except
> it does man-in-the-middle;
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 30 Mar 2015 20:53:05 +0000

------ Original Message ------
From: "Dan Anderson" <[email-masked]>
To: "Walter H." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 31/03/2015 9:33:49 a.m.
Subject: Re: 2 questions

>think I would still care about the integrity benefits (Am I talking to 
>the site I think I am talking to?, is there a man in the middle?, etc.)

so how do you get integrity benefits when there is a MitM?  Client 
certificates?  Good luck with that.

>I can't think of a case where I would not want this assurance.
I understand the desire for the assurance, and agree.  But it's just not 
there.

>And I can think of all sort of nefarious things to do to others when 
>they don't have this assurance.
>
I wonder what opportunity we have.  Moving to TLS everywhere does not do 
it.  Client certificates maybe.

I wonder how many people know what certs are in their trusted root 
store.  And keep an eye on it.

Adrien

>>>cost of running TLS.  There's admin overhead in renewing the cert for 
>>>each domain, there's network infrastructure overhead in providing 
>>>each domain a unique IP address (because you can't guarantee every 
>>>client supports SNI, much as we'd like to), and that additional 
>>>network infrastructure cost means hosting becomes more expensive.
>>sending content using TLS in comparison to just send them plain, this 
>>is true;
>>now think of the "next step", the website shows advertising for what 
>>the company gets money, that reduces the hosting costs;
>>now think of the people that do not want see the advertisings; with 
>>the newspaper it is easy to bring them showing on the advertisings,
>>if the advertisings are done without 3rd party, then a user might 
>>block specifics URLs - this and the above steps can be done centrally 
>>at a proxy server;
>>so now the question for you: do you really think, TLS costs you so 
>>much more that any way of reducing the whole hosting costs isn't it 
>>worth of doing TLS?
>>
>>by the way:

---

From: Xiaoyin Liu <[email-masked]>
Date: Mon, 30 Mar 2015 18:53:02 -0400

From: [email-masked]
To: [email-masked]; [email-masked]
CC: [email-masked]
Date: Mon, 30 Mar 2015 20:53:05 +0000
Subject: Re: 2 questions

>think of someone or company uses Internet for e-commerce; e.g. presenting his products is public for anybody; this doesn't need to be presented in TLS, 

I might not particularly, initially, care about confidentiality.  But I think I would still care about the integrity benefits (Am I talking to the site I think I am talking to?, is there a man in the middle?, etc.)
 
> so how do you get integrity benefits when there is a MitM?  Client certificates?  Good luck with that.
 Why are client certificates needed? Client certificates are for the servers to authenticate clients, but what Dan said was "am I talking to the site I think I am talking to". The assurance of integrity is provided by the normal TLS without client certs.
Best,Xiaoyin

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 31 Mar 2015 00:07:53 +0000

------ Original Message ------
From: "Xiaoyin Liu" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>; "Dan Anderson" 
<[email-masked]>; "Walter H." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 31/03/2015 11:53:02 a.m.
Subject: RE: 2 questions

>>I might not particularly, initially, care about confidentiality.  But 
>>I think I would still care about the integrity benefits (Am I talking 
>>to the site I think I am talking to?, is there a man in the middle?, 
>>etc.)
>
>Why are client certificates needed? Client certificates are for the 
>servers to authenticate clients, but what Dan said was "am I talking to 
>the site I think I am talking to". The assurance of integrity is 
>provided by the normal TLS without client certs.

no it's not.

With MitM all bets are off unless you use a client cert (which therefore 
the MitM cannot spoof in a way that will be trusted by the server).

Adrien

>Best,
>Xiaoyin

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Mar 2015 02:00:23 +0100

On 31/03/15 01:07, Adrien de Croy wrote:
> 
> With MitM all bets are off

Seems to me that claims of the prevalence of MitM are
somewhat exaggerated. The last study I recall of those
in the wild found about 0.41% of requests affected. [1]

So I think any argument of the form "don't do X to try
be more secure or private, since the prevalence of MitM
implies X is pointless" ought be considered bogus at the
~99.5% confidence level, at least according to [1].

I also note that [1] found that those few unfortunate
victims of the MitM attack are terribly served between UA
and MitM as they saw a bunch of short RSA keys (with no PFS)
used. And one would expect that to be the case as a supposedly
"benevolent" MitM will generally decide to prefer crap
security so that their always-negative performance impact
is minimised. (Seeing commensurate security on both sides
of the MitM might even be considered as indicative that
the MitM is more likely malicious and not benevolent? I've
not seen that measurement so far as I recall, so I'm just
speculating there.)

Are there better studies out there with better figures?

If not and 0.41% of crappy security that you get with real
deployments of MitM's is the norm, then we ought be more than
ignoring the MitM deployments - we all (and browsers!) should
be yelling loudly about 'em as we trip over their victims.

Cheers,
S.

[1] http://arxiv.org/abs/1407.7146

---

From: "Walter H." <[email-masked]>
Date: Tue, 31 Mar 2015 07:30:14 +0200

> Is this still a valid assumption?

Yes, why see below ...

> site I think I am talking to?, is there a man in the middle?, etc.)

just look at this screens-shot
http://imgbin.org/images/23055.png
(this was made at http://www.zalando.at/ - I'm Austrian and this is a
internet shop, but ... - my proxy blocks advertising in a very agressive
way)

> I can't think of a case where I would not want this assurance.

do you still think TLS would give you the "assurance", everything in the
browser windows comes from the host shown in the address bar, even when
its the kidding green bar?

> don't have this assurance.

really?

> So I am disappointed that we are not taking the opportunity to fix this.

Yes, fix this by only allowing relative URLs inside https-sites ..., or in
other words, restricting access to ONLY the host shown in the address bar,
when presenting the site with TLS in the browser windows ...

Much luck ;-)

by the way:

Thanks,
Walter

p.s. guess why the garbage collection isn't escorted by the police,
but the transport of money is ...

---

From: "Walter H." <[email-masked]>
Date: Tue, 31 Mar 2015 11:12:44 +0200

On Tue, March 31, 2015 11:02, Amos Jeffries wrote:

> Er, I feel obliged to say "please upgrade" to this.
have you understood the real message of this?
> I realise it was taken several years ago,
and now its even worse ..., nearly no site without embedding
advertising/tracking parts from 3rd party ...

Walter

---

From: "Eric J. Bowman" <[email-masked]>
Date: Tue, 31 Mar 2015 03:37:40 -0600

> 1. What were the reasons for HTTP/2 not requiring TLS?

Nutshell answer to Glen's original question, is consensus wasn't
reached in this WG for requiring TLS in HTTP/2.

> are there other technical reasons?

This entire thread is a discussion of why consensus wasn't reached,
within the framing of your original post, but that's still the answer to
your original question. What follows from me on the topic, is outside
that framework, or I wouldn't post. Because sometimes, technical and
social/political overlap, and that's where we are with this.

> have thought that now would be the right time to move in that

My personal opinion, as a content publisher, is that I don't want to
make promises I can't keep. Like "securing" or even privatizing your
visit to my website, if I don't even know who you are or where you come
from. Especially if my URLs leak your private info in REFERER...

My analogy is a speakeasy. If you don't want folks knowing you come in
and out the front door, you'd better have a password for the back door
(Copacabana shot in "Goodfellas" comes to mind), in which case I need
to know who you are. Ubiquitous HTTPS requires me to give everyone that
password, so philosophically speaking, what's the point of requiring it?

I'm +1 on the OpSec draft because of this. I don't care how much you
tip, you're not coming in my back door unless I know who you are. In
which case, you'll be taken care of to the best of my abilities. Which
includes not leaking your personal data to advertisers via URLs in the
REFERER header, which is a prominent Web problem ubiquitous HTTPS, and
even OpSec, don't begin to solve.

Ultimately, I don't believe in a "secure by default" vision of the Web.
What I'd like is to be able to verify to my site visitors, that their
viewed content hasn't been altered. By ad-injection or whatever, if
that's affecting a login page, I don't want them to log in from that
page. Because whether it's OpSec or ubiquitous HTTPS, my inability to
detect content alteration as a publisher, is my problem. For which I
don't see any solution proposed, so my +1 to OpSec is "lesser of two
evils".

IMHO, the closest we've come in HTTP was the now-deprecated Content-
Md5 header. It didn't play nice with Range requests. In retrospect,
instead of deprecating, we probably should have incorporated some means
to disable range requests when Content-Md5 was in play. Plus made it
registerable through IANA, i.e. now we'd have a Content-Sha256 header
or somesuch.

Just give me something where, from the server side, I can warn my
valued site visitors that something fishy's afoot between us. Instead
of promising them everything will be fine, by virtue of having 
browser-vendor-and-Google-approved HTTPS URLs which don't address the
main thing I could be doing wrong... But I guess I'm exonerated, if
everyone else buys into this flawed system, so What, me worry?

> want to run their website without it?

More onerous is Google tying HTTPS usage to "PageRank" for no reason
that makes any sense, other than throwing their weight around. Does
nothing for the hugely prevalent problem of poor URI allocation-scheme
design, which makes me wonder if ubiquitous HTTPS isn't counter-
productive to actually solving a privacy problem it only purports to
band-aid. The larger issue to me are all the sites HTTPS doesn't "fix"
because from where I sit, those are the majority of the sites we access
which can actually hurt us, IOW not browsing the local newspaper.

Did I make a medical reference? It's because HTTPS didn't stop the
personal health information of every U.S. citizen who entered it into
healthcare.gov from being transmitted to every partner corporation
involved in that website. We're supposed to trust that this data won't
be used because that would be against the law, but wouldn't it have
been better if the Identification of Resources constraint got the same
sort of press EFF's drummed up for ubiquitous HTTPS without, IMO, quite
understanding the problem?

My painful analogy, is ubiquitous HTTPS only even tries to solve the
problem of keeping the horse from bolting through the open barn doors.
Wouldn't it be better to approach the problem from the perspective of
closing the barn doors, if the intention is to keep horses inside of it?

;-)

Sorry for the tl;dr to arrive at that point, but "it is what it is".

-Eric

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 01 Apr 2015 00:21:24 +1300

> have you understood the real message of this?

I hope so. There are many interpretations though and you did not post it
in reply to a statement by me.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 31 Mar 2015 13:47:24 +0200

Hi Amos,

> in reply to a statement by me.

So you're lucky because for now, all of the messages I've read from Mr
"H." are quite confusing to me and talk about things totally unrelated
to TLS (eg: advertising etc) to the point that I'm now considering this
thread as rant or pollution. At least I don't understand the intent nor
what improvement is suggested here :-/

Best regards,
Willy

---

From: "Walter H." <[email-masked]>
Date: Tue, 31 Mar 2015 20:21:17 +0200

On 31.03.2015 13:21, Amos Jeffries wrote:
> I hope so.
I don't think so ...
> There are many interpretations though and you did not post it
No, there is definitely only one interpretation, you got a wrong one ... 
your "please update" is totally nonsense in this context;

as the garbage collection isn't escorted by police, there is no need of 
TLS everywhere;
just as much as really needed;

this screenshot  shows totally different content as supposed to be shown 
in connection with the URL presented in the address bar of the browser;
the same it would be with TLS.
but exactly this was the reason for  Dan Anderson

he wrote: "But I think I would still care about the integrity benefits 
(Am I talking to the site I think I am talking to?, is there a man in 
the middle?, etc.)
I can't think of a case where I would not want this assurance."

this screen shot shows the counter evidence of his requirements of 
comprehensive TLS;

Walter

---

From: "Walter H." <[email-masked]>
Date: Tue, 31 Mar 2015 20:27:05 +0200

On 31.03.2015 13:47, Willy Tarreau wrote:
>
> ..., all of the messages I've read from Mr
> thread as rant or pollution.
then I don't need to write anything to clarify ...
>   At least I don't understand the intent nor
your problem ...

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 31 Mar 2015 20:28:22 +0200

> >what improvement is suggested here :-/

Given that you're saying yourself that others don't understand, I'm not
sure I'm the common point between them...

Willy

---

From: Maxthon Chan <[email-masked]>
Date: Wed, 01 Apr 2015 02:37:32 +0800

Seem relevant, so I am just throwing it out here:

How about making TLS mandatory, and the URL scheme “http:” and “https:” only determines whether the certificate is checked or not?

Also since HTTP/1.1 have a protocol upgrade mechanism, how about using that as a stepstone of HTTP/2 (that is, all sessions is initiated as HTTP/1.1, and a HTTP/2-capable server tells the client it can start using HTTP/2 features in the resulting HTTP/1.1 header and further communications is HTTP/2) so HTTP/2 will not depend on TLS NPN feature (that is, HTTP/1.1 protocol upgrade is used as a makeshift NPN)

> On Apr 1, 2015, at 02:28, Willy Tarreau <[email-masked]> wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 31 Mar 2015 11:49:08 -0700

Using https is a statement that you'd rather have no connectivity than
nonencrypted nonauthenticated communication.
If you use http you're not saying that, and you're opening yourself up for
all kinds of nastiness, e.g. you can force a downgrade to plaintext  (port
80) by blocking port 443 for such urls.

-=R

On Tue, Mar 31, 2015 at 11:37 AM, Maxthon Chan <[email-masked]> wrote:

> How about making TLS mandatory, and the URL scheme “http:” and “https:”
> only determines whether the certificate is checked or not?
>
> Also since HTTP/1.1 have a protocol upgrade mechanism, how about using
> that as a stepstone of HTTP/2 (that is, all sessions is initiated as
> HTTP/1.1, and a HTTP/2-capable server tells the client it can start using
> HTTP/2 features in the resulting HTTP/1.1 header and further communications
> is HTTP/2) so HTTP/2 will not depend on TLS NPN feature (that is, HTTP/1.1
> protocol upgrade is used as a makeshift NPN)
>

---

From: "Walter H." <[email-masked]>
Date: Tue, 31 Mar 2015 20:55:20 +0200

> How about making TLS mandatory, and the URL scheme “http:” and “https:” only determines whether the certificate is checked or not?
what should be the benefit of this behaviour?
  please think of the user/client side, not the server side when 
answering this;
> Also since HTTP/1.1 have a protocol upgrade mechanism, how about using that as a stepstone of HTTP/2 (that is, all sessions is initiated as HTTP/1.1, and a HTTP/2-capable server tells the client it can start using HTTP/2 features in the resulting HTTP/1.1 header and further communications is HTTP/2)
this is the only way; and the client must be able to refuse this and go 
further with HTTP/1.1 ...; and a client that is not capable of using 
HTTP/2.0 will hopefully ignore this ...

Greetings,
Walter

---

From: Maxthon Chan <[email-masked]>
Date: Wed, 01 Apr 2015 02:58:31 +0800

I mean TLS is mandatory and all communications happens over port 443. However without authentication any form of encryption is pointless, so the only difference between http and https here in my suggestion is whether the certificate is authenticated or not, but keeping TLS intact would allow other protocol features to be used, like NPN.

Or we need some other form of protocol negotiation that is compatible with HTTP/1.1 or we run the risk of breaking Internet. My suggestion of this “other form of negotiation” is to use the HTTP/1.1 protocol upgrade or custom header mechanism to negotiate HTTP/2 operation over the first HTTP/1.1 request/response, since the main point of stageful differential requesting and responding does make a benefit on the first request.

> On Apr 1, 2015, at 02:49, Roberto Peon <[email-masked]> wrote:
> 
> 
> Using https is a statement that you'd rather have no connectivity than nonencrypted nonauthenticated communication.
> If you use http you're not saying that, and you're opening yourself up for all kinds of nastiness, e.g. you can force a downgrade to plaintext  (port 80) by blocking port 443 for such urls.
> 
> 
> -=R
> 
> On Tue, Mar 31, 2015 at 11:37 AM, Maxthon Chan <[email-masked] <mailto:[email-masked]>> wrote:
> > On Apr 1, 2015, at 02:28, Willy Tarreau <[email-masked] <mailto:[email-masked]>> wrote:
> >

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 31 Mar 2015 21:06:23 +0200

On Wed, Apr 01, 2015 at 02:58:31AM +0800, Maxthon Chan wrote:
> I mean TLS is mandatory and all communications happens over port 443. However
> without authentication any form of encryption is pointless, so the only
> difference between http and https here in my suggestion is whether the
> certificate is authenticated or not, but keeping TLS intact would allow other
> protocol features to be used, like NPN.

All of this has been discussed to death 2 years ago already and many cases
were provided about a number of situations where this would cause more harm
than good. IoT devices were one example where you don't want to spend CPU
cycles encrypting. Being able to use the existing infrastructure as it is
is another important aspect. Forcing everyone to mix secure and non-secure
traffic on the same port doesn't necessarily come without any security/
confidentiality impact. And in my personal opinion, encrypting without
authenticating just to let people *feel* they're safe is not a good idea,
though I know that many don't share my view on this. Quite frankly, when
you want an admin to switch his internal servers to TLS, there's no better
solution than providing him with a network capture showing all his activities
in clear text. Really.

Regards,
Willy

---

From: Maxthon Chan <[email-masked]>
Date: Wed, 01 Apr 2015 03:11:55 +0800

Sorry for my not being aware of that as I am new to this list.

Any form of HTTP/1.1-based HTTP/2 protocol negotiation must allow a client to ignore hints of HTTP/2 availability and keep speaking HTTP/1.1.

How about this two-request protocol negotiation:

The first request is normal HTTP/1.1, and the server announces its HTTP/2 availability by including the string “HTTP/2” at the end of its Server header. This hint will be blissfully ignored by all older browsers that does not support HTTP/2, but it will be picked up by browsers supporting it.

The second request starts off with a HTTP/1.1 protocol upgrade to HTTP/2 and the server responds to the HTTP/1.1 protocol upgrade request with a HTTP/2 response, which will break non-HTTP/2 browsers (which is intentional here)

The browser can cache the HTTP/2 availability and all further communication, even a new session, can start with a HTTP/1.1 protocol upgrade and then full-blown HTTP/2 traffic.

> On Apr 1, 2015, at 02:55, Walter H. <[email-masked]> wrote:
> 
> please think of the user/client side, not the server side when answering this;
> this is the only way; and the client must be able to refuse this and go further with HTTP/1.1 ...; and a client that is not capable of using HTTP/2.0 will hopefully ignore this ...
> 
> Greetings,
> Walter
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 31 Mar 2015 20:49:02 +0000

It's great people are doing work in that area and thanks for posting 
that link.

However I don't know it the conclusion can follow that it's completely 
bogus to consider the impact of MitM at all and if not now then for all 
time (I know this wasn't your exact claim).  Even the study remarked 
they got double the result of a previous study.  That could be down to 
better testing, and/or growth in use of MitM in the intervening time 
period.

Without the source to their flash app, it's hard to tell whether there 
were any issues with the validity of the testing.  Also it's hard to 
know from a google adwords campaign whether you are getting skewed 
results for instance where there are proxies configured on a whitelist 
basis (there are many of these) that prevent access to the test site.  
So I believe the number reported will be on the low side.  How much 
lower than real is for anyone to guess.  As to where to draw the line 
where we consider something to be insignificant or not, is 1% 
insignificant?  2%?

I know the use of MitM is growing (at least in our customer-base).  Sure 
some may be abandoning it, but I'm not really seeing any evidence of 
that.  So maybe in a couple years it could be much higher than 0.41%, 
and for corporate users I'm certain it is much higher.  I don't see the 
same incentives for ISPs to deploy MitM and there are bigger issues like 
convincing people to install root certs, which corporate environments 
don't suffer the same from.

So whilst very interesting, I don't know if we can really draw too much 
from this study alone.  It would be very interesting to see the results 
redone at say yearly intervals.

Adrien

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>; "Xiaoyin Liu" 
<[email-masked]>; "Dan Anderson" <[email-masked]>; "Walter 
H." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 31/03/2015 2:00:23 p.m.
Subject: Re: 2 questions

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Mar 2015 22:06:14 +0100

Hiya,

> redone at say yearly intervals.

Yep, longitudinal studies are valuable in things like this. I'd
be surprised if there wasn't being done by someone right now tbh.
Meanwhile, the take-away is clearly that MitM deployment is one of
those things that's (ab:-)used about 0.41% of the time and should
be treated as such and that claims to the contrary are anecdotal.

S.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 1 Apr 2015 07:16:33 +1000

On 1 April 2015 at 05:11, Maxthon Chan <[email-masked]> wrote:

> ​
> ​
> ​
> ​

​The archives are at https://lists.w3.org/Archives/Public/ietf-http-wg/

A lot of ground has been covered there.​

​
>
> ​​
> Any form of HTTP/1.1-based HTTP/2 protocol negotiation must allow a client
> to ignore hints of HTTP/2 availability and keep speaking HTTP/1.1.
>
> The first request is normal HTTP/1.1, and the server announces its HTTP/2
> availability by including the string “HTTP/2” at the end of its Server
> header. This hint will be blissfully ignored by all older browsers that
> does not support HTTP/2, but it will be picked up by browsers supporting it.
>
> The second request starts off with a HTTP/1.1 protocol upgrade to HTTP/2
> and the server responds to the HTTP/1.1 protocol upgrade request with a
> HTTP/2 response, which will break non-HTTP/2 browsers (which is intentional
> here)
>
> The browser can cache the HTTP/2 availability and all further
> communication, even a new session, can start with a HTTP/1.1 protocol
> upgrade and then full-blown HTTP/2 traffic.
>
>
​How is that any better than the client just sending Upgrade:h2c (or h2)
with the first request?​

---

From: Maxthon Chan <[email-masked]>
Date: Wed, 01 Apr 2015 05:40:41 +0800

This will cause a non-conformance server to freak out and start a reload. By allowing a server to announce its HTTP/2 availability a reconnect/reload can be avoided.

> On Apr 1, 2015, at 05:16, Matthew Kerwin <[email-masked]> wrote:
> 
> On 1 April 2015 at 05:11, Maxthon Chan <[email-masked] <mailto:[email-masked]>> wrote:
> Sorry for my not being aware of that as I am new to this list.​​
> ​​
> 
> ​The archives are at https://lists.w3.org/Archives/Public/ietf-http-wg/ <https://lists.w3.org/Archives/Public/ietf-http-wg/>
> 
> ​​Any form of HTTP/1.1-based HTTP/2 protocol negotiation must allow a client to ignore hints of HTTP/2 availability and keep speaking HTTP/1.1.
> 
> ​How is that any better than the client just sending Upgrade:h2c (or h2) with the first request?​
> 
> 
> -- 
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/ <http://matthew.kerwin.net.au/>

---

From: Maxthon Chan <[email-masked]>
Date: Wed, 01 Apr 2015 05:48:41 +0800

Let’s just say that a certain ISP (or rather, ISPs backed by government agency) in a certain country MITM 100% of all kinds of plaintext traffic, and they disrupt all kinds of encrypted traffic. If HTTP/2 cannot survive such MITM this will effectively disconnect a whole country from the Web.

Let’s just say this will make that certain government agency very happy, since they no longer need to censor anything, as the Web censored itself.

> On Mar 31, 2015, at 09:00, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 31 Mar 2015 21:49:44 +0000

The fact that one major Internet company has a bad habit of returning 400 when they see Upgrade: Anything-other-than-WebSockets on a request.

But that’s a server bug, and we shouldn’t mandate protocol behavior to work around a single implementation’s bug – all the necessary pieces are already in HTTP/1.1.  You don’t need to abuse the Host header – the Upgrade header in a response is already defined to mean exactly that.  It’s a hint of protocols the server would be willing to upgrade to, if the client supports it.  A cautious client can wait for the server to advertise willingness to upgrade, then actually perform the upgrade on the next request.  (And presumably cache the fact for future savings of the RTT.)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Matthew Kerwin
Sent: Tuesday, March 31, 2015 2:17 PM
To: Maxthon Chan
Cc: Walter H.; [email-masked]
Subject: Re: comprehensive TLS is not the solution, it's a bug ... (was 2 questions)

On 1 April 2015 at 05:11, Maxthon Chan <[email-masked]<mailto:[email-masked]>> wrote:
Sorry for my not being aware of that as I am new to this list.
​
​

​
​

​

​​

---

From: ChanMaxthon <[email-masked]>
Date: Wed, 01 Apr 2015 06:03:51 +0800

Maybe I missed out that and abused Server header, but the gist is still there: in the first request if cached information is not available, which is plain HTTP/1.1, the server advertises its availability of HTTP/2 capabilities; and on the second request or if a previous successful HTTP/2 session is still in cache HTTP/2 traffic is started by sending a HTTP/1.1 Upgrade request which is responded with a HTTP/2 response.

This non-symmetric behavior would throw off some of that MITM attempt (as an unwanted HTTP/1.1 response to this particular request is ignored.)

Sent from my iPhone

> On Apr 1, 2015, at 05:49, Mike Bishop <[email-masked]> wrote:
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 31 Mar 2015 22:21:13 +0000

--------

>be treated as such and that claims to the contrary are anecdotal.

Sorry for being the "one sheep which looks like it is black on at least
one side" guy:

As interesting as that study was, its results does not support your
rather flippant and arrogant marginalization of MitM as an issue.

What the study documents is that MitM, in two short periods of last
year was *detected* in about 0.41% of a particular small traffic
sample.

The main problem is that we have absolutely *no* idea what the
studys global probability of MitM detection was, which dumps us
right into the deep end of the type I/II error pool.  (ie: no mobiles
because they lack Flash, only webpages serving certain AdWords etc.)

The secondary problem is that the traffic sample is in no way
representative of the total traffic in the internet. (ie: Adwords
again and only return traffic to a particular destination.)

The study is therefore at best an "existence proof" study and at
most we can with *some* confidence say that the amount of MitM is
unlikely to be significantly *less* than 0.41% on a global scale.

But much more importantly, the study says absolutely nothing about
how important to society the 0.41% or the corresponding undetected
shadow number might be.

First, rememeber that just because it is a small number doesn't
mean it is unimportant:  The homicide rate in USA is 4.7 per 100,000
population, two orders of magnitude below 0.41%, but no sane person
thinks we can disband the police homicide units because it is a
small number "and claims to the contrary are anecdotal".

In particular it is worth pointing out that the studys methods would
entirely fail to detect legal and court-approved MitM as part of
criminal investigations, since they usually only MitM particular
destinations and often with certs which looks surprisingly valid.

Privacy is not a technical problem with a technical solution,
it is a political problem, and must be solved with political means.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Mar 2015 23:35:12 +0100

Hi,

> Sorry for being the "one sheep which looks like it is black on at least

Actually the reason I posted about it was because this list seems
to have a lot of anecdotes on this topic and little or no data.

> rather flippant and arrogant marginalization of MitM as an issue.

Flippant, that's quite possible:-)

Arrogant? Really? Apologies if I was, but that's surprising.

Anyway, feel free to produce better peer-reviewed data. I'm sure
the state of the art in this space is evolving rapidly, and it's
probably fair to say that it's still somewhat early days in
Internet measurement in general (or when we look back in a few
years, I figure we'll think that).

But studies like these are still (for me anyway) far more worth
paying attention to than yet more anecdotes and prognostications.

S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 31 Mar 2015 23:07:01 +0000

--------

>paying attention to than yet more anecdotes and prognostications.

I fully agree as long as their results are interpreted carefully
and precisely.

However this study only tells us that MitM is unlikely to be less
than 0.41%, we have *no* information about any upper limit.

But I find your continued belittlement of "anecdotes and
prognostications" problematic even without this study.

I know of no usable measurements of how often courts allow or mandate
MitM as part of criminal investigations.

Yet, we know that it happens:  Occasionally we spot bogo-certs
and here and there tidbits emerge from courthouses.

If we (try to) make MitM impossible for law-enforcement, courts
will approve use of more drastic and damaging means and measures,
and legislators will neuter "impediments to law-enforcement" if
necessary, no matter how ill advised that may be.

Remember how much privacy we lost after 2001 ?  Today we're probably
just a single convenient crisis, real or manufactured, from key
escrow becoming the law of the policestate.

Blindly pushing the "HTTPS anywhere" agenda through to completion
is at best a distraction and at worst it risks doing more damage
our privacy in the long run.

The only real solution is to make make privacy a protected human right.

Poul-Henning

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Apr 2015 00:15:23 +0100

> The only real solution is to make make privacy a protected human right.

It is in theory, says the UDHR. [1] But I think we've wandered far
from this list's remit. Happy to continue off list though, or you
could sign up to the (quite new) [email-masked] list [2] that was
previously hosted at. [3]  ([3] was just migrated to [2] yesterday.)

S.

[1] http://www.un.org/en/documents/udhr/index.shtml/index.shtml#a12
[2] https://irtf.org/mailman/listinfo/hrpc
[3] https://lists.ghserv.net/mailman/listinfo/hrpc

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 01 Apr 2015 14:30:30 +1300

> This will cause a non-conformance server to freak out and start a reload. By allowing a server to announce its HTTP/2 availability a reconnect/reload can be avoided.

Server advertising HTTP/2 support will cause the equivalent
non-conforming clients to "freak out".

Upgrade has a 10 year old RFC to point the few (if any) non-compliant
people at. And the default behaviour for non-implementers (ignoring it
completely is compliant with HTTP) will only cause fallback to HTTP/1.1
with zero cost.

Adding a new header for server adverts (assumign you done emit Upgrade
from server) means another 5-10 years of software upgrading
HTTP/1.x-only things before HTTP/2 has a chance to start transition.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 01 Apr 2015 14:41:03 +1300

> This non-symmetric behavior would throw off some of that MITM attempt (as an unwanted HTTP/1.1 response to this particular request is ignored.)

No it won't. Google tried that style of upgrade with QUIC.

Which forced me to do this a short while ago:
<http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13193.patch>

Note that the change was done to fix *security vulnerabilities*
affecting even regular benevolent existing HTTP proxies. These occur
regardless of how secure QUIC itself might be. Alt-Svc draft is
struggling with the same class of issues.

Any proxy (MITM or not) which is erasing the client signals (Upgrade or
HTTP2-Settings headers) is just as likely to erase server signals with
more actual need to do so.

Amos

---

From: ChanMaxthon <[email-masked]>
Date: Wed, 01 Apr 2015 11:51:08 +0800

Just wondering, have you guys heard of Let's Encrypt project led by EFF and backed by a few major companies including Cisco, providing SSL certificates with a valid trust chain to everybody for free? If that project is successful we may be able to treat any plaintext traffic as deprecated - just deprecate plaintext HTTP/2 upon release as well as plain HTTP/1.1

Sent from my iPhone

> On Apr 1, 2015, at 07:15, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 01 Apr 2015 17:45:18 +1300

> ~99.5% confidence level, at least according to [1].

You seem to be seeing different claims.

I, Adrien, Willy, PHK have been stating that MITM exist already in TLS
*and are increasing*. The research you point out supports that
statement, they saw TLS MITM rates double within just last year. With
growth of malware instances almost tripling.

The call we are making is to avoid doing things which encourage that
growth to increase any further. Some cases of your "X" are things which
activly force ISP / CDN people to become MITM against their will. Those
"improvements" are actively harming both privacy and security for
everybody in the guise of improving only-security for only-some of
Internet participants. "First, do no harm" comes to mind.

Amos