Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS over HTTPS

github.com

Post reply on HN
Print view View original

141–150 of 195 posts

Re: DNS over HTTPS

#141

Post by alien_at_work »

gkya wrote: post #139
alien_at_work wrote: post #119

Earlier quoted context omitted.

>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…

Political battles are hard to do, and take time, sometimes very very long times they take.

I don't disagree at all. But I don't find this sufficient justification to engage in poor engineering practices.

DNS has a different set of use cases than HTTP so, while it can be made to work with enough effort (anything can), HTTP can never be as good at DNS as an actual protocol designed to do DNS can.

Re: DNS over HTTPS

#142

Post by kernelPan1c »

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 significantly beef up security.

Similar to how tor hidden services get resolved, distributed hash tables seem like the way to go. Take the ISPs and Cert Authorities out of the equation.

Re: DNS over HTTPS

#143

Post by gcr »

kernelPan1c wrote: post #142

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…

I thought modern browsers ship with pinned certificates for Google and other large companies built in to the browser download.

Re: DNS over HTTPS

#144

Post by gsich »

remedan wrote: post #130
gsich wrote: post #104

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.

You're still circumventing security measures to use somebody else's hardware in a way they clearly don't want you to. That's illegal in most cases.

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!

Re: DNS over HTTPS

#145

Post by half-kh-hacker »

cabaalis wrote: post #115
PakG1 wrote: post #89

Earlier quoted context omitted.

What's cromulent mean? I looked it up at dictionary.com and couldn't find anything. Or are you making up more words to point out the irony? :)

I wonder if you can use "cromulent" to guess the age of a person. Older people would not have watched the Simpsons in the early 90s. Younger people very likely missed this obscure episode. I would guess an age of the user to be 30-35.

I may be an outlier but as a seventeen year old, I'd already heard of 'cromulent' (from the Simpsons, but through Reddit).

Re: DNS over HTTPS

#146

Post by Someone1234 »

kernelPan1c wrote: post #142

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…

> Why won't browsers allow the certificate's public key to be readable by javascript

Because sites would randomly block reverse proxies, web proxies, enterprise users, people using certain WiFi APs, and it would give advertisers another thing to track users on.

Frankly after looking at what websites did with the User Agent, I'm scared to see what they'd do when a certificate mismatch occurs.

Re: DNS over HTTPS

#147

Post by lyk »

gsich wrote: post #144
remedan wrote: post #130

Earlier quoted context omitted.

You're still circumventing security measures to use somebody else's hardware in a way they clearly don't want you to. That's illegal in most cases.

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.

Re: DNS over HTTPS

#148

Post by 0xffff2 »

gsich wrote: post #104
pbhjpbhj wrote: post #79

Earlier quoted context omitted.

In USA and UK at least unauthorised access or use of a computer is criminalised. On some situations you can argue for assumed consent, the law doesn't operate on "if I can do it then it's authorised". Unless you can show you have permission then it's not authorised, ergo not legal. AIUI; not legal advice.

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.

Re: DNS over HTTPS

#149

Post by nly »

kernelPan1c wrote: post #142

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

Re: DNS over HTTPS

#150

Post by kernelPan1c »

gcr wrote: post #143
kernelPan1c wrote: post #142

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…

I thought modern browsers ship with pinned certificates for Google and other large companies built in to the browser download.

Public key pinning helps but it operates on the assumption that the initial key is the correct one. I find it curious that these public keys are not readable by the client.
Post reply on HN