[whatwg] TCPConnection feedback

From: "Michael Carter" <michael.carter@kaazing.com>
Subject: Re: [whatwg] TCPConnection feedback
To: whatwg at whatwg.org
Message-ID:
	<24f9a1ba0806191101h13291792wded6d16560fec632 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

> I fail to see how virtual hosting will work for this anyway. I mean we're
>> not talking about Apache/IIS here, we're talking about custom applications,
>> scripts or devices - possibly implemented in firmware or "a few lines of
>> perl". Adding vhost control to the protocol is just silly since the
>> webserver won't ever see the request and the customer application should be
>> able to use any method it likes to differentiate its services. Even URI
>> addressing is silly since again the application may have no concept of
>> "paths" or "queries". It is simply a service running on a port. The only
>> valid use case for all this added complexity is proxying but nobody has
>> tested yet whether proxies will handle this (short of enabling encryption,
>> and even that is untested).
>>
> 
> Actually, I've already tested this protocol against some typical forward
> proxy setups and it hasn't caused any problems so far.


Can you elaborate on what you mean by tested? Are you saying you've performed non-TLS, persistent, asynchronous 
communication through a proxy + Apache/IIS or proxy + custom application?


>>
>> I'm thinking here that this proposal is basically rewriting the CGI
>> protocol (web server handing off managed request to custom scripts) with the
>> ONLY difference being the asynchronous nature of the request. Perhaps more
>> consideration might be given to how the CGI/HTTP protocols might be updated
>> to allow async communication.
>>
> 
> Rewriting the HTTP spec is not feasible and I'm not even convinced its a
> good idea. HTTP has always been request/response so it would make a lot more
> sense to simply use a new protocol then confuse millions of
> developers/administrators who thought they understood HTTP.

As pointed out by others HTTP can preform asynchronously and persistently under certain circumstances (ie TLS 
handshake). Microsoft describe the process here: http://msdn.microsoft.com/en-us/library/aa380513(VS.85).aspx

This appears to be bi-directional communication so we can probably assume that proxies and servers supporting TLS could 
be made to support other async processes. Also taking into consideration what others have said regarding keep-alive and 
protocol switching it would seem that we are looking at a fairly trivial problem as far as HTTP is concerned. My 
recommendation is probably less relevant to HTTP than it is to CGI.

Currently CGI has the web server offload a bunch of environment variables that the CGI script decodes. What's missing 
then is a way to pass the whole socket off to the script. The Fast CGI protocol is closer to the mark. Wikipedia says: 
"Environment information and page requests are sent from the web server to the process over a TCP connection (for remote 
processes) or Unix domain sockets (for local processes). Responses are returned from the process to the web server over 
the same connection. The connection may be closed at the end of a response, but the web server and the process are left 
standing."

So Fast CGI achieves all the main goals for WebSocket (proxy support, virtual hosting, ssl support) using existing 
access control rules and configs that ISPs are familiar with. The only thing that is not supported is persistent 
bi-directional communication (at least I have found nothing to indicate this). However based on the description above 
the only limiting factor seems to be an assumption that all links in the chain close the connection after the initial 
server response (making it bi-directional but not persistent). It also isn't strictly asynchronous since the client and 
server apparently cannot send/receive simultaneously.

I propose a new protocol called Asynchrous CGI that extends Fast CGI to support asynchonous and persistent channels 
rather than the creation of an entirely new WebSockets protocol from scratch.

>>
>> Having said that I still see a very strong use case for low-level
>> client-side TCP and UDP. There are ways to manage the security risks that
>> require further investigation. Even if it must be kept same-domain that is
>> better than creating a new protocol that won't work with existing services.
>> Even if that sounds like a feature - it isn't. There are better ways to
>> handle access-control for non-WebConnection devices than sending garbage to
>> the port.
>>
> 
> If we put the access control in anything but the protocol it means that we
> are relying on an external service for security, so it would have to be
> something that is completely locked down. I don't really see what the
> mechanism would be. Can you propose a method for doing this so as to allow
> raw tcp connections without security complications?


I don't understand your point. Existing services use firewalls, authentication, host-allow, etc as appropriate. The only 
new issue TCPConnection or WebConnection introduce is the concept of an "non-user-initiated connection". In other words 
a remote untrusted server causing the local machine to make a connection without an explicit user action (such as 
checking mail in Outlook). I believe the proposed DNS extension combined with some form of explicit user-initiated 
priviledge elevation reduce the two main threats: DDOS and browser-based brute-force attacks.


>> How would WebSocket connections be more harmful than something like
>>
>> setInterval(function(){
>>   var img = new Image();
>>   img.src = "http://victim.example.com/" <http://victim.example.com/> + generateLongRandomString();
>> }, 1000);
>>
>> for example would?
>>
>>  It's more harmful because an img tag (to my knowledge) cannot be used to
>> brute-force access, whereas a socket connection could. With the focus on
>> DDOS it is important to remember that these sockets will enable full
>> read/write access to arbitrary services whereas existing methods can only
>> write once per connection and generally not do anything useful with the
>> response.
>>
> 
> What do you mean by brute-force access, and how could the proposed protocol
> be used to do it. Can you provide an example?
> 
> Also, the proposed protocol will do a single HTTP request, just like the img
> tag, and the response be hidden from the attacker if it wasn't the right
> response. From a potential attacker's point of view, this is a write once
> per connection where the only control they have over the request is the
> value of the url. Attacking with this protocol is identical to attacking
> with an image tag in every way that I can think of.

I already have already provided two examples in previous posts but to reiterate quickly this protocol as currently 
described can be manipulated to allow a full challenge-response process. This means I can make every visitors browser 
continually attempt username/password combinations against a service, detect when access is granted, and continue to 
send commands following the handshake. IMG and FORM allow at most a single single request to be sent before closing the 
connection and generally return the data in a form that cannot be inspected inside javascript. I have shown that by 
injecting a custom URI into the handshake I can theoretically force a valid server response to trick the browser into 
keeping the connection open for the purpose of DDOS or additional attacks. The difference is not in the ability to DDOS, 
it's in the ability to maintain a connection in the presense of a server challenge, despite WebSockets proposed 
safeguards (keeping in mind these proposed safeguards render the protocol useless for accessing legacy devices).


Shannon

PS (to list): Sorry if this post generates yet another thread. Thunderbird keeps truncating my replies in a way that 
seems to invalidate the thread history. I might need to shift to a proper newsreader.

Received on Friday, 20 June 2008 01:26:29 UTC