3 ms·

I actually do stuff like this, in the connection request packet a mix of "additional data" protected by the AEAD as well as encrypted data (keys), allows me to

I actually do stuff like this, in the connection request packet a mix of "additional data" protected by the AEAD as well as encrypted data (keys), allows me to quickly reject stale tokens because the expire timestamp is public, but protected with signature check, vs. having to fully decrypt first to see the token is stale. I don't have any defined port because in the game industry we tend to run multiple game servers on the same box, so we take up a bunch of ports. I acknowledge that this could cause issues with corporate firewalls, and would be open to ideas how to solve this. Regarding P2P, I think WebRTC solves the problem of browser to browser communication just fine. Any attempt to support p2p this would just end up rewriting WebRTC. What I'm trying to do is solve just one small part of the problem, in a WebSockets like way, just one thing that would enable a lot of other cool things to be built on it, if it were adopted by browsers. cheers

irq-1 10y ago
> quickly reject stale tokens because the expire timestamp is public, but protected with signature check A forged timestamp would still need a signature check, but a clear-text token would not. The speed difference would only be important with a flood of forged packets, each of which would need to have it's signature checked. Additionally, each system could implement a different type of defense: like issuing regional clear-text tokens, or A/B tokens to find which account is leaking a clear-text token, or giving each server it's own token so a DDOS attempt that wanted to force signature checks would need to get the right token (and get it again when an attacked system changes it.) Hosting providers that offer DDOS protection today could offer integrations based on clear-text tokens that wouldn't need any interaction from a game system (other than submitting the clear-text tokens.) I don't know if routers typically have the ability to check a signature, but they can probably drop packets that don't pass a (clear-text token) mask check. The port issue is interesting. Maybe a range of ports (44300-45100) would work for network administrators. Maybe there should be restrictions and a listing of uses like the first 1024 (this is voice, that port's video, file transfer, etc...) Browsers should also limit connections. Only 2 connections/IPs at a time? Only JavaScript from the origin domain (the address in the URL) can open connections, not advertisements or iframes. Maybe ask the user to open connections like browsers ask to use your location or audio/video. I wonder too if a browser should only open a connection when presented with a request signed using the (private) domain SSL cert? That would drastically reduce the ability of bad JavaScript to co-opt browsers of a website (into a DDOS of connection requests.) To use a websites traffic for a DDOS, you would need the SSL keys. Browsers could also be required to add the domain and verified domain sig to a connection request, so a website that cause a DDOS would be identified. I'm not sure identifying the website would lead to accountability since they may have been compromised, but it would prove which domain caused a browser based DDOS; reddit.com couldn't claim a bad advertisement caused their millions of browsers to open connections. This wouldn't stop forged packets, but it should stop innocent web-browsers from becoming a tool for DDOS.

irq-1 10y ago

> quickly reject stale tokens because the expire timestamp is public, but protected with signature check A forged timestamp would still need a signature check, but a clear-text token would not. The speed difference would only be important with a flood of forged packets, each of which would need to have it's signature checked. Additionally, each system could implement a different type of defense: like issuing regional clear-text tokens, or A/B tokens to find which account is leaking a clear-text token, or giving each server it's own token so a DDOS attempt that wanted to force signature checks would need to get the right token (and get it again when an attacked system changes it.) Hosting providers that offer DDOS protection today could offer integrations based on clear-text tokens that wouldn't need any interaction from a game system (other than submitting the clear-text tokens.) I don't know if routers typically have the ability to check a signature, but they can probably drop packets that don't pass a (clear-text token) mask check. The port issue is interesting. Maybe a range of ports (44300-45100) would work for network administrators. Maybe there should be restrictions and a listing of uses like the first 1024 (this is voice, that port's video, file transfer, etc...) Browsers should also limit connections. Only 2 connections/IPs at a time? Only JavaScript from the origin domain (the address in the URL) can open connections, not advertisements or iframes. Maybe ask the user to open connections like browsers ask to use your location or audio/video. I wonder too if a browser should only open a connection when presented with a request signed using the (private) domain SSL cert? That would drastically reduce the ability of bad JavaScript to co-opt browsers of a website (into a DDOS of connection requests.) To use a websites traffic for a DDOS, you would need the SSL keys. Browsers could also be required to add the domain and verified domain sig to a connection request, so a website that cause a DDOS would be identified. I'm not sure identifying the website would lead to accountability since they may have been compromised, but it would prove which domain caused a browser based DDOS; reddit.com couldn't claim a bad advertisement caused their millions of browsers to open connections. This wouldn't stop forged packets, but it should stop innocent web-browsers from becoming a tool for DDOS.