Couldn't SCTP/DCCP (or a variant) over UDP (for NAT compatibility) work?<br><br>They seem both seem to be session oriented while loosening the other restrictions of TCP,<br><br><br><div class="gmail_quote">On 4 June 2010 00:18, Philip Taylor <span dir="ltr"><<a href="mailto:excors%2Bwhatwg@gmail.com">excors+whatwg@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Thu, Jun 3, 2010 at 7:28 AM, Erik Möller <<a href="mailto:emoller@opera.com">emoller@opera.com</a>> wrote:<br>


> [...]<br>
<div class="im">> One thing to remember here is that browsers have other means for<br>
> communication as well. I'm not saying we shouldn't support reliable messages<br>
> over UDP, but just pointing out the option.<br>
<br>
</div>Yep - the relevant use cases ought to be supported decently by the<br>
platform, but not necessarily by this extension to the platform (it<br>
might be a different extension or it might be (probably is) supported<br>
already).<br>
<div class="im"><br>
>> - Protection against an attacker initiating a legitimate socket with a<br>
>> user and then redirecting it (with some kind of IP (un)hijacking) to a<br>
>> service behind the user's firewall (which isn't a problem when using<br>
>> TCP since the service will ignore packets when it hasn't done the TCP<br>
>> handshake; but UDP services might respond to a single packet from the<br>
>> middle of a websocket stream, so every single packet will have to be<br>
>> careful not to be misinterpreted dangerously by unsuspecting<br>
>> services).<br>
><br>
> I don't quite follow what you mean here. Can you expand on this with an<br>
> example?<br>
<br>
</div>I was thinking something like: A host at IP 11.11.11.11 on the public<br>
internet runs some UDP service, like DNS or TFTP or something a bit<br>
more secure. That service is restricted so it only responds to packets<br>
received from IP 22.22.22.22 (a trusted user). The UDP Web Socket<br>
handshake is carefully constructed so that it won't trigger dangerous<br>
behaviour in any of those services (like how the TCP Web Socket uses a<br>
safe HTTP-ish handshake).<br>
<br>
An attacker hijacks the IP 11.11.11.11 from the perspective of the<br>
user (by advertising new routes near the user), so the user's packets<br>
to that address go to the attacker. The attacker gets the user to<br>
visit a web page which sets up a UDP Web Socket with the attacker's<br>
server at 11.11.11.11, doing all the handshake authentication<br>
correctly.<br>
<br>
The attacker then releases its hijacked address, so any subsequent Web<br>
Socket packets will go to the original restricted service. Since<br>
they're being received from the trusted user, the service will trust<br>
them. Since the web browser has already done the Socket handshake, it<br>
will believe it's talking to a legitimate Web Socket server and will<br>
continue sending whatever data packets the attacker's script tells it<br>
to.<br>
<br>
The service will then be receiving and responding to<br>
attacker-controlled packets, and will never have seen the carefully<br>
constructed handshake that's designed to protect it. That's not a<br>
danger for TCP services since they'll reject unexpected packets from<br>
the middle of a TCP stream, but UDP services may accept packets from<br>
the middle of a UDP Web Socket stream.<br>
<br>
So it's not sufficient to carefully construct the Web Socket handshake<br>
packets to not trigger unwanted behaviour in non-Socket services.<br>
Every data packet sent on the Socket has to be carefully constructed<br>
too.<br>
<br>
(This might be a largely impractical or pointless attack, and there's<br>
probably much easier ways to attack the exposed service, but I don't<br>
know enough about security to judge that. Also I don't know what<br>
packet construction would be sufficiently careful. But it seems like a<br>
possible new concern that's introduced when using UDP in this<br>
context.)<br>
<div><div></div><div class="h5"><br>
--<br>
Philip Taylor<br>
<a href="mailto:excors@gmail.com">excors@gmail.com</a><br>
</div></div></blockquote></div><br>