151–160 of 195 posts
“...for privacy...” and “Google runs one...” Strikes me as funny. Interesting concept apart from this detail though. Are there any servers that aren’t owned by advertisers and the like?
people invented other security things inside of dns protocol to avoid having the added bandwidth. i dont think it's reasonable to say that everyone can handle the increased load nowadays. However, i've been thinking of this, for enterprise, you could build a dns server which servers over TLS connections, and then put a local dns proxy on clients which receives on 127.0.0.1 and sends out tls to the custom dns server.…
IMO, the purpose of DOH is to address semi hostile environments like the free Wifi at the Airport. It is kind of like a VPN for just your DNS traffic.
Yes, greater for security but still depends upon reliability of certificate authorities and ISPs. ISPs have the ability to issue the client a bogus certificate while they hold the real one in order to decrypt traffic. Why won't browsers allow the certificate's public key to be readable by javascript so that the remote server can verify the client has the correct certificate? This wouldn't be foolproof but it would si…
Making the public key of the remote available to JS wouldnt help because if you can't trust the identity of the remote server or integrity of the connection then you can't trust the javascript. Tor hidden services are secure because of the lack of human meaningful names. See: https://en.wikipedia.org/wiki/Zooko%27s_triangle
Thanks for Zooko's Traingle wiki. Hadn't seen that one before.
I am just wondering why would you want DNS over https instead of something like dnscrypt which would be dns over ssl ( I think opendns does this already) ?
"A server that is acting both as a normal web server and a DNS API server is in a position to choose which DNS names it forces a client to resolve (through its web service) and also be the one to answer those queries (through its DNS API service)."
https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-02
How might this affect users who block ads via DNS?
What about users who want the system DNS settings they have configured (e.g. /etc/resolv.conf) to be honoured?
I can clear browser DNS cache with a couple of keystrokes, but I am not using Chrome, Firefox, IE/Edge, Safari, Brave, Opera, etc.
How easy is it for a user to clear the DNS cache in the popular browsers?
The best "privacy, performance and security" for the user is achieved by using /etc/hosts. HOSTS (i.e., no DNS) will beat DNS on all three, every time. "Flexibility" was not mentioned as a criteria.
There is also the issue of "transparency" to consider. It is easy for the user to check their HOSTS file to see what are the current name to address mappings. How easy is it for the user to check what mappings are in the browsers DNS cache?
Fact: Many/most of the names looked up by a user repeatedly every day do not change by the hour, by the day, the week, month or even year.
As a user, I use HOSTS heavily, with appropriate ed scripts for fast automated modification. I use HOSTS for the transparency, control and speed. Any privacy or security benefit is a bonus.
Contrast: https://en.wikipedia.org/wiki/Fast_flux (need DNS or perhaps "DOH" for this to work)
Earlier quoted context omitted.
You don't even need SNI; the initial Server Hello, which contains the server's certificate (which contains the DNS name the certificate is issued for) is sent in the clear.
No longer true in TLS 1.3 as I understand it The ServerHello starts out by finishing key agreement and then (in the same message) it assumes its peer now knows the session key and encrypts the rest of the message, including Certificate.
(Essentially, the problem is that prior to requesting the certificate for X.com, you need to know that you're talking to X.com; a sort of authentication chicken and egg.)
Earlier quoted context omitted.
Who is the "someone else" in your case? Where does the someone else's hardware come from? OP mentioned this to get rid off e.g captive portals. Iodine requires a client and a server. Both belong to you, what is the problem here? That I use a network to transmit packets? We are not talking about installing iodine on someone else's computer!
Not sure if you're trolling, but the network is being accessed by bypassing the captive portal. The network is being accessed in a way that isn't permitted.
Earlier quoted context omitted.
But the premise was to circumvent crap such as captive portals. Doing that on your own computer (mostly in a public wlan), I don't see any reason against it.
In this case, you're potentially using the public wlan's router in an unauthorized manner.
Earlier quoted context omitted.
I would love this to catch on wildly! DNS through TLS means it's all end-to-end encrypted, DNS reflection attacks are harder, etc. The "why even have protocols" doesn't make sense. Protocol can be layered just fine (HTTP itself is a good example). DNS as it exists now is another random special snowflake that vendors need corresponding snowflake implementations for.
>DNS through TLS means it's all end-to-end encrypted I didn't say I'm against DNS being encrypted, even with TLS. I just hate that instead of doing the right thing (e.g. political battle with the government, opening a port on a firewall) people choose the laziest way: just tunnel it over HTTP. >Protocol can be layered just fine (HTTP itself is a good example) They can, but why do it? Just figure out a way to make you…
Earlier quoted context omitted.
No longer true in TLS 1.3 as I understand it The ServerHello starts out by finishing key agreement and then (in the same message) it assumes its peer now knows the session key and encrypts the rest of the message, including Certificate.
Interesting; do you have a reference? In particular, how does it complete key agreement without the certificate? The first thing that comes to my mind is that in order to build the encrypted connection, you need to know who you're building it with, i.e., you need the certificate. You could build an encrypted connection with just whoever is on the other end, and then exchange the cert, but I would wonder then how you…
So, firstly I'm going to say, go read the drafts for yourself https://tools.ietf.org/html/draft-ietf-tls-tls13-23 because I am pretty sure that's the most snarky response and also hey, it's right there, if I'm wrong that's a great place to start in proving so.
But then I'll answer your substantive question, because the answer is pretty interesting (and quite unlike earlier versions of TLS).
So, you are correct that we can (and TLS does) do DH without knowing who we're talking to, and that our problem is that although our session is encrypted and can't be eavesdropped, this seems useless because we don't know who the heck we're talking to, surely we can be subject to a Man in the Middle attack.
However, TLS 1.3 has a trick here, after sending Certificate the server sends CertificateVerify. CertificateVerify signs the entire key agreement (which we just did) with the identity from the Certificate. So, a client receiving CertificateVerify either gets a matching signature (the party we did our DH key agreement with _was_ the owner of the Certificate - good) or they don't (we're being MitM'd the phone call is coming from inside the house - get out!)
Once the client has checked CertificateVerify (and presuming they're happy with whatever was inside Certificate) they're truly secure and Application Data can begin to be processed.