171–180 of 195 posts
Earlier quoted context omitted.
In this case, you're potentially using the public wlan's router in an unauthorized manner.
What is authorized and what is not? It is (usually) not presented.
So what use does this have? DNSSEC already gives us validation of the records, and thanks to SNI, this doesn't give us any privacy. It is more complex, more centralized, and ends up slower than using actual DNS, and doesn't seem to provide any benefits. Am I missing something?
"... thanks to SNI, this doesn't give us any privacy." Assumption: All sites use SNI or will use SNI. True? Experiment: List all domains posted to HN (pages 1-20) that require https on any given day. Try accessing each one without SNI. Result: Most do not require SNI.
SNI has to be sent without any previous negotiation. Therefore the client does not know if a site will require SNI or not.
Assumption 1: browser vendors do not want to break sites relying on SNI
(Confirmed by WHATWG)
Assumption 2: at least one major site will continue to use SNI
Conclusion: browsers will continue to send SNI.
Earlier quoted context omitted.
No. All actors currently involved with the web are ideologically opposed to backwards incompatible changes, and, as a result, they'd never make a change that prevents a browser from accessing a legacy site. As result, SNI is here to stay.
This isn't how backwards compatibility works. A hypothetical encrypted SNI would be "optional" in the sense that your Firefox 57 wouldn't use it, but a site could implement it, and Firefox 73 could too and then the actual user of that actual site is protected by upgrading to FF 73. If you were right everything would still be HTML 4 over HTTP 1.1
This is why today your browser sends the SNI info even if the site will never need it.
And that also means for eternity all TLS1.3 or lower connections will continue to use SNI.
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.
I suspect it wouldn't be too hard for a nation state or similar to determine the signature of DNS over HTTPS requests to see if someone is making a DNS request, unless you add a bunch of noise to the transaction.
Doubt it. How can a DNS HTTP GET look that much different than a favicon.ico GET over TLS? MTU/size alone is all they can use to shape, but there are many small web requests.
> for privacy, performance and security. I understand the privacy and security aspects. But I am wondering - how can DNS over HTTPS be more performant in the case of curl commands? A browser could probably persist the connection to the resolver and issue several requests together, but with a single curl command surely there's the overhead of initiating the first DNS resolve, the HTTPS connection, the second DNS resol…
It is a recognized word, at least by the Cambridge [0], Oxford [1], and Wiktionary [2] dictionaries. [0] https://dictionary.cambridge.org/dictionary/english/performa... [1] https://en.oxforddictionaries.com/definition/performant [2] https://en.wiktionary.org/wiki/performant
Dictionaries are descriptive, not prescriptive.
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.
Earlier quoted context omitted.
"... thanks to SNI, this doesn't give us any privacy." Assumption: All sites use SNI or will use SNI. True? Experiment: List all domains posted to HN (pages 1-20) that require https on any given day. Try accessing each one without SNI. Result: Most do not require SNI.
Wrong. SNI has to be sent without any previous negotiation. Therefore the client does not know if a site will require SNI or not. Assumption 1: browser vendors do not want to break sites relying on SNI (Confirmed by WHATWG) Assumption 2: at least one major site will continue to use SNI Conclusion: browsers will continue to send SNI.
The client that I use assumes no SNI required. (It intentionally does not support SNI.) If it fails because the website is on a shared host and requires SNI, then it retries via a local SNI-enabled proxy bound to localhost.
"Conclusion: browsers will continue to send SNI."
Some clients/browsers will continue to send the domainname in the clear for every https url, even when it is not required.
Some users might consider that as sacraficing their privacy even when it is not necessary.
But not the client I use. It assumes no SNI is required, by default. It never sends the domainname in the clear for https when it is not necessary.