errata logo graphic

Found 7 records.

Status: Verified (3)

RFC6455, "The WebSocket Protocol", December 2011

Source of RFC: hybi (app)

Errata ID: 3150

Status: Verified
Type: Technical

Reported By: Robert Munyer
Date Reported: 2012-03-07
Verifier Name: Peter Saint-Andre
Date Verified: 2012-03-22

Section 4.1 says:

AQIDBAUGBwgJCgsMDQ4PEC==

It should say:

AQIDBAUGBwgJCgsMDQ4PEA==

Notes:

The "test vector" for Sec-WebSocket-Key encoding, provided in RFC 6455 section 4.1, is wrong. It was processed by a base 64 encoder that was "improperly implemented" as mentioned in RFC 4648 section 3.5. Pad bits were not set to zero, which is a "MUST" requirement in RFC 4648, and was also required by many other RFCs, going back to RFC 989 in the 1980s. In the string "AQIDBAUGBwgJCgsMDQ4PEC==", the final C should be changed to A.

In a Sec-WebSocket-Key header sent by a properly implemented client, the last letter will always be A, Q, g or w.


Errata ID: 3433

Status: Verified
Type: Technical

Reported By: Eric Lawrence
Date Reported: 2012-12-20
Verifier Name: Barry Leiba
Date Verified: 2012-12-22

Section 11.3.2 says:

However, the |Sec-WebSocket-Extensions| header field MUST NOT appear
more than once in an HTTP response.

It should say:

The |Sec-WebSocket-Extensions| header field MAY appear multiple 
times in an HTTP response (which is logically the same as a single
|Sec-WebSocket-Extensions| header field that contains all values).

Notes:

Section 4.2.2 Step 5 subpart 6 (top of page 25) clearly explains that this header field may appear multiple times in the server's response: "If multiple extensions are to be used, they can all be listed in a single |Sec-WebSocket-Extensions| header field or split between multiple instances of the |Sec-WebSocket-Extensions| header field. This completes the server's handshake..."


Errata ID: 3473

Status: Verified
Type: Editorial

Reported By: Adam Rice
Date Reported: 2013-01-31
Verifier Name: Barry Leiba
Date Verified: 2013-02-18

Section 4.1 says:

   2.  If the client already has a WebSocket connection to the remote
       host (IP address) identified by /host/ and port /port/ pair, even
       if the remote host is known by another name, the client MUST wait
       until that connection has been established or for that connection
       to have failed.  There MUST be no more than one connection in a
       CONNECTING state.  If multiple connections to the same IP address
       are attempted simultaneously, the client MUST serialize them so
       that there is no more than one connection at a time running
       through the following steps.

It should say:

   2.  If the client already has a WebSocket connection to the same IP
       address and port pair, even if the remote host is known by another
       name, the client MUST wait until that connection has been established
       or for that connection to have failed.  There MUST be no more than
       one connection in the CONNECTING state for any IP address and port
       pair.  If multiple connections to the same IP address and port pair
       are attempted simultaneously, the client MUST serialize them so that
       there is no more than one connection at a time running through the
       following steps.

Notes:

The original wording makes it ambiguous whether distinct ports on the same host are considered distinct for throttling purposes. The first sentence implies that the throttling should be applied per (host,port) pair, whereas the final sentence implies it is only based on IP address.

Implementations of both interpretations appear to exist in the wild.

I propose disambiguating in favour of the (host,port) interpretation, because the host-only interpretation allows for a potential denial-of-service attack targeted against hosts which drop packets to unused ports.

For example, an attacker from a different origin can create several hundred WebSockets to "wss://google.com:81/". Each one will attempt to connect in serial, and take tens of seconds to time out.

If the user then attempts to use an application which legitimately uses a WebSocket to "wss://google.com:443/", then due to the throttling to google.com it will not be able to connect until all of the attacker's connections have timed out.

The user will perceive that the legitimate application is malfunctioning, since there is no visible sign that they are being attacked. From the server end, the attack is only apparent in the firewall logs. The actual rate of SYN packets dropped will be small and unlikely to trigger an alert.

On the other hand, with the (host,port) interpretation, connections to google.com:81 do not block connections to google.com:443, and this attack is completely ineffective.

=== Verifier Notes ===

The subsequent paragraph already indicates what must be done in the case where the IP address cannot be determined, so this change should not create any difficulties in the case where the connection is tunnelled via an HTTP(S) or SOCKS5 proxy.

A separate concern has been raised that this section creates problems for WebSocket proxies and non-browser clients. That issue cannot be handled without changing the meaning of the text, so it would have to be dealt with in a document update.


Status: Held for Document Update (2)

RFC6455, "The WebSocket Protocol", December 2011

Source of RFC: hybi (app)

Errata ID: 3227

Status: Held for Document Update
Type: Technical

Reported By: Alexey Melnikov
Date Reported: 2012-05-16
Held for Document Update by: Barry Leiba

Section 7.4.1 says:

   1011

      1011 indicates that a server is terminating the connection because
      it encountered an unexpected condition that prevented it from
      fulfilling the request.

It should say:

   1011

      1011 indicates that a remote endpoint is terminating the connection
      because it encountered an unexpected condition that prevented it from
      fulfilling the request.

Notes:

As per the discussion in the WG (See <http://www.ietf.org/mail-archive/web/hybi/current/msg09628.html>) the meaning of this error close code should be extended to cover clients as well. As the Designated Expert for the WebSocket close code registry I've approved the corresponding change to the IANA registry.

This should be "hold for update" for rfc6455bis.


Errata ID: 3432

Status: Held for Document Update
Type: Technical

Reported By: Eric Lawrence
Date Reported: 2012-12-18
Held for Document Update by: Barry Leiba
Date Held: 2012-12-18

Section 5.7 says:

   o  Unmasked Ping request and masked Ping response

      *  0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello",
         but the contents of the body are arbitrary)

      *  0x8a 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58
         (contains a body of "Hello", matching the body of the ping)


It should say:

   o  Unmasked Ping request and masked Pong response

      *  0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello",
         but the contents of the body are arbitrary)

      *  0x8a 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58
         (contains a body of "Hello", matching the body of the ping)


Notes:

The response isn't a Ping, it's a Pong.
--VERIFIER NOTES--
The errata system is meant for documentation errors that could cause implementation confusion. I don't think this will confuse anyone.


Status: Rejected (2)

RFC6455, "The WebSocket Protocol", December 2011

Source of RFC: hybi (app)

Errata ID: 3215

Status: Rejected
Type: Technical

Reported By: Jesse Katzman
Date Reported: 2012-05-06
Rejected by: Barry Leiba
Date Rejected: 2012-05-06

Section 5.3 says:

The unpredictability of the masking key is
essential to prevent authors of malicious applications from selecting
the bytes that appear on the wire.

Notes:

I don't see how the client-to-server masking prevents "authors of malicious applications from selecting the bytes that appear on the wire".

Maliciously changing the contents of a message simply requires a few more steps than it would without masking, as far as I can tell.

I'm quite new at networking, so perhaps I'm missing something. Thank you.
--VERIFIER NOTES--
Not appropriate for errata; please take your input to the HyBi working group as it continues its efforts.


Errata ID: 3912

Status: Rejected
Type: Technical

Reported By: Mattias Ekendahl
Date Reported: 2014-03-05
Rejected by: Barry Leiba
Date Rejected: 2014-03-24

Section 5.2 says:

    frame-payload-length    = ( %x00-7D )
                            / ( %x7E frame-payload-length-16 )
                            / ( %x7F frame-payload-length-63 )
                            ; 7, 7+16, or 7+64 bits in length,
                            ; respectively

    frame-payload-length-16 = %x0000-FFFF ; 16 bits in length

    frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
                            ; 64 bits in length

It should say:

    frame-payload-length    = ( %x00-7D )
                            / ( %x7E frame-payload-length-16 )
                            / ( %x7F frame-payload-length-64 )
                            ; 7, 7+16, or 7+64 bits in length,
                            ; respectively

    frame-payload-length-16 = %x0000-FFFF ; 16 bits in length

    frame-payload-length-64 = %x0000000000000000-FFFFFFFFFFFFFFFF
                            ; 64 bits in length

Notes:

Name of field and range is implying that it should be 63 bits in length, but documentation is saying 64 bits in 2 places.
--VERIFIER NOTES--
The intended interpretation is that lexically the field is 64 bit long but the value space is constrained to 63 bit (so the length can be represented in a 64 signed integer, with the sign bit always zero). It is a bit unconventional to use ABNF like this, but it is explained in Section 5.2.


Report New Errata