<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000">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).<br>
</div></blockquote><div><br>Actually, I've already tested this protocol against some typical forward proxy setups and it hasn't caused any problems so far. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><br>
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.</div></blockquote><div><br>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. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><br>
<br>
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.<div class="Ih2E3d"></div></div></blockquote><div><br>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?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><div class="Ih2E3d"><blockquote type="cite">
<blockquote type="cite"><pre><span>> </span>[If a] protocol is decided on, and it is allowed to connect to any IP-address
<span>> </span>- then DDOS attacks can still be performed: If one million web
<span>> </span>browsers connect to any port on a single server, it does not matter
<span>> </span>which protocol the client tries to communicate with. The server will
<span>> </span>still have problems.
</pre>
</blockquote>
<pre>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 = <a href="http://victim.example.com/" target="_blank">"http://victim.example.com/"</a> + generateLongRandomString();
}, 1000);
for example would?</pre>
</blockquote></div>
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.</div></blockquote><div> </div><div>What do you mean by brute-force access, and how could the proposed protocol be used to do it. Can you provide an example?<br><br>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.<br>
<br>-Michael Carter<br></div></div>