Re: [hybi] NPN proposal

[Ian Fette (イアンフェッティ) <[e-mail]>]

2010/12/21 Simon Pieters <[e-mail]>

> On Tue, 21 Dec 2010 18:36:46 +0100, Ian Fette (イアンフェッティ) <
> [e-mail]> wrote:
>
>  I will be writing the following up as a more concrete proposal for a
>> NPN-based handshake, but wanted to send something out quickly as it seems
>> timely. The below assumes we can work with the appropriate groups to make
>> progress on NPN. (I'm no longer convinced that this group is faster moving
>> than any other.)
>> http://tools.ietf.org/id/draft-agl-tls-nextprotoneg-00.txt
>>
>> Assumptions:
>> 1. The framing from -03 is good enough.
>> 2. SSL handshake roundtrip is acceptable cost
>> 3. We still want to be able to send headers
>>  - this includes cookies
>>  - this includes a resource / path (so we can figure out which backend /
>> application we are taking about)
>>  - this includes "Origin"
>> 4. After the SSL handshake we don't want an extra roundtrip if we can
>> avoid
>> it
>> 5. After SSL+NPN handshake we are sure we are talking to WebSocket
>> endpoint.
>> 6. We assume people can deploy NPN
>> 7. We assume SSL extensions actually work, and available in well known
>> libraries.
>> 8. We assume ws:// should not require encryption (monitoring software etc
>> continues to work)
>> 9. We assume we can use :443 for both ws:// and wss://
>>
>> Proposal:
>> 1. Use -03 framing
>> 2. Add a "Hello" frame type (more detail later) with opcode 0x06
>> 3. In the SSL handshake, use npn("websockets") to indicate that we want to
>> establish SSL connection
>> 4. For ws://, do not check certificate validity. use NULL
>> (TLS_RSA_WITH_NULL_SHA?) cipher suite. This still has some overhead but
>> allows intermediaries such as those deployed at school to look for porn
>> still function. Encrypting / masking would introduce significant
>> deployment
>> headaches for such scenarios otherwise.
>> 5. NPN allows for a server to announce things like extensions in the
>> ServerHello and a client to select. We could use this facility to
>> negotiate
>> protocol-level extensions (if any).
>> 6. After SSL handshake, we have selected WebSocket extension(s) (if any),
>> WebSocket extensions (if any).
>> 7. We still need to indicate the resource (ws://google.com/gmail/chat)
>> somewhere. We also need to include e.g. Cookies. And, if there are any
>> WebSocket "SubProtocols" we need to indicate those as well. So, let's have
>> the first thing a client or server sends be a HELLO frame, unfragmented.
>> The
>> Hello frame in its body includes:
>> - client: HTTP headers for Origin:, Sec-WebSocket-URL, Cookie:,
>> Sec-WebSocket-Protocol, X-Whatever-Else
>> - server: Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
>> (same as a HTTP response, may include error codes like 403), Set-Cookie,
>>  X-Whatever-Else
>> 8. Assume after client has sent HELLO, it is free to start sending data.
>> It
>> doesn't have to wait for server HELLO. Caveat being if the client needs to
>> negotiate a "subprotocol" then it should wait for that to be echoed in a
>> server HELLO. (Is anyone actually planning on using SubProtocol?)
>>
>
> Currently the client is not allowed to send messages until the connection
> is established. The server needs Origin, URL and subprotocol to decide
> whether to establish the connection. If the client gets 'open' and starts
> sending messages, but the server actually refuses the connection based on
> the information in the Hello frame, then the client will think that the
> connection was first accepted but then dropped.
>
> I think we still need to wait for the server to check Origin, URL and
> subprotocol before saying that the "connection is established".
>
> Would it be possible to smuggle this information somewhere in the TLS
> handshake?
>
>
>
In the current draft of NPN, the client is basically not allowed to smuggle
any data in the handshake. Adam Langley didn't seem thrilled with the
prospect, though it is possible.

I agree it might be a bit odd to say the websocket is connected, and then
throw an error saying "oops, never mind". We could do it, but it wouldn't be
that clean. A server may also wish to check the cookies before accepting
data. I suppose a server could decide to close the connection based on any
of that data. It's not clear how much we really want to smuggle into the TLS
handshake (cookies, etc?).

Perhaps we end up living with the rtt, though it does seem unfortunate.


>
>  9. Server MAY send data immediately after sending Server HELLO, but in
>> practice it will probably only ever send data after receiving client's
>> first
>> data frame.
>>
>>
>> I am happy to write this up in more detail as a formal draft, but I wanted
>> to at least get this out for discussion as long as other people are
>> contributing handshake proposals. I personally think such an approach is
>> far
>> easier to reason about from a security perspective, avoids discussions
>> about
>> semantics of CONNECT and whether or not UPGRADE is understood by
>> intermediaries, whether or not we need to do payload masking, etc.
>>
>
>
> --
> Simon Pieters
> Opera Software
>