A core mission of cryptostorm is ensuring consistent, reliable network security with minimal fuss & drama. From DNS-based services like our DeepDNS in-browser native .onion/.i2p site access, through grounbreaking research on IP6 leakblocking, & to firewall-based structures to enable "fail-closed" security, this is where we discuss & develop cryptostorm-style leakblock tech.
5 posts • Page 1 of 1
I suspect this was actually a result caused by the webRTC browser IP leak - because we've had testers confirm that ipleak.net was (wisely, and appropriately) doing a webRTC call as part of their test suite. That'd explain why you were showing cryptostorm IPs (all of your tunnelled traffic) and then also your physical IP (errant, improperly-routed webRTC UDP packets heading to brower-project STUN servers) at the same time.lordsatch wrote:Hello, Using the latest Windows client, unfortunately, I have IP leaks going on, with original IP continually showing up at ipleak.net as well as the Cryptostorm Iceland address. Is there no DNS leak protection in your client?
Either follow one of the "how to turn off webRTC in your browser" tutorials or apply our browser-agnostic bugfix that blocks webRTC IP leaks at the network stack on Windows machines. Then run the leaktest again, and I suspect you will see only cstorm's IPs now.
To be clear, we really can't do much at the cstorm network level to stop browser-based IP leaks. Here's a metaphor: let's say you want to make sure that nobody walks out of your house with your favourite My Little Pony stuffed pony. You lock the doors and windows, and you watch whether people coming and going have said pony in their hands as they try to leave. This is sorta like an encrypted tunnel (sorta).
However, if someone walks out with the pony inside a box they carried in, your search criteria will fail and pony will be gone: you see a box going out, and that's not a pony.
The box is the browser's application-layer communications with the world beyond cstorm's nodes. What's inside that box could include your physical IP address - it'll tunnel right thru cstorm, and out to its destination. We can't stop that at cstorm, unless we start opening and searching everyone's boxes (packet payloads) which of course is contrary to our mission of secure packet transit.
Or think of this: you sit at your computer and send an email to someone saying "my IP address on this PC is xxxx" and hit send. The person gets the email and knows your IP... was that a cstorm "IP leak?" Not really, because we don't search your outbound emails.
The metaphors aren't perfect, as at least part of the webRTC leak was caused by packets errantly pushing outside the tunnel and thus bypassing cstorm altogether... like a house visitor who can walk through walls, and leaves with your pony through the wall from the bathroom. Who's going to be checking for people who can walk through walls, right?
Anyway, there's my own advice.