Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>One solution is to use TCP because it is immune to spoofing the source address over the open internet because of the <a href="http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml" rel="nofollow noreferrer">three-way-handshake</a> (<a href="http://www.linuxsecurity.com/resource_files/documentation/tcpip-security.html" rel="nofollow noreferrer">More information</a> on why TCP source address spoofing is <strong>impossible</strong>.). If you still want to use UDP, you could have a simulated three way handshake to begin the connection. A session id could then be added to each UDP packet. This will increase the connection overhead by 2 packets and a few bits per packet, however you will still gain from UDP's speed for the rest of the session when compared to tcp.</p> <p>However, using TCP or UDP as a <a href="http://en.wikipedia.org/wiki/Transport_Layer" rel="nofollow noreferrer">transport layer</a> still leaves you open to other attacks such as <a href="http://www.wireshark.org/" rel="nofollow noreferrer">Sniffing</a> and <a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack" rel="nofollow noreferrer">Man in The Middle</a> attacks using <a href="http://en.wikipedia.org/wiki/ARP_spoofing" rel="nofollow noreferrer">arp spoofing</a> or <a href="http://en.wikipedia.org/wiki/DNS_cache_poisoning" rel="nofollow noreferrer">dns cache poising</a>. Another problem is if both the attacker and the gamers are on the same local lan, such as a wireless network or another broadcast network then you are able to receive traffic regardless of the source/dest address and <em>ONLY THEN</em> does spoofing a three way handshake become possible (and an hmac can't help!). The best soltuion is to use <strong>SSL/TLS</strong> as your transport layer which solves all of these problems.</p> <p>You should not reinvent the wheal, but if you need to encrypt UDP for some reason you should use a Stream Cipher like RC4-drop1024 or even better a Block Cipher like AES 256 in <a href="http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Output_feedback_.28OFB.29" rel="nofollow noreferrer">OFB Mode</a>. This will save bandwidth over other modes of encryption because they round up to the largest block size. </p> <p>EDIT: Based on Marts comment for (Datagram Transport Layer Security)DTLS I did some digging and I found there is an <a href="http://tools.ietf.org/html/rfc4347" rel="nofollow noreferrer">official RFC</a> and its supported by OpenSSL and should be exposed using the <a href="https://launchpad.net/pyopenssl" rel="nofollow noreferrer">pyOpenSSL</a> library. I recommend using the RC4-SHA cipher suite to reduce overhead, this suite is supported by SSL 3.0 (newest). However DTLS will probably have more overhead (LAG!) then TCP. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload