>they refuse to conduct proper studies on it out of sheer stupidity and stubbornness
Not stupidity and stubbornness. There is exactly zero money to be made from fasting. Much better to try to make some miracle compound and sell it for $50 per pill and bill it from insurers.
Now it seems they have also added fake lag to TCP port 80.
hlds@machine:~$ tcptraceroute -f 128 -m 128 thepiratebay.se 80
Selected device venet0, address 5.9.249.8, port 41774 for outgoing packets
Tracing the path to thepiratebay.se (194.71.107.15) on TCP port 80 (www), 128 hops max
128 thepiratebay.org (194.71.107.15) [open] 751.198 ms 735.700 ms 767.937 ms
This wasn't the case an hour ago. I was able to get 50ms RTT from TCP port 80 but now they probably added fake lag with tc(linux traffic shaping tool)
It's fake but his analysis is wrong. TPB is still somewhere in Europe. Otherwise you couldn't have 50ms RTT to thepiratebay.se TCP port 80 from within Europe.
I explained here how they do it http://news.ycombinator.com/item?id=5319720
Exactly. Here is a collection of route-servers and looking glasses which tell you what path a route from ISP x to IP y will take. http://www.bgp4.as/looking-glasses
You will see that every single route to 194.71.107.0/24 will travel through AS39138.
fale@machine:~$ tcptraceroute -f 128 -m 128 thepiratebay.se
Selected device venet0, address 5.9.249.8, port 40771 for outgoing packets
Tracing the path to thepiratebay.se (194.71.107.15) on TCP port 80 (www), 128 hops max
128 thepiratebay.org (194.71.107.15) [open] 51.673 ms 49.002 ms 47.187 ms
That server is in Germany, no way it's possible to have 50ms to NK. Also traditional traceroute has 500ms+ RTT.
They are faking/spoofing the ICMP responses.
They are also prepending their route advertisement with corresponding AS paths to further disguise it.
194.71.107.0/24 *[BGP/170] 02:10:36, MED 0, localpref 150, from 80.91.255.255
AS path: 2914 39138 22351 131279 51040 I
AS39138 is probably the real upstream provider of TBP. They peer with AS51040(TPB network) and TPB router prepends AS22351(Intelsat) and AS131279(North Korean ISP) into it's AS Path before advertising it to AS39138.
Hetzner's Xeon offerings with ECC aren't that expensive either: http://www.hetzner.de/hosting/produkte_rootserver/ex6
I would expect Softlayer to be more reliable than Hetzner as a service provider but that being said, the price difference is still huge.
I think it's a bit ironic given the nature of the talk that the link on the video page to seomoz.org has rel="nofollow" while comments down below don't have. No link juice for those who provide content(talk) and all the link juice for commenters.
Assuming DNS resolvers work as they should, most bitflips on the wire shouldn't result to anything else than a failed DNS query since DNS packets include the original requested FQDN in the result.
Scenario 1) Lets say we have normal Windows computer asking what is update.microsoft.com as an A-record. The computer's resolver sends its request to its ISP's DNS server it was assigned via DHCP. One bit is flipped on transit and the DNS server receives request to resolve update.mic2osoft.com and it does so. Then it returns the result via UDP telling the Windows computer that update.mic2osoft.com is 1.2.3.4, but the computer's resolver was expecting an answer for update.microsoft.com so it rejects(should reject) the result even though the transaction ID is what it expected. Also UDP checksum poses a problem the recursor could reject the packet and not do anything.
Scenario 2) Another scenario is where the bit corrupts on transit while the ISP's DNS recursor is querying the Verisign .com root servers for microsoft.com (assuming it's not cached) and one bit corrupts in transit. Verisign's server answers that mic2osoft.com DNS servers are ns1.mic2rosoft.com and ns2 and it provides the glue records for them (IP addresses) if necessary. DNS recursor receives an answer for mic2rosoft.com while it expects answer for microsoft.com and rejects the result before querying nsX.mic2rosoft.com. UDP checksum also a problem here.
Scenario 3) Bit flip on the Windows computer's RAM before gethostbyname() is called so they call gethostbyname(update.mic2osoft.com). Another timeframe for a successful bitflip is while the OS is running gethostbyname(update.microsoft.com) but before the request is sent. gethostbyname() only returns the IP address so the function caller will not know if its wrong. This is the most plausible scenario, ECC is also rare in consumer hardware so that shouldn't pose a problem.
Scenario 4) Bit flip on the DNS recursors RAM. This depends on whether the address to be queried is stored in several variables in the DNS server so the DNS answer packet to the Windows computer has the correct FQDN but the DNS server queried for the wrong address due to the bit flip. Servers usually have ECC so this is implausible but not impossible. Also if this happened, the DNS server's cache could also get the incorrect entry and give it out to many many many clients if it was a popular ISP's DNS server.
An interesting thought would be what if IP-addresses bit-flipped. If Microsoft had all their update servers in 80.100.2.0/24 and an attacker owned 16.100.2.0/24 with one bit flipped. How much traffic would the network receive? If bit flipped on transit while the server is returning answer for update.microsoft.com UDP checksum should be incorrect but what if a popular ISP's DNS recursor's cache had a flipped IP address for update.microsoft.com. Very implausible but would result in lot of traffic.
One more scenario comes to mind about IP bit-flipping. If ns1.microsoft.com was at 5.1.1.1 and an attacker owned 1.1.1.1 he could also configure his DNS server (more specifically the UDP stack on the Linux kernel) to ignore the invalid UDP checksums and serve falsified DNS answers.
It's already possible for amateurs to use an RC plane/drone without a line of sight, it's called FPV(first person view) piloting. They have a videocamera onboard and transmit the video signal into their VR googles. Then they control their plane with a normal radio controller.
Since electrical systems already exist for driving servos and other devices, all you need is a detonator and some explosives to make a lethal and accurate flying bomb that can be remote controlled from a distance.
I think the decision by Google to not buy Skype is great. Skype uses supernodes/decentralized address book and other trickery to keep the most of the load off their servers/NAT proxies. Whatever advantage Skype got from decentralization when it started in 2003 is now long gone. Bandwidth is ridiculously cheap and voice calls don't really take more than 16kbps with modern codecs.
If two Skype clients can't connect to each other directly due to NAT, they proxy the connection via supernode. Any Skype client with a public IP address can be a supernode, so they might use your bandwidth and computer to route calls.
Skype brand and userbase alone are not worth $8,5B. Their P2P decentralization technology is worth ~$0.
No one mentioned Mixrank in the comments, I like the idea. Maybe someday it will be one of those essential marketing tools like SEOmoz. I for one, am lazy and would prefer just mimic my competitors ads instead of making 10 different ads and A/B testing them.
Coverage seems quite narrow at least for .fi domains. They probably need to get some ad-crawler servers with IP addresses(according to GeoIP) from Finland or any other country they want to have coverage in.
Linux has tsocks and proxychains which override the connect() method with a LD_PRELOAD library and force traffic to go through a socks proxy. Easier than iptables since at least proxychains can be installed with apt-get on Ubuntu(don't know about other OSes).
Just a quick note. Make sure your VPS is Xen/KVM/Vmware and not OpenVZ or some other container based virtualization if you want to use OpenVPN since it needs access to tun/tap devices. On OpenVZ based virtual machines, the administrator has to specifically grant you that access, which might not be possible on a $1/month machine.
Assuming DNS resolvers work as they should, most bitflips on the wire shouldn't result to anything else than a failed DNS query since DNS packets include the original requested FQDN in the result.
Scenario 1) Lets say we have normal Windows computer asking what is update.microsoft.com as an A-record. The computer's resolver sends its request to its ISP's DNS server it was assigned via DHCP. One bit is flipped on transit and the DNS server receives request to resolve update.mic2osoft.com and it does so. Then it returns the result via UDP telling the Windows computer that update.mic2osoft.com is 1.2.3.4, but the computer's resolver was expecting an answer for update.microsoft.com so it rejects(should reject) the result even though the transaction ID is what it expected. Also UDP checksum poses a problem the recursor could reject the packet and not do anything.
Scenario 2) Another scenario is where the bit corrupts on transit while the ISP's DNS recursor is querying the Verisign .com root servers for microsoft.com (assuming it's not cached) and one bit corrupts in transit. Verisign's server answers that mic2osoft.com DNS servers are ns1.mic2rosoft.com and ns2 and it provides the glue records for them (IP addresses) if necessary. DNS recursor receives an answer for mic2rosoft.com while it expects answer for microsoft.com and rejects the result before querying nsX.mic2rosoft.com. UDP checksum also a problem here.
Scenario 3) Bit flip on the Windows computer's RAM before gethostbyname() is called so they call gethostbyname(update.mic2osoft.com). Another timeframe for a successful bitflip is while the OS is running gethostbyname(update.microsoft.com) but before the request is sent. gethostbyname() only returns the IP address so the function caller will not know if its wrong. This is the most plausible scenario, ECC is also rare in consumer hardware so that shouldn't pose a problem.
Scenario 4) Bit flip on the DNS recursors RAM. This depends on whether the address to be queried is stored in several variables in the DNS server so the DNS answer packet to the Windows computer has the correct FQDN but the DNS server queried for the wrong address due to the bit flip. Servers usually have ECC so this is implausible but not impossible. Also if this happened, the DNS server's cache could also get the incorrect entry and give it out to many many many clients if it was a popular ISP's DNS server.
An interesting thought would be what if IP-addresses bit-flipped. If Microsoft had all their update servers in 80.100.2.0/24 and an attacker owned 16.100.2.0/24 with one bit flipped. How much traffic would the network receive? If bit flipped on transit while the server is returning answer for update.microsoft.com UDP checksum should be incorrect but what if a popular ISP's DNS recursor's cache had a flipped IP address for update.microsoft.com. Very implausible but would result in lot of traffic.
One more scenario comes to mind about IP bit-flipping. If ns1.microsoft.com was at 5.1.1.1 and an attacker owned 1.1.1.1 he could also configure his DNS server (more specifically the UDP stack on the Linux kernel) to ignore the invalid UDP checksums and serve falsified DNS answers.
Seems like the author's DEFCON speak will be held next Sunday, he probably knows much much more about the subject than what I just wrote. I will definitely read his slides/whitepaper.
Not stupidity and stubbornness. There is exactly zero money to be made from fasting. Much better to try to make some miracle compound and sell it for $50 per pill and bill it from insurers.