New answers tagged

0

This means that websites have little incentive to start supporting DNSSEC, as a MITM can spoof a DNS record simply by not including a signature. This is incorrect. If a MITM attacker sends a result without a signature to a client that supports DNSSEC, the resolve will fail. This is because there is a signed DS record for that domain returned by the TLD's ...


1

Interesting video. In my opinion, to setup this kind on technique, you need to: 1) Own a domain name, say mysite.com 2) Each domain name has an "Authoritative name server". Usually the Authoritative name server are managed by the company that sold you the domain name. 3) You need to setup you own Authoritative DNS server on a public IP address, then ...


0

There is another risk using private / LAN IP addresses for public DNS records. Suppose you have a laptop user in your LAN, who uses web.company.com (which resolves for example to 192.168.178.10). If this user connects his laptop to another network (wifi!), and tries to use web.company.com, it will resolve to 192.168.178.1 using the public DNS entry. It may ...


3

DNScrypt encrypts the communication between you and the DNS provider. It hides your DNS queries from anyone trying to wiretap your traffic, but it does not hide your queries from DNS provider itself. The primary benefits I see are in situations where you are on an untrusted network (e.g. public hotspot, censored connection, malicious ISP, etc.) and you ...


0

To address the DNS leak issue, I'm certain you can obtain the IP address of your VPN provider that you are making the connection to and firewall off all outgoing connections heading to any other IP address on any port other than the specific IP and port being used by your VPN. That will prevent any "leaked" traffic from exiting your network. Done. After ...


1

From here: Disadvantages of DNSSEC DNSSEC can add significant load to DNS servers – increasing costs and reducing efficiency of current DNS systems. It requires significant investment of resources on the part of TLD registry operators, domain name registrars, ISPs and hosting providers. “Bootstrap problem” – a minimum level of ...


4

The Chromium security team say: DNSSEC and DANE (types 2/3) do not measurably raise the bar for security compared to alternatives, and can be negative for security. DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to the same effect, and with a much more reliable and consistent delivery mechanism. (see https://bugs.chromium.org/...


4

First, I will point out that private information should not be posted in the public domain name system. However, for the obscure case this is actually needed DNSSEC now supports NSEC3 for zones, which prevents this kind of attack (Although is more expensive on the DNS query from my understanding of how NSEC3 works compared to plain NSEC). Edit: Didn't see ...


3

There are really two things you need to trust here: the DNS response's authenticity and privacy. Authenticity You can be reasonably sure of the authenticity of the data returned if all of the below are true: The site supports DNSSEC The site's TLD supports DNSSEC Your client checks DNSSEC - For a browser I recommend the extension at dnssec-validator.cz (...


3

Each production IP address has a unique hostname, which is predictable, consistent, deterministic, and entirely useless to anyone but a few engineers who I suspect can read these addresses like a map. These names matter a lot to those people; but for the rest of us we just care that it doesn't create new problems. That's where the XSS comes in, because ...


1

I suspect the security aspect (their second reason) is related to 1e100.net simply being different from the product domains (youtube.com, blogger.com, google.com). The fact that all servers identify by the same hostname is nice for simplicity (their first reason), but probably not significant for security. I'm not sure exactly what the threat profile is ...


1

This situation would not be possible in the first place. The certificate authority must verify that the person requesting a certificate for example.com actually owns example.com before issuing a certificate. If A is the owner of example.com, then B obviously isn't, assuming they are independent entities.


4

You shouldn't trust them. You may suffer from "DNS Leaking". Ideally, your computer should send DNS Requests through the VPN, but it may request it directly. Your IP address will be exposed. Anyone snooping on the connection to the DNS Server will see what site you are accessing. That also opens you up to the dangerous Man-In-The-Middle attack. Use DNSCrypt. ...


2

While using your own VPN you can increase your security, putting the DNS server on the side of the network of the VPN service, and forcing any DNS request going through it through your own local DNS service/proxy. The ISP/DNS provider of the server/network where the DNS is hosted can however log, intercept and modify your DNS queries. Setting up a DNS ...


7

No, you can't. It's as easy as you search information about "DNS leak" topic. When you use a VPN, you have the risk of a DNS leak. In other words, your DNS resolution will be made outside your VPN. Second, VPN server knows (in some way) who you are, where are you from and where you want to go. It's the same risk that exit nodes of Tor Network pose. ...


4

In order for that to succeed the server's hostname would have to match the certificate name. That means you would have to either get a CA to issue a cert as google.com (not likely to happen) or you would have to get a root cert from a CA you control and install that on the user's computer as a trusted CA certificate. Even then, many big web sites use ...


-2

If you are a technical person and also if you are security expert than you should not trust on any third party DNS. Because of there are so many websites and web-server , those are provides their services and also sell their data to another hackers for their profits. So If you have your own well prepared DNS and VPN then trust on yourself only.


-1

If you are using a VPN and that VPN is using a public DNS then your requests are most likely anonymous enough. The truth is that if they want to find you badly enough they will. Running your own DNS would be a bad idea as the requests being sent to a DNS with only one user would stand out as strange. I would say you should find the most popular DNS there ...


4

First of all I think the biggest thing that OP missed is that SSL/TLS negotiation happens first. Only AFTER safe connection is negotiated and validated, there can be any HTTP communication. HTTPS is a big misnomer, it's just your plain old HTTP only sent over completely independent SSL/TLS. If the real site has an SSL/TLS certificate, would that stop the ...


0

If you happen to have a certificate authority that will validate any certificates for any domain, that's when you have a huge problem. Prior to certificate pinning by the browsers that is done only to the domains that they have an interest in, everyone else has to depend on CAs' not behaving badly, which is why there is a repository of collated SSL certs ...


12

No, the DNS lookup does not tell the client if it should connect via HTTP or HTTPS. The browser decides that - if you enter an HTTP URL it will request without TLS on port 80, and if you enter an HTTPS one it will request with TLS on port 443. So it is the client, and not the server, that decides. If the server gets a request over a protocol it does not ...


56

The decision on whether to use HTTP or HTTPS is the client's. If the user goes directly to http://example.com, an attacker could simply hijack that connection and perform a man-in-the-middle attack. If the user goes directly to https://example.com, then the attacker must spoof the SSL/TLS connection somehow; doing so without showing the user an invalid ...



Top 50 recent answers are included