Replies (53)

DNS is name resolution. The internet doesn’t know what Google.com is. It only knows IP addresses. So when you go to a site the request has to go to a resolver to figure out what the IP address is and then direct you to it. When half of the internet breaks because cloudflare is down, that’s DNS. DNS doesn’t reveal content but it does reveal intent. Where are you going? Gmail? Porn Hub? When you connect to WiFi a lot of things happen in the background in order. Gets network settings. System processes and apps immediately start resolving domains. Finally your VPN app finish starting and take over routing. If DNS is not explicitly forced into the VPN, those early lookups go to whatever DNS the WiFi handed out. Hotel. Airport. That is the leak.
I would not trust my VPN providers leak tester. Nothing against mullvad just a matter of principle to separate testing from the service itself.
I don’t think you are hearing me. That test is telling you the status NOW. Not at connection. Leaks happen: - During network join - During captive portal checks - During OS service startup - Before the VPN hooks routing and DNS By the time you’re connected and run this test, the damage may already be done.
I ran an extended test but don’t understand what these results mean. 6 queries. Progress just says ……. for all of them. Servers found is 1 for all queries. Host name says none.
- Enable VPN kill switch so it blocks all traffic when the tunnel is down - Set the VPN as default route before network comes up (always on VPN) - Disable OS fallback DNS and captive portal probes if possible - Push DNS through the tunnel explicitly (VPN provided DNS or your own over the tunnel) - Possibly overkill but useful for peace of mind. Block port 53 outside the tunnel with firewall rules If DNS can’t reach anything unless the VPN interface is up, then it’s working. I’ve covered this a couple of times but the confusion is making me think this is one of those times when I think I’m being clear but I’m actually not. I might have to write a guide just for this question.
You have to compare connected and unconnected to VPN. Every single result should be different. Any matching address is a leak. Make sure to shut down every naughty VPN only thing before disconnecting.
Yeah a lot of this is going over my head. A guide would be helpful because idk what most of these things are.
Meaning the kind of things you definitely don't want your ISP to see. For example don't forget to turn off your torrents before disabling your VPN.
Yeah I'm not following. Are there any guides or resources/video tutorials on this subject that explain this from the beginning? I've heard about DNS problems and how cloudflare is evil before but it's time I actually learn about it.
Why do you recommend not caring? Why is DNS not that important? Is it because they still can't see what you do on the website but just know that you accessed that website?
See I wanna try to strike that balance well because I tend to obsess and go paranoid over the tiny details. To the point where it negatively affects my life.
This reminds me of something. Sometimes my browser blocks websites that don't have https. But it is random. If I enter the website despite the warning, it ends up redirecting to https anyway. Is that a malicious decision by the website owner?
As a driver, it's better to understand the mechanics of how an engine works than not. But if you don't it doesn't really matter.
Normally browsers only warn if a site doesn't employ HTTPS. Most browsers, however, actively block access if the site has an expired or self signed certificate. You can normally bypass this on the advanced tab shown on the browsers window. It is common for self hosted sites to use self signed certificates.
Yeah that's how I would bypass it using advanced but after I bypass, it says https. Never understood why that happened and just assumed the website was retarded. But this DNS talk makes me think maybe they're trying to find a leak or something.
A central issued certificate is using trusted private keys from an organisation like: A self signed certificate is like your NOSTR set of keys, completely secure encryption, but you're trusting an unknown signer. N.B. On NOSTR, you are using your keys to sign your posts. But nobody knows who you are on a website SSL certificate. As for DNS, apart from the idea of using DNS servers NOT supplied (and therefore monitored) by your ISP. There are two security layers available: 1. Encrypted DNS, just under 50% of DNS traffic is encrypted 2. DNSSEC, or signed DNS, meaning the information provided has been signed by the DNS authority to be valid, meaning it can't be spoofed by a man in the middle attack. This has a very low adoption rate, as you can see below at less than 5%, as reported by my NextDNS control panel. image
I want to try again with the explanation. i.e. If you can't understand, it's my fault. DNS encryption ensures nobody, but you, can see your traffic. DNS signing proves the data you receive is the same that was sent. A central key issuer, like LetsEncrypt is considered more trusted than an individual key issuer, like you, because their keys can be verified against a known organisation. So a company with a reputation has verified you are valid.
For the last part, I'd say it's more like this: The server needs a public/private key pair to set up the key exchange for HTTPS. Before DNSSEC+DANE (which no one implements... ugh), there was no secure way to know if a public key of a server is really that server, or a malicious actor in the middle pretending to be them. So, certificate authorities (CA) were created, which try to do secure checking of you owning the domain name before giving you a certificate saying "This public key is trusted for this domain". And your OS vendor trusts a certain set of CAs that they know is good and reliable, but not just anyone, because any trusted CA could spoof any website they want, like google.com. With newer CAs like Let's Encrypt the ownership checking is automated and they check your DNS from multiple random points on the internet to ensure there is no one tampering.
Or, even simpler, it is similar to this: You want to talk to John Doe on Nostr. The problem is anyone can pretend to be John. So, someone says "I will check your ID that you are John Doe, and I will give you a badge that I checked". Your client implements a list of trusted checkers, and when you search for John Doe, only the verified npub appears. The others get a big scary warning "This may not be John Doe". The client only trusts checkers that adhere to a given standard and have reputation, to prevent bad actors from being able to issue fake badges for anyone. This is how HTTPS works but instead of npubs it is servers' public/private keypairs, and instead of people it is domain names, and badges are certificates
@MAHDOOD I wrote the guide covering why you should care, how to do it, and how to test it. It ended up being longer than I expected (roughly 40 pages). Too long for an article and even too long for a field manual. I decided to sale it to try and recoup some operating expenses. Since you inspired the guide you will get a free copy. I’ll DM you a link once it goes live.