@imdb -- OK, thanks for confirming that. I didn't want to go though removing and recreating the exception. Or finding another site that I trust that uses a self-signed certificate. But the lesson here, I think, is that HTTPS Everywhere apparently didn't force Firefox to hit only https://www.wilderssecurity.com/ and instead defaulted to https://www.wilderssecurity.com/ silently. Given that its database knows that Wilders uses a self-signed certificate, I would have expected that it would have refused to connect until the user created an exception. Or at least warn the user. Maybe @Brosephine can share what it actually did.
Nothing happend. My browser has been acting strange for a bit now and many sites aren't secure. I think infected in some way. Hopefully it's not a fellow Wilder haha
Yes, you're less secure Browse https://www.wilderssecurity.com/ and you should see "This Connection is Untrusted". Click on "I understand the Risks", and then hit the "Add Exception" button. Then hit the "Confirm Security Exception" button. If you do this in private browsing mode, the exception will be temporary. If you don't see the "This Connection is Untrusted" page, disable HTTPS Everywhere, and try it again. You can see what exceptions you've created at http://about:preferences#advanced on the "Certificates" tab. Hit the "View Certificates" button.
Hello All: Great stuff @mirimir Test Setup: Windows 10, Firefox 44.0.1. VPN connection through Private Internet Access (PIA). Using the "IP Address" test section of https://www.browserleaks.com/, through a Private Internet Access (PIA) connection, I was able to 'see' from the test results that the true public/WAN IP address at the client system's geographic/residential location was definitely exposed. Ergo keeping a resident's WAN address anonymous through PIA is not currently possible using Firefox/Chrome browsers. Oddly enough though, IE 11 and Opera 12.17 did not pass the WAN IP address. Repeating the test with Tor Browser 5.5.1 (instead of Firefox) through PIA seemed to assure anonymity by not disclosing the residential WAN IP address. Also, simply repeating the test with only the benefit of the Tor Browser (No VPN connection through PIA) definitely did not reveal the origin's WAN IP address. Cheers
@1PW that leak is due to webrtc api of gecko and chromium-based browsers. the reason why tor browser doesn't leak is because webrtc is disabled by default in it.
I'm finding that Safari in OSX won't even connect to https://panopticlick.eff.org/ Any idea why? And yes, IE in Windows 10 isn't vulnerable to the WebRTC leak.
Hello mirimir: I am able to connect okay to https://panopticlick.eff.org/ with Safari Version 9.0.3 (11601.4.4) which is part of a OS X El Capitan 10.11.3 in a MacBook Pro. Thank you for the IE 11 vs webRTC information too. HTH
Thanks. Safari in a Yosemite Zone VM wasn't connecting. Maybe it's a new feature. Panopticlick does use emulated tracking apps.
Tried to resist jumping on this but feel like a comment is worth the time to post. The most sure fire way to protect yourself while at an HTTPS connected website is to either manually or via "auto scripting" make a definite CONFIRMATION of the cert fingerprint being used during your connection. e.g. - here is the sha256 fingerprint for here at Wilders. 028:E3:1E:75:96:BD:3F:89:47:6A:38:98:6D:65:CC:58:E7:C0:B2:64:56:97:47:50:A3A:4E:C4:B3:CF:57 Wilders has published the site's official cert fingerprint so we have and know it for sure. Now when you make the connection but before logging in with your CREDENTIALS you can view the EXACT fingerprint the brower is using. Not trying to get overly technical here, but in order to produce the needed fingerprint the hosting website (REAL WILDERS or a MITM fake) MUST have control and access to the private key that produced the cert. Maybe pgp/gpg would be a good reference for you. Anyone can get access to a public key, which is why they are called public. But only the private key will produce the needed matching fingerprint. If the fingerprint matches its either TRUE Wilders or their site has been completely and absolutely PWN'd with their total private key being compromised. As others have mentioned, MITM is not that tough even for https connections, but a matching fingerprint is NOT going to happen except on a total site PWN.
I've finally finished the guide. Some version of it will eventually show up on iVPN's site, if they like it. But I want to share the tl;dr about WebGL here, because it's a huge risk in using VMs and VPNs to compartmentalize. WebGL uses the OS graphics driver to access the machine's GPU. Given that, all WebGL-capable browsers on a given system will have the same WebGL fingerprint. You can verify that using https://panopticlick.eff.org/ Using a VPN service doesn't change the WebGL fingerprint. Neither does using Tor, unless you use Tor browser, which has been hardened to block WebGL fingerprinting, and otherwise to report the same fingerprints for all users. Anyway, I recommend blocking WebGL. In Firefox, for example, open "about:config" and toggle "webgl.disabled" to "true". In NoScript options, check "Forbid WebGL" in the "Embeddings" tab. It also seems that systems using a given graphics driver will have the same WebGL fingerprint on given hardware, with a given GPU. Reinstalling the OS, or using a related OS with the same graphics driver, won't change the WebGL fingerprint. It's possible that changing graphics drivers (e.g., default vs proprietary) will change the WebGL fingerprint, but I haven't checked that yet. It's also possible that a given OS and graphics driver will have the same WebGL fingerprint with a given GPU, even on different hardware. Anyone know? This is clearly the case for VMs using the default virtual GPU. For example, all browsers on Debian and Lubuntu VMs have the same WebGL fingerprint. But other OS (unrelated Linux distros, FreeBSD, Windows and OSX) have different WebGL fingerprints. So be careful if you're compartmentalizing in multiple VMs, hitting the Internet via VPN chains and Tor. At minimum, make sure WebGL is blocked. Better, use unrelated OS for different compartments. So far, I know that these have different WebGL fingerprints: Debian family, ArchBang, Fedora, PCBSD, IOS (Yosemite Zone) and Windows 10. All Debian family distros seem to have the same WebGL fingerprint. That may be the case for other sets of related distros. Or use Whonix VMs. But there, you're relying on Tor browser to block WebGL. However, the host and VMs use different GPUs (real vs virtual) so there is no overlap in WebGL fingerprints. I don't believe that VMs can actually access the host GPU directly. Enabling video acceleration in a VM doesn't change the WebGL fingerprint.
OK, so I've just seen this: http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ I'll describe how to configure frequently changing IPv6 addresses soon, for better privacy. None of this is relevant unless IPv6 is enabled on any network interface. Including VPN tunnels. Edit: Upon reflection, this can wait. There's still no need for IPv6, as far as I know. The challenge would be to ensure that the appropriate IPv6 address was used in various sorts of connections. The real MAC-based IPv6 for LAN stuff. A different faked IPv6 address for each VPN exit. Maybe for each session. And how will Tor eventually handle IPv6? A new IPv6 address for each circuit? Nontrivial stuff, there Privacy Extensions for Stateless Address Autoconfiguration in IPv6 https://tools.ietf.org/html/rfc4941 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) https://tools.ietf.org/html/rfc7217 http://docs.menandmice.com/display/MM/enable IPv6 privacy extension on Ubuntu Linux More about Debian: https://debian-handbook.info/browse/stable/sect.ipv6.html
What you guys recommend to avoid browser fingerprint? I use the extensions of my signature but I can not pass the test of the EFF. Thanks!
Install CanvasBlocker addon. Install Disable WebRTC addon. Install NoScript addon, and check "Forbid WebGL" in "Embeddings" tab, in options. Toggle "webgl.disabled" to "true" in about:config
Thanks for the info on ipv6 @mirimir - and, frankly, the laugh. I looked at ipv6 back in the day, and it's entertaining how little it's really progressed in terms of basics like scalability and privacy. I'm not aware of any important hosts that are ipv6 only, so what's the point? Hopefully your guide will elucidate.
I added [PLAIN]...[/PLAIN] to kill the smilies Also see https://www.dbshmc5frbchaum2.onion/Wilders_SHA-256_Fingerprint.html
Thanks! I did everything, but: I use: CanvasBlocker (original settings) Disable WebRTC HTTPS Everywhere Lastpass NoScript Privacy Badger Privacy Settings (Compatible mode) Self-Destructing Cookies Ublock Origin What is wrong?
I don't know. What do you get using IE? If this is a crucial issue for you, maybe try using Tor browser without Tor. See https://www.reddit.com/r/TOR/comments/2ywmji/is_it_possible_to_use_the_tor_browser_without/ for instructions.
@ExtremeGamerBR There are two things that make you stand out from the crowd: HTTP_ACCEPT Headers: if you don‘t mind, change your browser language to English only. At the moment it shows that you are supposedly from Brazil/ language Portuguese. This does not have to be true but there are considerably fewer people on the planet with this language setting, which makes it easier to track you. UserAgent: I can only assume that most people don‘t update their browser regularly so a UserAgent showing Windows and an older version of Firefox should fit in better with the crowd. At least I get about 6 bits of identifying information with this one: (Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0) Don't take it too seriously. A low score does not mean that you're invisible. Compartmentalization and using different personas like mirmir often advised is probably the best approach. Of course, there's Whonix and Tor, chained VPNs and so on but that's mirmir's playground. ;-)
"This webpage is not available ERR_NAME_NOT_RESOLVED The server at www.dbshmc5frbchaum2.onion can't be found, because the DNS lookup failed."
