I would wager that the crypto settings are done by some central IT organization within the school. Experience would suggest that the CS professors think the sys admins are a bunch of amateurs, and the sys admins probably think the professors are snobs with no appreciation of cost and "real-world" applications.
Should be fairly fast still in low traffic volume mode. The challenge is doing at scale.
With low volume traffic, the code spends most of it's time blocked waiting for the next packet so the response is very quick.
With high volumes, especially high volume of small packets, the code can get seriously backlogged and even miss packets altogether if the raw interface isn't serviced fast enough.
H/W acceleration is needed to do this at backbone volumes.
Once upon a time (over 10 years ago) I was working in the field of high-volume NIDS and keeping up with (then blazing fast) GiGE LAN volumes was very challenging with the CPU alone back then. And that was with tuned rule sets / minimal pre-processors / no other I/O in the hot path.
I took the undergraduate version of this class (at Stony Brook), the homework assignments were similar (usually, just the graduate version with a slightly lower bar to success - I partnered with a grad student so I had to do the graduate version.)
Our assignments were (1) a toy implementation of RSA, complete with the ability to generate SSL certificates (so, ASN.1 encoding, etc) using only a bignum library and (2) implementing a known buffer overflow attack on an old version of sendmail. ( http://web.nvd.nist.gov/view/vuln/detail?vulnId=CAN-2002-133... )
About 2 months ago -- for a presentation about being vigilant with your smartphone on public APs -- I implemented a toolkit that was essentially a man-in-the-middle/evil twin -- a single channel BSS analysis tool which allowed for broadcast and targeted deauth injection along with a probe request monitor, all in one interface, and a DNS spoofer in the other interface. I used HostAP for network spoofing. Its the simplest exploit but was very interesting building the demo and the kids enjoyed it!
This is another good little attack piece to shove in!
12 comments
[ 5.4 ms ] story [ 31.3 ms ] threadhttp://www.wired.com/2013/12/bgp-hijacking-belarus-iceland/
or more recently:
http://research.dyn.com/2015/03/uk-traffic-diverted-ukraine/
Don't know if its relevant to the submission :)
Something like scapy is perfect for this, I'm not sure about the speed though.
With low volume traffic, the code spends most of it's time blocked waiting for the next packet so the response is very quick.
With high volumes, especially high volume of small packets, the code can get seriously backlogged and even miss packets altogether if the raw interface isn't serviced fast enough.
H/W acceleration is needed to do this at backbone volumes.
Once upon a time (over 10 years ago) I was working in the field of high-volume NIDS and keeping up with (then blazing fast) GiGE LAN volumes was very challenging with the CPU alone back then. And that was with tuned rule sets / minimal pre-processors / no other I/O in the hot path.
Our assignments were (1) a toy implementation of RSA, complete with the ability to generate SSL certificates (so, ASN.1 encoding, etc) using only a bignum library and (2) implementing a known buffer overflow attack on an old version of sendmail. ( http://web.nvd.nist.gov/view/vuln/detail?vulnId=CAN-2002-133... )
https://web.archive.org/web/20140106173814/http://www.cs.sto...
About 2 months ago -- for a presentation about being vigilant with your smartphone on public APs -- I implemented a toolkit that was essentially a man-in-the-middle/evil twin -- a single channel BSS analysis tool which allowed for broadcast and targeted deauth injection along with a probe request monitor, all in one interface, and a DNS spoofer in the other interface. I used HostAP for network spoofing. Its the simplest exploit but was very interesting building the demo and the kids enjoyed it!
This is another good little attack piece to shove in!