Subject: [hybi] Removing Sec-WebSocket-Origin header field from the WebSocket document

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Aug 2011 17:54:13 +0100

Hi,

Richard Barnes who did Gen-Art team review of the protocol document 
asked the following question:

  Why is this document creating a separate Sec-WebSocket-Origin header, rather than using the Origin header from draft-ietf-websec-origin?

I've asked several people and nobody could tell me why the document is defining a new header field. So unless I hear some objection/explanation of why an additional header field is useful, it will be removed in -11.

Thank you,
Alexey, on behalf of editors of the document.

---

From: John Tamplin <[email-masked]>
Date: Sun, 14 Aug 2011 15:15:45 -0400

On Sun, Aug 14, 2011 at 12:54 PM, Alexey Melnikov <[email-masked]
> wrote:

> Richard Barnes who did Gen-Art team review of the protocol document asked
> the following question:
>
>  Why is this document creating a separate Sec-WebSocket-Origin header,
> rather than using the Origin header from draft-ietf-websec-origin?
>
> I've asked several people and nobody could tell me why the document is
> defining a new header field. So unless I hear some objection/explanation of
> why an additional header field is useful, it will be removed in -11.
>

My understanding is that the Sec-* headers were used because they cannot be
set on arbitrary XHR requests by hostile Javascript, thus helping prevent
spoofing of WS connections.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Aug 2011 20:19:55 +0100

John Tamplin wrote:
> On Sun, Aug 14, 2011 at 12:54 PM, Alexey Melnikov 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Richard Barnes who did Gen-Art team review of the protocol
>     document asked the following question:
>
>      Why is this document creating a separate Sec-WebSocket-Origin
>     header, rather than using the Origin header from
>     draft-ietf-websec-origin?
>
>     I've asked several people and nobody could tell me why the
>     document is defining a new header field. So unless I hear some
>     objection/explanation of why an additional header field is useful,
>     it will be removed in -11.
>
>
> My understanding is that the Sec-* headers were used because they 
> cannot be set on arbitrary XHR requests by hostile Javascript, thus 
> helping prevent spoofing of WS connections.
Yes that occurred to me as well, but, IMHO, that is a wrong reason to 
invent a new header field with identical semantics.

---

From: Philipp Serafin <[email-masked]>
Date: Sun, 14 Aug 2011 21:27:14 +0200

> helping prevent spoofing of WS connections. 
Would that really be a security issue?

On XHR implementations that support CORS, neither can the Origin header
be spoofed.
Old implementations without CORS support only permit same-origin
requests. I'd think if an attacker can inject JS code into pages of the
victim's origin, spoofed WS connections are probably the least concern.

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 15 Aug 2011 10:09:36 +1000

> Would that really be a security issue?

Also note that we don't need Sec-* on all headers in the handshake
request.  We only need to require Sec- on 1 mandatory header and that
should be sufficient to prevent spoofing.   The key exchange header
fits that bill, so I don't see why we need it on Origin.  After all we
are not sending a Sec-Upgrade header!

cheers

---

From: "Simon Pieters" <[email-masked]>
Date: Tue, 16 Aug 2011 12:17:35 +0200

On Sun, 14 Aug 2011 18:54:13 +0200, Alexey Melnikov  
<[email-masked]> wrote:

> defining a new header field. So unless I hear some objection/explanation  
> of why an additional header field is useful, it will be removed in -11.
>
> Thank you,

<Hixie> zcorpan: back when i was editing the spec, it had Origin:  
client-to-server, and Sec-WebSocket-Origin server-to-client
<Hixie> zcorpan: because Origin: is only defined for client-to-server, and  
because it was another way to prevent echo servers getting p0wned

http://krijnhoetmer.nl/irc-logs/whatwg/20110815#l-802

I note that indeed  
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 has Origin  
as a request header and Sec-WebSocket-Origin as a response header, while  
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10 has  
only Sec-WebSocket-Origin as a request header, and no such response header  
(I guess the server needs to reject the connection if it doesn't want to  
accept the origin). I have no idea why the request header was renamed  
between -76/-00 and -10. I'm fine with renaming it back to Origin.

-- 
Simon Pieters
Opera Software

---

From: "Len Holgate" <[email-masked]>
Date: Tue, 30 Aug 2011 08:44:54 +0100

Could someone explain the rationale behind how changing the header field for
origin from Sec-WebSocket-Origin to Origin in v11 of the draft doesn't
require a protocol version change?

Surely an implementation of draft 08 which advertises itself as
Sec-WebSocket-Version: 8 can now fail to interoperate with an implementation
of draft 11 or 12 which also avertises itself as Sec-WebSocket-Version: 8.

At the very least, a draft 08 implementation will now incorrectly interpret
browser clients (implementing 11 or later) as non browser clients and if
there are any draft 08 implementations that use origin specific "access
control"...

Likewise the Sec-WebSocket-Version change also breaks protocol compatibility
in that a draft 08 client would expect the response from the server to
include the WebSocket-Version header and a draft 11 server only has to send
it if the handshake fails...

Len

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 30 Aug 2011 10:44:38 +0100

Hi,

>there are any draft 08 implementations that use origin specific "access
Maybe not bumping the version number was a mistake. The server can 
handle either type of client, but this is not explicitly mentioned in 
the draft.

>it if the handshake fails...
I don't think I've made any intentional change in this area, I think 
I've only clarified the text that was already in the document. Please 
describe the behaviour you would like to see.

---

From: "Len Holgate" <[email-masked]>
Date: Tue, 30 Aug 2011 11:00:53 +0100

> handle either type of client, but this is not explicitly mentioned in 

How? If the server is only looking for Sec-WebSocket-Origin (which a valid
08 draft server could be) then it wont see the Origin header from the v11
client.

> describe the behaviour you would like to see.

My mistake, I thought that the server echoed the version back on successful
connection, it doesn't.

Lem

---

From: John Tamplin <[email-masked]>
Date: Tue, 30 Aug 2011 11:51:18 -0400

> 08 draft server could be) then it wont see the Origin header from the v11

I server implementing v08 and v11 can look for both, the same way existing
servers support older versions of the protocol.

---

From: "Len Holgate" <[email-masked]>
Date: Tue, 30 Aug 2011 17:12:26 +0100

A new server, yes, anything existing that thinks it implements protocol
version 8 now doesn't implement draft HyBi-11's version of protocol version
8... 

> -----Original Message-----
> From: John Tamplin [mailto:[email-masked]] 
> Sent: 30 August 2011 16:51
> To: Len Holgate
> Cc: Alexey Melnikov; Hybi
> Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin
> 
> I server implementing v08 and v11 can look for both, the same 
> way existing servers support older versions of the protocol.
> 
> -- 
> John A. Tamplin

---

From: Brian <[email-masked]>
Date: Tue, 30 Aug 2011 10:21:14 -0700

Yes.  The protocol version needs to be incremented when there is a
non-backward-compatible handshake change as well as when there is a
non-backward-compatible change to the framing.  If we're changing the name
of the origin header, we absolutely need to also increment the version
number.

Brian

---

From: Patrick McManus <[email-masked]>
Date: Tue, 30 Aug 2011 13:25:37 -0400

I'd much rather see the silly aesthetic name change reverted, so we
could get some testing continuity and experience in order to find actual
meaningful shortcomings in the protocol.

On Tue, 2011-08-30 at 10:21 -0700, Brian wrote:
> non-backward-compatible change to the framing.  If we're changing the
> name of the origin header, we absolutely need to also increment the
> version number.
> 
> Brian
> 
>

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 30 Aug 2011 10:33:36 -0700

I don't have a strong feeling on the origin header, only that the version is incremented if there's a backward incompatible change in the handshake.

Sent from my iPhone

---

From: "Len Holgate" <[email-masked]>
Date: Tue, 30 Aug 2011 18:48:53 +0100

Agreed. 

> From: Brian McKelvey [mailto:[email-masked]] 
> Sent: 30 August 2011 18:34
> To: Patrick McManus
> Cc: Len Holgate; Hybi
> I don't have a strong feeling on the origin header, only that 
> the version is incremented if there's a backward incompatible 
> change in the handshake.
> 
> Sent from my iPhone
> 
> >> On Tue, Aug 30, 2011 at 9:12 AM, Len Holgate 
> <[email-masked]>
> >> wrote:
> >>        A new server, yes, anything existing that thinks it 
> implements
> >>        protocol

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 30 Aug 2011 10:55:49 -0700

> I'd much rather see the silly aesthetic name change reverted, so we could get
> some testing continuity and experience in order to find actual meaningful
> shortcomings in the protocol.

+1

Maybe we could queue up a header name change for the future to merge into any
protocol change that would necessarily require bumping up the version (should there
be such change).

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 31 Aug 2011 11:13:28 +0100

The version will be incremented in -13, so the error of not incrementing 
it earlier should be short lived.