From: "Michael Carter" <[EMAIL PROTECTED]>
Subject: Re: [whatwg] TCPConnection feedback
To: [EMAIL PROTECTED]
Message-ID:
<[EMAIL PROTECTED]>
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.
