- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Sat, 28 Mar 2015 21:36:43 +0000
- To: Glen <glen.84@gmail.com>
- Cc: ietf-http-wg@w3.org
> On 28 Mar 2015, at 14:43, Glen <glen.84@gmail.com> wrote: > > 1. What were the reasons for HTTP/2 not requiring TLS? 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) and still maintain security? 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
Received on Saturday, 28 March 2015 21:37:12 UTC