[html5] r5171 - [e] (0) Clarify what parts of the server side of the WebSocket handshake are mea [...]
whatwg at whatwg.org
whatwg at whatwg.org
Tue Jul 20 16:52:51 PDT 2010
Author: ianh
Date: 2010-07-20 16:52:50 -0700 (Tue, 20 Jul 2010)
New Revision: 5171
Modified:
complete.html
index
source
Log:
[e] (0) Clarify what parts of the server side of the WebSocket handshake are meant to fit in unsigned 32-bit integers. Also, 'consistencise' the use of 32bit/32 bit/32-bit.
Modified: complete.html
===================================================================
--- complete.html 2010-07-20 22:55:14 UTC (rev 5170)
+++ complete.html 2010-07-20 23:52:50 UTC (rev 5171)
@@ -72453,9 +72453,9 @@
<p>The concatenation of the number obtained from processing the
<code title=http-sec-websocket-key>Sec-WebSocket-Key1</code>
- field, expressed as a big-endian 32 bit number, the number
+ field, expressed as a big-endian 32-bit number, the number
obtained from processing the <code title=http-sec-websocket-key>Sec-WebSocket-Key2</code> field,
- again expressed as a big-endian 32 bit number, and finally the
+ again expressed as a big-endian 32-bit number, and finally the
eight bytes at the end of the handshake, form a 128 bit string whose
MD5 sum is then used by the server to prove that it read the
handshake.</p>
@@ -73554,10 +73554,11 @@
<li>
- <p>Let <var title="">challenge</var> be the concatenation of <var title="">number<sub>1</sub></var>, expressed as a big-endian 32
- bit integer, <var title="">number<sub>2</sub></var>, expressed as
- a big-endian 32 bit integer, and the eight bytes of <var title="">key<sub>3</sub></var> in the order they were sent on the
- wire.</p>
+ <p>Let <var title="">challenge</var> be the concatenation of <var title="">number<sub>1</sub></var>, expressed as a big-endian
+ unsigned 32-bit integer, <var title="">number<sub>2</sub></var>,
+ expressed as a big-endian unsigned 32-bit integer, and the eight
+ bytes of <var title="">key<sub>3</sub></var> in the order they
+ were sent on the wire.</p>
<!--
perl -e 'foreach (@ARGV) { print pack 'N', $_ }' 777007543 114997259 | hexdump -C
@@ -73664,7 +73665,7 @@
<p class=warning>It is possible for a server to (innocently
or maliciously) send frames with lengths greater than
2<sup>31</sup> or 2<sup>32</sup> bytes, overflowing a signed
- or unsigned 32bit integer. User agents may therefore impose
+ or unsigned 32-bit integer. User agents may therefore impose
implementation-specific limits on the lengths of invalid
frames that they will skip; even supporting frames 2GB in
length is considered, at the time of writing, as going well
@@ -74096,6 +74097,15 @@
<var title="">key<sub title="">2</sub></var>, interpreted as a base ten integer,
ignoring all other characters in <var title="">key<sub title="">2</sub></var>.</p>
+ <p>If either <var title="">key-number<sub title="">1</sub></var>
+ or <var title="">key-number<sub title="">2</sub></var> is greater
+ than 4,294,967,295, then <a href=#abort-the-websocket-connection>abort the WebSocket
+ connection</a>. This is a symptom of an attack.</p>
+
+ <p class=note>If the client is a conforming client, then both
+ <var title="">key-number<sub title="">1</sub></var> and <var title="">key-number<sub title="">2</sub></var> will fit in
+ unsigned 32-bit integers.</p>
+
<div class=example>
<p>For example, assume that the client handshake was:</p>
@@ -74129,10 +74139,16 @@
<p>Let <var title="">spaces<sub title="">2</sub></var> be the number of U+0020 SPACE
characters in <var title="">key<sub title="">2</sub></var>.</p>
- <p>If either <var title="">spaces<sub title="">1</sub></var> or <var title="">spaces<sub title="">2</sub></var> is zero, then <a href=#abort-the-websocket-connection>abort the WebSocket
- connection</a>. This is a symptom of a cross-protocol
- attack.</p>
+ <p>If either <var title="">spaces<sub title="">1</sub></var> or
+ <var title="">spaces<sub title="">2</sub></var> is zero, then
+ <a href=#abort-the-websocket-connection>abort the WebSocket connection</a>. This is a symptom of
+ a cross-protocol attack.</p>
+ <p class=note>If the client is a conforming client, then both
+ <var title="">spaces<sub title="">1</sub></var> and <var title="">spaces<sub title="">2</sub></var> will easily fit in
+ unsigned 32-bit integers (indeed, they won't be greater than
+ 12).</p>
+
<p class=example>In the example above, <var title="">spaces<sub title="">1</sub></var> would be 4 and <var title="">spaces<sub title="">2</sub></var>
would be 10.</p>
@@ -74167,10 +74183,10 @@
<li>
- <p>Let <var title="">challenge</var> be the concatenation of <var title="">part<sub title="">1</sub></var>, expressed as a big-endian 32 bit integer,
- <var title="">part<sub title="">2</sub></var>, expressed as a big-endian 32 bit
- integer, and the eight bytes of <var title="">key<sub title="">3</sub></var> in the
- order they were sent on the wire.</p>
+ <p>Let <var title="">challenge</var> be the concatenation of <var title="">part<sub title="">1</sub></var>, expressed as a
+ big-endian unsigned 32-bit integer, <var title="">part<sub title="">2</sub></var>, expressed as a big-endian unsigned 32-bit
+ integer, and the eight bytes of <var title="">key<sub title="">3</sub></var> in the order they were sent on the
+ wire.</p>
<!--
perl -e 'foreach (@ARGV) { print pack 'N', $_ }' 906585445 179922739 | hexdump -C
@@ -74351,7 +74367,7 @@
<p class=warning>It is possible for a malicious client to send
frames with lengths greater than 2<sup>31</sup> or
- 2<sup>32</sup> bytes, overflowing a signed or unsigned 32bit
+ 2<sup>32</sup> bytes, overflowing a signed or unsigned 32-bit
integer. Servers may therefore impose implementation-specific
limits on the lengths of invalid frames that they will skip, if
they support skipping such frames at all. If a server cannot
@@ -94209,6 +94225,7 @@
Boris Zbarsky,
Brad Fults,
Brad Neuberg,
+ Brad Spencer,
Brady Eidson,
Brendan Eich,
Brenton Simpson,
Modified: index
===================================================================
--- index 2010-07-20 22:55:14 UTC (rev 5170)
+++ index 2010-07-20 23:52:50 UTC (rev 5171)
@@ -213,7 +213,7 @@
<header class=head id=head><p><a class=logo href=http://www.whatwg.org/ rel=home><img alt=WHATWG src=/images/logo></a></p>
<hgroup><h1>HTML5 (including next generation additions still in development)</h1>
- <h2 class="no-num no-toc">Draft Standard — 16 July 2010</h2>
+ <h2 class="no-num no-toc">Draft Standard — 20 July 2010</h2>
</hgroup><p>You can take part in this work. <a href=http://www.whatwg.org/mailing-list>Join the working group's discussion list.</a></p>
<p><strong>Web designers!</strong> We have a <a href=http://blog.whatwg.org/faq/>FAQ</a>, a <a href=http://forums.whatwg.org/>forum</a>, and a <a href=http://www.whatwg.org/mailing-list#help>help mailing list</a> for you!</p>
<!--<p class="impl"><strong>Implementors!</strong> We have a <a href="http://www.whatwg.org/mailing-list#implementors">mailing list</a> for you too!</p>-->
@@ -87583,6 +87583,7 @@
Boris Zbarsky,
Brad Fults,
Brad Neuberg,
+ Brad Spencer,
Brady Eidson,
Brendan Eich,
Brenton Simpson,
Modified: source
===================================================================
--- source 2010-07-20 22:55:14 UTC (rev 5170)
+++ source 2010-07-20 23:52:50 UTC (rev 5171)
@@ -81515,10 +81515,10 @@
<p>The concatenation of the number obtained from processing the
<code title="http-sec-websocket-key">Sec-WebSocket-Key1</code>
- field, expressed as a big-endian 32 bit number, the number
+ field, expressed as a big-endian 32-bit number, the number
obtained from processing the <code
title="http-sec-websocket-key">Sec-WebSocket-Key2</code> field,
- again expressed as a big-endian 32 bit number, and finally the
+ again expressed as a big-endian 32-bit number, and finally the
eight bytes at the end of the handshake, form a 128 bit string whose
MD5 sum is then used by the server to prove that it read the
handshake.</p>
@@ -82770,11 +82770,11 @@
<li>
<p>Let <var title="">challenge</var> be the concatenation of <var
- title="">number<sub>1</sub></var>, expressed as a big-endian 32
- bit integer, <var title="">number<sub>2</sub></var>, expressed as
- a big-endian 32 bit integer, and the eight bytes of <var
- title="">key<sub>3</sub></var> in the order they were sent on the
- wire.</p>
+ title="">number<sub>1</sub></var>, expressed as a big-endian
+ unsigned 32-bit integer, <var title="">number<sub>2</sub></var>,
+ expressed as a big-endian unsigned 32-bit integer, and the eight
+ bytes of <var title="">key<sub>3</sub></var> in the order they
+ were sent on the wire.</p>
<!--
perl -e 'foreach (@ARGV) { print pack 'N', $_ }' 777007543 114997259 | hexdump -C
@@ -82898,7 +82898,7 @@
<p class="warning">It is possible for a server to (innocently
or maliciously) send frames with lengths greater than
2<sup>31</sup> or 2<sup>32</sup> bytes, overflowing a signed
- or unsigned 32bit integer. User agents may therefore impose
+ or unsigned 32-bit integer. User agents may therefore impose
implementation-specific limits on the lengths of invalid
frames that they will skip; even supporting frames 2GB in
length is considered, at the time of writing, as going well
@@ -83389,6 +83389,16 @@
<var title="">key<sub title="">2</sub></var>, interpreted as a base ten integer,
ignoring all other characters in <var title="">key<sub title="">2</sub></var>.</p>
+ <p>If either <var title="">key-number<sub title="">1</sub></var>
+ or <var title="">key-number<sub title="">2</sub></var> is greater
+ than 4,294,967,295, then <span>abort the WebSocket
+ connection</span>. This is a symptom of an attack.</p>
+
+ <p class="note">If the client is a conforming client, then both
+ <var title="">key-number<sub title="">1</sub></var> and <var
+ title="">key-number<sub title="">2</sub></var> will fit in
+ unsigned 32-bit integers.</p>
+
<div class="example">
<p>For example, assume that the client handshake was:</p>
@@ -83422,11 +83432,17 @@
<p>Let <var title="">spaces<sub title="">2</sub></var> be the number of U+0020 SPACE
characters in <var title="">key<sub title="">2</sub></var>.</p>
- <p>If either <var title="">spaces<sub title="">1</sub></var> or <var
- title="">spaces<sub title="">2</sub></var> is zero, then <span>abort the WebSocket
- connection</span>. This is a symptom of a cross-protocol
- attack.</p>
+ <p>If either <var title="">spaces<sub title="">1</sub></var> or
+ <var title="">spaces<sub title="">2</sub></var> is zero, then
+ <span>abort the WebSocket connection</span>. This is a symptom of
+ a cross-protocol attack.</p>
+ <p class="note">If the client is a conforming client, then both
+ <var title="">spaces<sub title="">1</sub></var> and <var
+ title="">spaces<sub title="">2</sub></var> will easily fit in
+ unsigned 32-bit integers (indeed, they won't be greater than
+ 12).</p>
+
<p class="example">In the example above, <var
title="">spaces<sub title="">1</sub></var> would be 4 and <var title="">spaces<sub title="">2</sub></var>
would be 10.</p>
@@ -83465,10 +83481,12 @@
<li>
<p>Let <var title="">challenge</var> be the concatenation of <var
- title="">part<sub title="">1</sub></var>, expressed as a big-endian 32 bit integer,
- <var title="">part<sub title="">2</sub></var>, expressed as a big-endian 32 bit
- integer, and the eight bytes of <var title="">key<sub title="">3</sub></var> in the
- order they were sent on the wire.</p>
+ title="">part<sub title="">1</sub></var>, expressed as a
+ big-endian unsigned 32-bit integer, <var title="">part<sub
+ title="">2</sub></var>, expressed as a big-endian unsigned 32-bit
+ integer, and the eight bytes of <var title="">key<sub
+ title="">3</sub></var> in the order they were sent on the
+ wire.</p>
<!--
perl -e 'foreach (@ARGV) { print pack 'N', $_ }' 906585445 179922739 | hexdump -C
@@ -83681,7 +83699,7 @@
<p class="warning">It is possible for a malicious client to send
frames with lengths greater than 2<sup>31</sup> or
- 2<sup>32</sup> bytes, overflowing a signed or unsigned 32bit
+ 2<sup>32</sup> bytes, overflowing a signed or unsigned 32-bit
integer. Servers may therefore impose implementation-specific
limits on the lengths of invalid frames that they will skip, if
they support skipping such frames at all. If a server cannot
@@ -108135,6 +108153,7 @@
Boris Zbarsky,
Brad Fults,
Brad Neuberg,
+ Brad Spencer,
Brady Eidson,
Brendan Eich,
Brenton Simpson,
More information about the Commit-Watchers
mailing list