heads in the _security_ sand was: fixing TLS vulnerabilities with h2 was: ezflate: proposal to reinstitute deflate header compression

I think relying on h2 to fix security vulnerabilities is (to steal Peter's analog) akin to "burying our heads in the sand."

Sure, we may have "fixed" CRIME with HPACK, but what about BREACH? And what about the next vulnerability?

For exmple, how do I know that my bank isn't vulnerable to BREACH?
- did the client software send 'A-E: identity'?
- did the server disable response body compression completely?
- did the application separate secret data from echo'd user input? is there echo'd user input?

Perhaps we could add a third icon to the left of the url line (i.e. left of the cert valid and trusted proxy icons) to indicate the response is BREACH-free :)

-keith


On 04 June 2014 10:51 gregw@intalio.com wrote:
> ... the transport protocol should not need to tie itself in knots trying to make up for the deficiencies of the secure channel of choice on the internet.
>
> Currently I've seen at least 3 security inspired mechanism in h2 that I don't think belong in the transport protocol.
> Firstly there is data frame padding, complete with scary text about how you must use this feature if you wish to be secure - But don't even think of trying to use it unless you are a super security expert.
>
> We then have hpack encoding strategies that must pick the right style of encoding depending on the security nature of the meta data.  Easy for cookies, but not much else.
>
> While not in the spec, I have seen a hpack implementation that is using a constant time string equals function, so it does not leak timing information on inequality failure!
> These are all at the discretion of the implementation and thus I do not understand how they move security forward in any general way and users will not know if they can trust https2 or not. Will it really only be safe to use my online banking if I know both ends are using constant time equals comparisons?   How will the users know that their bank server is generating safe padding? Will the browser location bar contain a bunch of little icons for constant time equals, safe padding generation etc.
>
> I do understand that something has to be done to fix the deficiencies of TLS.  I just don't see why that is the responsibility of the h2 protocol and the detailed implementations to do so.     Not every (or any) h2 implementation is going to be able to warrant that it does not leak some kind of information about it's security related content.  Avoiding compressing cookies is OK, but I just don't know what to do with the other mechanisms and nor will many many http2 implementers.
>
> ...
This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Friday, 20 June 2014 17:47:33 UTC