Slashdot Mirror

← Back to Stories (view on slashdot.org)

HTTP 2.0 Will Be a Binary Protocol

Posted by timothy on from the cram-your-stuff-in-this-box dept.

earlzdotnet writes "A working copy of the HTTP 2.0 spec has been released. Unlike previous versions of the HTTP protocol, this version will be a binary format, for better or worse. However, this protocol is also completely optional: 'This document is an alternative to, but does not obsolete the HTTP/1.1 message format or protocol. HTTP's existing semantics remain unchanged.'"

3 of 566 comments (clear)

  1. Re:Makes sense by redalien · · Score: 5, Informative

    https://en.wikipedia.org/wiki/CRIME_(security_exploit)

  2. Rationale by hebcal · · Score: 5, Informative

    The rationale for http-2.0 is available in the http-bis charter. Quoting the spec:...

    As part of the HTTP/2.0 work, the following issues are explicitly called out for consideration:

    • * A negotiation mechanism that is capable of not only choosing between HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other transports (for example).
    • * Header compression (which may encompass header encoding or tokenisation)
    • * Server push (which may encompass pull or other techniques)

    It is expected that HTTP/2.0 will:

    • * Substantially and measurably improve end-user perceived latency in most cases, over HTTP/1.1 using TCP.
    • * Address the "head of line blocking" problem in HTTP.
    • * Not require multiple connections to a server to enable parallelism, thus improving its use of TCP, especially regarding congestion control.
    • * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields.
    • * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2).
    • * Clearly identify any new extensibility points and policy for their appropriate use.
  3. Re:Makes sense by Anonymous Coward · · Score: 5, Informative

    No, the parent is right, and this weakness has been demonstrated in recent HTTPS attacks like BEAST and CRIME.

    It works like this. You visit a site that has malicious JavaScript which sends a HTTPS request to some site (like your bank). This request will include whatever known plain-text that the JavaScript wants to send, *plus* any cookies you have stored for the target site, possibly including authentication cookies. If the plain text happens to match part of that authentication cookie, then the compressed headers will be smaller than if they if they don't match. If the attacker can monitor this encrypted traffic and see the sizes of the packets, then they can systematically select the known plaintext to slowly learn the value of the authentication cookie.

    This can be done today in about half an hour. And the attack setup is feasible - consider a public WiFi access point that requires you to keep a frame open in order to use their WiFi. This gives them both the MITM and JavaScript access needed to perform this attack.

    Sorry for posting as AC - slashdot logged me out and I have a meeting in 5 minutes.