Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.

On Fri, Dec 4, 2009 at 12:52, Ian Hickson <ian@hixie.ch> wrote:
>> >> With flash, you can connect to any server and any port as long as the
>> >> application can first download a policy file from the same IP number.
>> >
>> > Flash's security model has had so many security holes reported on it
>> > that I really don't want to try to emulate it. It also requires two
>> > sets of TCP connections per socket, and has some scary race
>> > conditions. It also requires talking to two different ports, which is
>> > dubious in shared hosting situations.
>>
>> In shared hosting situations, the policy file should be generated from
>> other data sources, just like other firewall rules, no?
>
> How is the client supposed to recognise a shared hosting situation?

It does not need to. It is an administrative issue of each site to
allocate hosts & port numbers to services and the policy file is the
site's way of telling what webpages are allowed to connect to them.

>> Just so we are talking about the same thing. When the current flash
>> player tries to connect with TCP to a server, it first connects to a
>> different port on that server and gets a policy file in response, the
>> player does only have to open the port and the server just have to
>> send a file and close the socket afterwards. So it wastes less network
>> and server resources than getting the FavIcon.ico file for example.
>
> There are at least two problems with this: first, the port contacted might
> not be the one under the control of the target service, and second, it
> means there are at least two TCP roundtrips required before the WebSocket
> connection can be opened.

How would the policy file and the service not be under the same
control? I fail to see the attack scenarios to make that happen.
The second connection should of course only be made to the same IP
number as the first connection.

> If we assume a round-trip time of 120ms, that
> means that opening a WebSocket connection takes 360ms rather than the
> 120ms it takes with the security model in the spec today. That's a lot of
> extra latency.

One could also do both connections at the same time, but not open the
socket to the application until the policy file has been read. Or
simply use a cache.

>> I don't know if the current player caches the result, but that could be
>> added.
>
> Then you increase the race condition I mentioned from being merely a few
> milliseconds to being whatever the time-to-live of the policy file is.

Since I fail to see the attack scenario, I fail to see the race condition.


>>> What's wrong with the way WebSocket does it?

>> Many custom protocols are based on a length field followed by a protocol
>> frame. With WebSocket it is possible to connect to such a service and be
>> connected for a while until a timeout happens and thus a DoS attack
>> against such a service would be trivial to write.
>
> Interesting. Do you have any examples of such services that I could study?
> If we could mitigate that that would be very useful. Are these services
> that send no traffic until they've received the first packet?

MS-RPC and CIFS are such I believe. At least one can send the example
header from the RFC to them without being disconnected nor getting an
answer.
I've seen a few network games that uses such a protocol too, but many
of them do send an initial packet so at least the client could
disconnect when getting the incorrect answer.

Regards,
Sebastian Andersson

Received on Friday, 4 December 2009 15:42:52 UTC