[whatwg] TCPConnection feedback

[Michael Carter]

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.


>
> 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.


>
> 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?

> [If a] protocol is decided on, and it is allowed to connect to any IP-address> - then DDOS attacks can still be performed: If one million web> browsers connect to any port on a single server, it does not matter> which protocol the client tries to communicate with. The server will> still have problems.
>
>
>  Couldn't this already be done today, though? You can already today
> connect to an arbitrary server on an arbitrary port using forms,
> <img>, <script src=""> and all other references that cannot be
> cross-domain protected for backwards compatibillity reasons. The whole
> hotlinking issue is basically the result of that.
> 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.

-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080619/1d96552a/attachment-0001.htm>