Discussion:
Cloudflare & Apple & Fastly back a new DNS protocol separating DNS address lookups from those making them
(too old to reply)
Arlen Holder
2020-12-09 04:48:39 UTC
Permalink
Dateline today...

Cloudflare & Apple & Fastly back a new DNS protocol
separating DNS address lookups from those making them.

Verbatim from:
o Improving DNS Privacy with Oblivious DoH in 1.1.1.1
<https://blog.cloudflare.com/oblivious-dns/>

"Today we are announcing support for a new proposed DNS standard
co-authored by engineers from Cloudflare, Apple, and Fastly,
that separates IP addresses from queries, so that no single entity
can see both at the same time."

"Even better, we've made source code available,
so anyone can try out ODoH, or run their own ODoH service!"

Verbatim from:
o Cloudflare and Apple design a new privacy-friendly internet protocol
<https://techcrunch.com/2020/12/08/cloudflare-and-apple-design-a-new-privacy-friendly-internet-protocol/>

"Dubbed Oblivious DNS-over-HTTPS, or ODoH for short,
the new protocol makes it far more difficult for internet providers
to know which websites you visit"

"ODoH decouples DNS queries from the internet user,
preventing the DNS resolver from knowing which sites you visit."

Verbatim from:
o Cloudflare and Apple made a new DNS protocol to protect your data from ISPs
<https://www.theverge.com/2020/12/8/22163871/cloudflare-apple-dns-protocol-online-privacy>

"Whether it does or not depends on how creepy your ISP is"

"It's meant to help anonymize the information that's sent
before you even make it onto a website."

Verbatim from:
o Cloudflare, Apple, and others back a new way to make the Internet more private
<https://arstechnica.com/information-technology/2020/12/cloudflare-apple-and-others-back-a-new-way-to-make-the-internet-more-private/>

"Cloudflare, Apple, and content-delivery network Fastly
have introduced a novel way to fix that using a technique
that prevents service providers and network snoops from seeing
the addresses end users visit or send email to."

"The companies are working with the Internet Engineering Task Force
in hopes it will become an industry-wide standard."
--
One bug.... and the entire iOS house of cards completely falls down.
<https://groups.google.com/g/misc.phone.mobile.iphone/c/7Mc1sX9XISA>
Google handily proved iOS core code dating to 1985 was _never_ tested!
Melzzzzz
2020-12-09 05:02:42 UTC
Permalink
Post by Arlen Holder
Dateline today...
Cloudflare & Apple & Fastly back a new DNS protocol
separating DNS address lookups from those making them.
It's not protocol it's rather accessing dns via proxy, anonimizing,
I guess.
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Grant Taylor
2020-12-09 05:23:46 UTC
Permalink
Post by Melzzzzz
It's not protocol it's rather accessing dns via proxy, anonimizing,
I guess.
My impression -- based on a quick glance -- is that it's stock DNS over
HTTPS via a standard HTTP proxy using TLS security.

The article I skimmed called out that the HTTP proxy and the DoH
resolver can't be in cahoots with each other. So ... how can Cloudflare
as a proxy not be in cahoots with Cloudflare as the DoH provider?
--
Grant. . . .
unix || die
Melzzzzz
2020-12-09 05:30:25 UTC
Permalink
Post by Grant Taylor
Post by Melzzzzz
It's not protocol it's rather accessing dns via proxy, anonimizing,
I guess.
My impression -- based on a quick glance -- is that it's stock DNS over
HTTPS via a standard HTTP proxy using TLS security.
The article I skimmed called out that the HTTP proxy and the DoH
resolver can't be in cahoots with each other. So ... how can Cloudflare
as a proxy not be in cahoots with Cloudflare as the DoH provider?
Only if proxy isn't Cloudflares.
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
gamo
2020-12-09 12:52:33 UTC
Permalink
Post by Melzzzzz
Post by Grant Taylor
Post by Melzzzzz
It's not protocol it's rather accessing dns via proxy, anonimizing,
I guess.
My impression -- based on a quick glance -- is that it's stock DNS over
HTTPS via a standard HTTP proxy using TLS security.
The article I skimmed called out that the HTTP proxy and the DoH
resolver can't be in cahoots with each other. So ... how can Cloudflare
as a proxy not be in cahoots with Cloudflare as the DoH provider?
Only if proxy isn't Cloudflares.
The tangent question: Who really cares about the tech if the
ping 1.1.1.1
is way faster that
ping 8.8.8.8
? Yes, I know that that depends on the traffic and could be
reversed, but...
--
http://gamo.sdf-eu.org/
"What happens in EuroVegas it remains in EuroVegas"
Sjouke Burry
2020-12-09 13:12:34 UTC
Permalink
Post by gamo
Post by Melzzzzz
Post by Grant Taylor
Post by Melzzzzz
It's not protocol it's rather accessing dns via proxy, anonimizing,
I guess.
My impression -- based on a quick glance -- is that it's stock DNS over
HTTPS via a standard HTTP proxy using TLS security.
The article I skimmed called out that the HTTP proxy and the DoH
resolver can't be in cahoots with each other. So ... how can Cloudflare
as a proxy not be in cahoots with Cloudflare as the DoH provider?
Only if proxy isn't Cloudflares.
The tangent question: Who really cares about the tech if the
ping 1.1.1.1
is way faster that
ping 8.8.8.8
? Yes, I know that that depends on the traffic and could be
reversed, but...
Way faster? 18 and 20 msec here.
Javier
2020-12-09 13:45:01 UTC
Permalink
Post by Grant Taylor
Post by Melzzzzz
It's not protocol it's rather accessing dns via proxy, anonimizing,
I guess.
My impression -- based on a quick glance -- is that it's stock DNS over
HTTPS via a standard HTTP proxy using TLS security.
It looks like they want to stop people blocking ads, trackers, etc
based on /etc/hosts file.

https://someonewhocares.org/hosts/

For example, right now I block youtube on /etc/hosts, so I don't see
embedded youtube content. The aim looks to be to push all that crap
into everybody's throat.

The introduction of https had a similar effect back in the day, as it
made it difficult for end user to filter and proxy-cahe content.
Although it was truth that internet providers were abusing it, there
could have been a solution that made easier to proxy content.

The final aim of all this is to make the webpages to be like an android app.
Melzzzzz
2020-12-09 17:05:11 UTC
Permalink
Post by Javier
Post by Grant Taylor
Post by Melzzzzz
It's not protocol it's rather accessing dns via proxy, anonimizing,
I guess.
My impression -- based on a quick glance -- is that it's stock DNS over
HTTPS via a standard HTTP proxy using TLS security.
It looks like they want to stop people blocking ads, trackers, etc
based on /etc/hosts file.
How they can do that? You block add site way before you make dns query...
and afterwards you can clean page from crap when you receieve it.
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Grant Taylor
2020-12-09 18:02:52 UTC
Permalink
Post by Melzzzzz
How they can do that? You block add site way before you make dns query...
Yes and no.

The application typically asks the host resolver to resolve a name to an IP.

Nothing prevents the application from doing it's own DoH based
resolution before asking the host to resolve, if it asks the host to
resolve.

The host resolver is what (typically) checks the hosts file before doing
a DNS query.
--
Grant. . . .
unix || die
Peter Köhlmann
2020-12-09 17:17:45 UTC
Permalink
Post by Javier
Post by Grant Taylor
Post by Melzzzzz
It's not protocol it's rather accessing dns via proxy, anonimizing,
I guess.
My impression -- based on a quick glance -- is that it's stock DNS over
HTTPS via a standard HTTP proxy using TLS security.
It looks like they want to stop people blocking ads, trackers, etc
based on /etc/hosts file.
https://someonewhocares.org/hosts/
For example, right now I block youtube on /etc/hosts, so I don't see
embedded youtube content. The aim looks to be to push all that crap
into everybody's throat.
The introduction of https had a similar effect back in the day, as it
made it difficult for end user to filter and proxy-cahe content.
Although it was truth that internet providers were abusing it, there
could have been a solution that made easier to proxy content.
The final aim of all this is to make the webpages to be like an android app.
install pihole on a raspberry3 (or better a raspi4) and be done with it.
And works better than adblockers
Grant Taylor
2020-12-09 18:04:33 UTC
Permalink
Post by Peter Köhlmann
install pihole on a raspberry3 (or better a raspi4) and be done with it.
Except that the way that I've seen people using DoH can actually thwart
things installed by the local administrator to filter like this.
Post by Peter Köhlmann
And works better than adblockers
Potentially.
--
Grant. . . .
unix || die
Grant Taylor
2020-12-09 18:01:14 UTC
Permalink
Post by Javier
The introduction of https had a similar effect back in the day, as
it made it difficult for end user to filter and proxy-cahe content.
Although it was truth that internet providers were abusing it, there
could have been a solution that made easier to proxy content.
Energetic people can still filter HTTPS content. It's just more
difficult and requires a TLS bump-in-the-wire proxy and creating new
certs with a root certificate that the clients trust. Think enterprises
or BOFH home networks.
--
Grant. . . .
unix || die
Javier
2020-12-10 14:28:47 UTC
Permalink
Post by Grant Taylor
Post by Javier
The introduction of https had a similar effect back in the day, as
it made it difficult for end user to filter and proxy-cahe content.
Although it was truth that internet providers were abusing it, there
could have been a solution that made easier to proxy content.
Energetic people can still filter HTTPS content. It's just more
difficult and requires a TLS bump-in-the-wire proxy and creating new
certs with a root certificate that the clients trust. Think enterprises
or BOFH home networks.
Do you have a suggestion of which software to use for https caching?

From what I know, there is a way of avoiding tinkering with
certificates by forwarding https traffic to http, (as Elijah suggested
in an old thread in comp.misc) .

https://cern.ch ---> http://localhost:80/https://cern.ch

Changing the domain name avoids problem with certificates . But it
would need to convert the HTML documents and rewrite the links with
the new domain. It's simple but I don't know any piece of software
that does that.

I am not a protocol guru and I am quite lost at which software to use.
I guess somebody has already written an https to http gateway
rewriting html, but I am not aware of any working example.
Grant Taylor
2020-12-10 16:36:37 UTC
Permalink
Post by Javier
Do you have a suggestion of which software to use for https caching?
I did it about six years ago with Squid.
Post by Javier
From what I know, there is a way of avoiding tinkering with
certificates by forwarding https traffic to http, (as Elijah suggested
in an old thread in comp.misc) .
https://cern.ch ---> http://localhost:80/https://cern.ch
Are you going to have end users go to a new different URL? New URLs are
probably going to be prone to failure for various reasons.

Because doing anything with the existing URL is going to very likely
involve messing with certificates.
Post by Javier
Changing the domain name avoids problem with certificates . But it
would need to convert the HTML documents and rewrite the links with
the new domain. It's simple but I don't know any piece of software
that does that.
I've used Apache's mod_proxy and mod_proxy_html to do the URL rewriting
in the past. It's annoying, but not terrible, to configure. It worked
well for me and my customer who used it for years.
Post by Javier
I am not a protocol guru and I am quite lost at which software to use.
It really depends what you want to do. Your message has touched on
multiple pieces.
Post by Javier
I guess somebody has already written an https to http gateway rewriting
html, but I am not aware of any working example.
HTTPS to HTTP gateway implies messing with TLS. That could be a TLS
bump-in-the-wire utility like Squid, or it could be any standard HTTPS
web server with an alternate certificate. -- Though if you're
presenting a certificate to the user, you might as well do things over
it. -- It could also be something like Apache doing URL rewriting.
Though users need to initially connect to the non-encrypted version.
Some sites are HTTPS only and some browsers know about this. Chrome, et
al., comes to mind for Google resources.

I know that there are some more questionable tools (from a hat color
point of view) that play in this space. I'm not familiar with them.

There are some proxies that present HTTP and / or older HTTPS with
looser security parameters for older browsers and retro computing
intentions.

There are a lot of ways to address this. But my choice would be Squid
TLS bump-in-the-wire. Or at least it was about six years ago.
--
Grant. . . .
unix || die
Javier
2020-12-11 02:27:13 UTC
Permalink
Post by Grant Taylor
Post by Javier
Do you have a suggestion of which software to use for https caching?
I did it about six years ago with Squid.
Post by Javier
From what I know, there is a way of avoiding tinkering with
certificates by forwarding https traffic to http, (as Elijah suggested
in an old thread in comp.misc) .
https://cern.ch ---> http://localhost:80/https://cern.ch
Are you going to have end users go to a new different URL? New URLs are
probably going to be prone to failure for various reasons.
Because doing anything with the existing URL is going to very likely
involve messing with certificates.
Post by Javier
Changing the domain name avoids problem with certificates . But it
would need to convert the HTML documents and rewrite the links with
the new domain. It's simple but I don't know any piece of software
that does that.
I've used Apache's mod_proxy and mod_proxy_html to do the URL rewriting
in the past. It's annoying, but not terrible, to configure. It worked
well for me and my customer who used it for years.
Post by Javier
I am not a protocol guru and I am quite lost at which software to use.
It really depends what you want to do. Your message has touched on
multiple pieces.
Post by Javier
I guess somebody has already written an https to http gateway rewriting
html, but I am not aware of any working example.
HTTPS to HTTP gateway implies messing with TLS. That could be a TLS
bump-in-the-wire utility like Squid, or it could be any standard HTTPS
web server with an alternate certificate. -- Though if you're
presenting a certificate to the user, you might as well do things over
it. -- It could also be something like Apache doing URL rewriting.
Though users need to initially connect to the non-encrypted version.
Some sites are HTTPS only and some browsers know about this. Chrome, et
al., comes to mind for Google resources.
I know that there are some more questionable tools (from a hat color
point of view) that play in this space. I'm not familiar with them.
There are some proxies that present HTTP and / or older HTTPS with
looser security parameters for older browsers and retro computing
intentions.
There are a lot of ways to address this. But my choice would be Squid
TLS bump-in-the-wire. Or at least it was about six years ago.
The only user would be me. This is a personal thing. The aim of it
is to keep a history archived of what I browse. This is specially
useful when webpages vanish, or when people rewrite history.

This is more or less like archive.org. But I would like to be able to
access content in a manner that is filesystem transparent. I don't
know if squid is fileystem transparent with archived content.

Apache sounds like a good idea to serve the content over http or https.
And it would be able to modify content before it reaches the browser.

I guess nobody proxies https because of the complexity. The problem
is complex if you want to cover all cases. For example, https
webpages where you need to be logged in. In that case it is necessary
to tinker with certificates.

I think the way to make things easier is to try to cover only simple
cases, i.e. avoid js, avoid pages that need log in. I guess if those cases
are avoided the problem of caching https is much easier to handle.
Jasen Betts
2020-12-11 10:30:50 UTC
Permalink
Post by Javier
Post by Grant Taylor
Post by Javier
The introduction of https had a similar effect back in the day, as
it made it difficult for end user to filter and proxy-cahe content.
Although it was truth that internet providers were abusing it, there
could have been a solution that made easier to proxy content.
Energetic people can still filter HTTPS content. It's just more
difficult and requires a TLS bump-in-the-wire proxy and creating new
certs with a root certificate that the clients trust. Think enterprises
or BOFH home networks.
Do you have a suggestion of which software to use for https caching?
From what I know, there is a way of avoiding tinkering with
certificates by forwarding https traffic to http, (as Elijah suggested
in an old thread in comp.misc) .
https://cern.ch ---> http://localhost:80/https://cern.ch
Changing the domain name avoids problem with certificates . But it
would need to convert the HTML documents and rewrite the links with
the new domain. It's simple but I don't know any piece of software
that does that.
It's not simple, pages include javascript, therfore it's actually
impossible. See "the halting problem"
--
Jasen.
Continue reading on narkive:
Loading...