Subject: [hybi] -09: security considerations

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Jun 2011 10:48:49 -0600

First, I am not a member of the security mafia.

However, the security considerations section seems incomplete to me. I
suggest that the author and WG spend some quality time with RFC 3552
(and with other RFCs that have good discussions of security) to make
this section more robust and complete.

Questions to ask and answer include (but are not limited to):

1. What is the threat model against the architecture assumed in this
document? (And to answer that question, it would help to more clearly
explain the architecture.)

2. How will the protocol address confidentiality?

3. How will the protocol address data integrity?

4. How will the protocol address peer entity authentication?

5. How does the protocol ensure strong security (RFC 3365)?

6. If certificates are to be used, how are they handled (RFC 6125 and
RFC 2818)?

7. What are the mandatory-to-implement TLS ciphersuites?

8. What are the security considerations related to technologies that are
reused in WebSocket (e.g., Base 64 and UTF-8)?

9. What information leaks are possible?

10. What denial of service attacks (RFC 4732) are possible and what
measures can be taken to prevent those attacks?

11. What is the relationship, if any, between the security of the
WebSocket protocol and the security of HTTP? In what ways does this
protocol build on HTTP from a security perspective, and in what ways
does it need additional security mechanisms?

I'm sure the reviewer from the IETF Security Directorate will come up
with more questions than that, so we need to be prepared.

A personal note: in revising RFC 3920 to produce RFC 6120, I put a great
deal of thought and time into writing the security considerations
section, which ended up being 20 pages long. That might be longer than
necessary here, but I think 2 pages is a bit shy of what we need.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Fri, 17 Jun 2011 09:55:42 -0700

I would hope that the discussions don't need to be so long. The security
model is based on that of HTTP. Whatever HTTP gives you WS gives you,
whatever HTTPS gives you WSS gives you. WS is at its core a less hacky more
performant version of what people are already doing today in javascript,
it's not some totally new concept.

-Ian

On Fri, Jun 17, 2011 at 9:48 AM, Peter Saint-Andre <[email-masked]>wrote:

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

---

From: Adam Barth <[email-masked]>
Date: Fri, 17 Jun 2011 23:30:30 -0700

There's somewhat more to it than that, right?  For example, HTTP
doesn't use the origin security model, whereas WebSockets does.  Also,
HTTP punts on cross-protocol security issues, whereas WebSockets does
not.  Finally, HTTP has the benefit of being invented prior to the
deployment of much of today's network infrastructure.  That means the
network infrastructure needs to work around HTTP whereas WebSockets
needs to work around the network infrastructure.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 20 Jun 2011 16:42:45 +1000

Also HTTP has BASIC and DIGEST authentication, while WS does not
(although it could very easily support these).

cheers

---

From: Diogo Pereira <[email-masked]>
Date: Mon, 20 Jun 2011 08:19:51 +0100

> (although it could very easily support these).

I think this is implicitly allowed:

 "1.  If the status code received from the server is not 101, the
       client handles the response per HTTP procedures." (p. 30)

So in response to a 401 the client could resend the handshake request
with an Authorization header.

-- 
Diogo

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jun 2011 10:34:18 +0200

> with an Authorization header.

The question is: should the browser prompt the human user for
user/pass as when a 401 is received before accessing to a web page?

Imagine this case:

- www.domain.org => 1.1.1.1:80

- ws.domain.org => 1.1.1.2:443

- I open http://www.domain.org in my browser, fill some login form and
retrieve websocket connection data, including an user and pass (for
Digest).

- My JavaScript is then provisioned (via JavaScript WebSocket API
????) with ws connection data: server ip, port, Digest user/passwd.

- My web browser starts the ws connection with ws.domain.org:443. It
receives 401 with Digest (so I need a nonce from the server before
using my user/passwd).

- JavaScript code automatically accepts the Digest chanllenge,
generates a Digest response with the provided user/passwd and the
retrieved Digest nonce, and re-send the HTTP GET request (all of this
without prompting the user).

- If the JavaScript code would not be proviosioned with user/pass,
then upon receipt of the 401 it should prompt the user.

So, if all this stuff is not clearly specified (and I think passing
user/pass to the JavaScript WebSocket connection API does not exist)
then using HTTP Digest (or Basic) will be not useful or feasible, and
I expect than using cookies and all that "pure just-web stuff" will be
the only way. Please, take into account that a websocket server could
run in a separate server, so using cookies mechanism is not so
feasible. Neither I think that cookies (a workaround to simulate
sessions in HTTP protocol) are the best way to go.

IMHO the draft should do much more effort in authentication process.
Please don't let the door open to ugly and/or propietary
authentication solutions.

-- 
Iñaki Baz Castillo
<[email-masked]>