8 ms·

Wouldn't this make it pretty easy to have browser clients unknowingly participate in DoS attacks?

dsl 9y ago
Yes. The only way this could be done safely is if you are required to establish a TCP connection, and then "upgrade" it to UDP. There are too many pointy sticks that developers could impale themselves on, with the side effect of creating DDoS vectors.
- deleted 9y ago
  [deleted]
- geofft 9y ago
  Can you do it safely if you're required to make an HTTPS request to the same hostname with some standardized request (a la CORS preflight) and get an answer back saying "Yes, this origin may connect to me on these UDP ports", and then hang onto that permission indefinitely? The nice thing about having a persistent permission instead of an upgrade on each request is that a service worker that's woken up by a push notification or similar can immediately send UDP traffic instead of doing a TCP (+ HTTPS?) handshake. Since it's restricted by origin (probably using literally the same mechanism CORS uses) and over HTTPS, a malicious actor can't DDoS anyone but themselves. If you're really worried, maybe extend it to allow the server to limit the duration of the permission and the maximum bandwidth, but I think you don't need that. EDIT: Oh, oops, binding to the hostname doesn't help because you can just repoint your hostname in DNS at someone else. You'd ideally need to bind it to the IP, in which case you definitely want it to be a time-limited permission. (But I think that attack is also feasible, though a bit harder, with the handshake-before-each-UDP-connection model. Just have the attacker set up a custom DNS server for their domain, which for any hostname sends you a low-TTL response pointing to the attacker's HTTPS server, and then a higher-TTL response to the victim. Each user gets pointed at a random hostname within that domain.)
  - jandrese 9y ago
    That model tends to be hell on firewall appliances and NAT/load balancing devices.
    - geofft 9y ago
      I'm not sure I follow - how is this different from, say, a native app (desktop or mobile) that's just using UDP like normal? There's a single preflight request per client device, which can usually be satisfied when you load the website itself.
      - edwhitesell 9y ago
        It's different because a load balancer will send your initial HTTPS request to one application server, but when you're switching protocols (to UDP) you'll then want that traffic directed the same place. Or need some way to share session data across multiple app servers. You could handle it with some kind of cookie/token that enables the LB to route to the right place, but that opens a whole bunch of other complicated logic too. Whereas if the UDP application/server were able to handle it independently of HTTP(S), you wouldn't need any of that.
        mrmoka 9y ago
        UDP over IPv4 and IPv6 has source IP and source Port in header. This can be used for sticky routing through Load Balancers.
        edwhitesell 9y ago
        Sure, but in this context, unless you are able to use the same source port for TCP and UDP (and likely from the load balancer to the application server too) you'll still need another way to identify a client/session when switching from TCP to UDP. Doing that with NAT is even trickier. Take a look at the way some firewalls need to configure a DMZ for gaming, or SIP for some examples.
- edwhitesell 9y ago
  You could also handle the "handshake" elsewhere, like the application layer. This type of identification is already done in other UDP-based protocols, like RADIUS. UDP is arguably faster in some ways that is handled, provided the application load is managed well.
- jandrese 9y ago
  Putting UDP on top of TCP eliminates any possible benefit of using UDP.
feross 9y ago
This is nothing new. It's trivial to make website visitors DoS a target IP address using XHR requests, WebRTC, <img> tags, etc. WebUDP wouldn't necessarily make the situation any worse.
- rnhmjoj 9y ago
  Like the attack on GitHub a few years ago: https://www.eff.org/deeplinks/2015/04/china-uses-unencrypted-websites-to-hijack-browsers-in-github-attack https://www.eff.org/deeplinks/2015/04/china-uses-unencrypted...
- Ironlink 9y ago
  Seems to me that one key difference would be that giving javascript access to UDP sockets easily enables a single browser to send huge amounts of traffic since there's no ACK to wait for. With anything based on TCP, the attacker at least has to put some effort in to achieve that.
  - IshKebab 9y ago
    You could easily design it so that you can only send UDP packets to hosts you already have a TCP connection with.
mrmoka 9y ago
If it is implemented with handshake mechanics same as WebSockets, then it would be no more harmful than WebSockets.
- gafferongames 9y ago
  This is demonstrably not true.
TD-Linux 9y ago
It's definitely a concern! WebRTC solves this in two different ways: 1. The receiving end must consent to receiving packets by completing the DTLS handshake required by WebRTC. 2. The browser enforces SCTP congestion control to avoid spamming large numbers of UDP packets. Basically, it'll start throttling you when it detects packet loss.
- gafferongames 9y ago
  This sounds like a bad option for games played over wireless connections.

dsl 9y ago

Yes. The only way this could be done safely is if you are required to establish a TCP connection, and then "upgrade" it to UDP. There are too many pointy sticks that developers could impale themselves on, with the side effect of creating DDoS vectors.

deleted 9y ago
[deleted]
geofft 9y ago
Can you do it safely if you're required to make an HTTPS request to the same hostname with some standardized request (a la CORS preflight) and get an answer back saying "Yes, this origin may connect to me on these UDP ports", and then hang onto that permission indefinitely? The nice thing about having a persistent permission instead of an upgrade on each request is that a service worker that's woken up by a push notification or similar can immediately send UDP traffic instead of doing a TCP (+ HTTPS?) handshake. Since it's restricted by origin (probably using literally the same mechanism CORS uses) and over HTTPS, a malicious actor can't DDoS anyone but themselves. If you're really worried, maybe extend it to allow the server to limit the duration of the permission and the maximum bandwidth, but I think you don't need that. EDIT: Oh, oops, binding to the hostname doesn't help because you can just repoint your hostname in DNS at someone else. You'd ideally need to bind it to the IP, in which case you definitely want it to be a time-limited permission. (But I think that attack is also feasible, though a bit harder, with the handshake-before-each-UDP-connection model. Just have the attacker set up a custom DNS server for their domain, which for any hostname sends you a low-TTL response pointing to the attacker's HTTPS server, and then a higher-TTL response to the victim. Each user gets pointed at a random hostname within that domain.)
- jandrese 9y ago
  That model tends to be hell on firewall appliances and NAT/load balancing devices.
  - geofft 9y ago
    I'm not sure I follow - how is this different from, say, a native app (desktop or mobile) that's just using UDP like normal? There's a single preflight request per client device, which can usually be satisfied when you load the website itself.
    - edwhitesell 9y ago
      It's different because a load balancer will send your initial HTTPS request to one application server, but when you're switching protocols (to UDP) you'll then want that traffic directed the same place. Or need some way to share session data across multiple app servers. You could handle it with some kind of cookie/token that enables the LB to route to the right place, but that opens a whole bunch of other complicated logic too. Whereas if the UDP application/server were able to handle it independently of HTTP(S), you wouldn't need any of that.
      - mrmoka 9y ago
        UDP over IPv4 and IPv6 has source IP and source Port in header. This can be used for sticky routing through Load Balancers.
        edwhitesell 9y ago
        Sure, but in this context, unless you are able to use the same source port for TCP and UDP (and likely from the load balancer to the application server too) you'll still need another way to identify a client/session when switching from TCP to UDP. Doing that with NAT is even trickier. Take a look at the way some firewalls need to configure a DMZ for gaming, or SIP for some examples.
edwhitesell 9y ago
You could also handle the "handshake" elsewhere, like the application layer. This type of identification is already done in other UDP-based protocols, like RADIUS. UDP is arguably faster in some ways that is handled, provided the application load is managed well.
jandrese 9y ago
Putting UDP on top of TCP eliminates any possible benefit of using UDP.

feross 9y ago

This is nothing new. It's trivial to make website visitors DoS a target IP address using XHR requests, WebRTC, <img> tags, etc. WebUDP wouldn't necessarily make the situation any worse.

rnhmjoj 9y ago
Like the attack on GitHub a few years ago: https://www.eff.org/deeplinks/2015/04/china-uses-unencrypted-websites-to-hijack-browsers-in-github-attack https://www.eff.org/deeplinks/2015/04/china-uses-unencrypted...
Ironlink 9y ago
Seems to me that one key difference would be that giving javascript access to UDP sockets easily enables a single browser to send huge amounts of traffic since there's no ACK to wait for. With anything based on TCP, the attacker at least has to put some effort in to achieve that.
- IshKebab 9y ago
  You could easily design it so that you can only send UDP packets to hosts you already have a TCP connection with.

mrmoka 9y ago

If it is implemented with handshake mechanics same as WebSockets, then it would be no more harmful than WebSockets.

gafferongames 9y ago
This is demonstrably not true.

TD-Linux 9y ago

It's definitely a concern! WebRTC solves this in two different ways: 1. The receiving end must consent to receiving packets by completing the DTLS handshake required by WebRTC. 2. The browser enforces SCTP congestion control to avoid spamming large numbers of UDP packets. Basically, it'll start throttling you when it detects packet loss.

gafferongames 9y ago
This sounds like a bad option for games played over wireless connections.