Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #221123 > unrolled thread
| Started by | Anil F Duggirala <anilduggirala@fastmail.fm> |
|---|---|
| First post | 2020-04-09 15:00 +0200 |
| Last post | 2020-04-10 20:00 +0200 |
| Articles | 20 on this page of 118 — 23 participants |
Back to article view | Back to linux.debian.user
geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-09 15:00 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-09 16:50 +0200
Re: geolocation services disabled and Gnome maps David Wright <deblis@lionunicorn.co.uk> - 2020-04-09 16:50 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:50 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-11 17:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 17:40 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-11 18:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 18:10 +0200
Re: geolocation services disabled and Gnome maps Celejar <celejar@gmail.com> - 2020-04-13 15:50 +0200
Re: geolocation services disabled and Gnome maps David Wright <deblis@lionunicorn.co.uk> - 2020-04-13 23:10 +0200
Re: geolocation services disabled and Gnome maps Brad Rogers <brad@fineby.me.uk> - 2020-04-11 18:00 +0200
Re: geolocation services disabled and Gnome maps Joe <joe@jretrading.com> - 2020-04-11 20:50 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-12 01:20 +0200
Re: geolocation services disabled and Gnome maps Gene Heskett <gheskett@shentel.net> - 2020-04-12 02:40 +0200
Re: geolocation services disabled and Gnome maps Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-12 09:20 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-12 20:20 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 17:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 17:50 +0200
Re: geolocation services disabled and Gnome maps Brad Rogers <brad@fineby.me.uk> - 2020-04-11 18:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 18:20 +0200
Re: geolocation services disabled and Gnome maps rhkramer@gmail.com - 2020-04-11 22:10 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 22:20 +0200
Re: geolocation services disabled and Gnome maps rhkramer@gmail.com - 2020-04-12 02:30 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 10:10 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-12 10:20 +0200
Re: geolocation services disabled and Gnome maps Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-12 10:50 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 11:50 +0200
Re: geolocation services disabled and Gnome maps Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-12 16:20 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 17:00 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-12 12:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-12 12:30 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-12 12:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-12 13:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-12 15:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-13 01:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-13 07:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-13 10:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-13 12:00 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-13 12:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Liam O'Toole <liam.p.otoole@gmail.com> - 2020-04-13 13:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-13 15:30 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Liam O'Toole <liam.p.otoole@gmail.com> - 2020-04-13 17:20 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-13 17:40 +0200
Re: DOH "Liam O'Toole" <liam.p.otoole@gmail.com> - 2020-04-14 22:10 +0200
Re: DOH Reco <recoverym4n@enotuniq.net> - 2020-04-14 22:50 +0200
Re: DOH Liam O'Toole <liam.p.otoole@gmail.com> - 2020-04-14 23:30 +0200
Re: DOH Celejar <celejar@gmail.com> - 2020-04-15 00:00 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-15 01:10 +0200
Re: DOH Liam O'Toole <liam.p.otoole@gmail.com> - 2020-04-15 01:30 +0200
Re: DOH Reco <recoverym4n@enotuniq.net> - 2020-04-15 09:00 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-13 17:30 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-14 00:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-14 08:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-14 13:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) nito@dismail.de - 2020-04-14 13:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-14 14:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Reco <recoverym4n@enotuniq.net> - 2020-04-14 15:30 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-14 17:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Celejar <celejar@gmail.com> - 2020-04-14 05:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-14 11:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Celejar <celejar@gmail.com> - 2020-04-14 19:00 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-14 19:20 +0200
Re: DOH Celejar <celejar@gmail.com> - 2020-04-15 00:00 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-13 09:20 +0200
Re: DOH John Hasler <jhasler@newsguy.com> - 2020-04-13 17:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-14 01:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) tomas@tuxteam.de - 2020-04-14 10:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-14 13:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-14 16:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Lee <ler762@gmail.com> - 2020-04-15 01:20 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-15 13:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) David Wright <deblis@lionunicorn.co.uk> - 2020-04-15 16:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Celejar <celejar@gmail.com> - 2020-04-17 05:30 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Gene Heskett <gheskett@shentel.net> - 2020-04-12 13:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-12 15:40 +0200
Re: DOH Michael Howard <mike@dewberryfields.co.uk> - 2020-04-12 15:50 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Gene Heskett <gheskett@shentel.net> - 2020-04-12 18:10 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) Tixy <tixy@yxit.co.uk> - 2020-04-12 14:40 +0200
Re: DOH (was: geolocation services disabled and Gnome maps) <tomas@tuxteam.de> - 2020-04-12 15:50 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 15:00 +0200
Re: geolocation services disabled and Gnome maps Joe <joe@jretrading.com> - 2020-04-11 23:40 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-12 10:00 +0200
Re: geolocation services disabled and Gnome maps Celejar <celejar@gmail.com> - 2020-04-13 16:00 +0200
Re: geolocation services disabled and Gnome maps Richard Owlett <rowlett@cloud85.net> - 2020-04-13 16:40 +0200
Re: geolocation services disabled and Gnome maps Michael Howard <mike@dewberryfields.co.uk> - 2020-04-13 16:40 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-11 17:10 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-09 18:20 +0200
Re: geolocation services disabled and Gnome maps "Anil Felipe Duggirala" <anilduggirala@fastmail.fm> - 2020-04-10 15:30 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-10 15:50 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 16:30 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:40 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:30 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-10 16:30 +0200
Re: geolocation services disabled and Gnome maps Reco <recoverym4n@enotuniq.net> - 2020-04-10 17:00 +0200
Re: geolocation services disabled and Gnome maps Reco <recoverym4n@enotuniq.net> - 2020-04-10 17:20 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 17:40 +0200
Re: geolocation services disabled and Gnome maps Reco <recoverym4n@enotuniq.net> - 2020-04-10 17:50 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 18:10 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-10 20:00 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-10 18:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 18:20 +0200
Re: geolocation services disabled and Gnome maps <tomas@tuxteam.de> - 2020-04-10 18:40 +0200
Re: geolocation services disabled and Gnome maps David Wright <deblis@lionunicorn.co.uk> - 2020-04-10 18:40 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:40 +0200
Re: geolocation services disabled and Gnome maps tomas@tuxteam.de - 2020-04-11 16:50 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:40 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 17:30 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 17:20 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:30 +0200
Re: geolocation services disabled and Gnome maps Reco <recoverym4n@enotuniq.net> - 2020-04-11 17:20 +0200
Re: geolocation services disabled and Gnome maps Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-13 13:40 +0200
Re: geolocation services disabled and Gnome maps David Wright <deblis@lionunicorn.co.uk> - 2020-04-10 17:20 +0200
Re: geolocation services disabled and Gnome maps John Hasler <jhasler@newsguy.com> - 2020-04-10 20:00 +0200
Re: geolocation services disabled and Gnome maps Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-11 09:40 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-11 10:30 +0200
Re: geolocation services disabled and Gnome maps Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-11 16:50 +0200
Re: geolocation services disabled and Gnome maps mick crane <mick.crane@gmail.com> - 2020-04-10 19:00 +0200
Re: geolocation services disabled and Gnome maps Curt <curty@free.fr> - 2020-04-10 20:00 +0200
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2020-04-14 19:00 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVx4K-6uv-3@gated-at.bofh.it> |
| In reply to | #221493 |
On Tue, 14 Apr 2020 05:45:45 -0400 Lee <ler762@gmail.com> wrote: > On 4/13/20, Celejar wrote: > > On Mon, 13 Apr 2020 08:47:22 +0300 > > Reco <recoverym4n@enotuniq.net> wrote: > > > >> Hi. > >> > >> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote: > > > > ... > > > >> > I just did a quick search and couldn't find anything for smart TVs > >> > using DOH. > >> > >> Probably because they aren't there yet. A typical smart TV is based on > >> the Android, and Google haven't said their word about DOH so far. > > > > I suppose you mean DoH specifically, as opposed to DNS over TLS (DoT), > > but just to clarify for the record, they have implemented the latter: > > > > https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie/ > > https://www.techrepublic.com/article/how-to-enable-dns-over-tls-in-android-pie/ > > > > Yes, DNS over HTTPS specifically is the concern. DNS over TLS uses a > specific port (that they could change, yeah, i know) that I have > blocked, so I'm not all that concerned about DoT. Ah, I think I understand. But if you're really worried about bad guys: > > 3) Bad guys and gals can hijack DNS too, to the usual hilarious results. > > And the bad guys and gals can use DOH to "hide" their traffic and > circumvent things like pihole. I just did a quick search and couldn't > find anything for smart TVs using DOH. Probably because my search > skillz sux :( why would they be limited by whatever the OS supports? Surely their malware can easily include an internal DoH implementation, although I suppose you'll at least be safer from malware that doesn't bother. Celejar
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2020-04-14 19:20 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVxo6-6Rd-7@gated-at.bofh.it> |
| In reply to | #221543 |
Celejar writes: > why would they be limited by whatever the OS supports? Surely their > malware can easily include an internal DoH implementation, They needn't use DNS at all. Hard coded IPs work fine for reaching their own servers. They are also not limited to the usual ports and protocols when talking to their own servers. -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2020-04-15 00:00 +0200 |
| Subject | Re: DOH |
| Message-ID | <zVBL5-10A-9@gated-at.bofh.it> |
| In reply to | #221545 |
On Tue, 14 Apr 2020 12:13:11 -0500 John Hasler <jhasler@newsguy.com> wrote: > Celejar writes: > > why would they be limited by whatever the OS supports? Surely their > > malware can easily include an internal DoH implementation, > > They needn't use DNS at all. Hard coded IPs work fine for reaching > their own servers. They are also not limited to the usual ports and > protocols when talking to their own servers. Indeed. As I noted (in the other part of my previous message), I suppose it's ultimately only a question of making things slightly more inconvenient for the malware authors. Celejar
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2020-04-13 09:20 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zV1xT-3Jx-7@gated-at.bofh.it> |
| In reply to | #221356 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote: [...] > Mozilla claims it's a privacy issue: > https://support.mozilla.org/en-US/kb/firefox-dns-over-https > Benefits Yes, sure [1], but *not in each and every friggin' application*. It'd be OK for the local DNS caching resolver to forward its queries to some DOH responder "out there", *configurable by the local sys admin. Locally, you have the same posibilities (resolv.conf, nsswitch, hosts). But letting an app bypass that, to some Mozilla-blessed DOH service is *not nice*. Just imagine your solitaire game had its very own way of doing name resolving. Cheers [1] I know. Even with DNSSEC, your ISP can see it /is/ DNS traffic, whereas they have given up (have they)? on sniffing https. -- tomás
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2020-04-13 17:20 +0200 |
| Subject | Re: DOH |
| Message-ID | <zV92r-8kG-33@gated-at.bofh.it> |
| In reply to | #221366 |
tomás writes: > But letting an app bypass that, to some Mozilla-blessed DOH service is > *not nice*. I assume that Mozilla is only considering Windows users who are going to use whatever DNS their ISP configured into their router. -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2020-04-14 01:10 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVgng-4y3-15@gated-at.bofh.it> |
| In reply to | #221366 |
On 4/13/20, tomas wrote: > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote: > > [...] > >> Mozilla claims it's a privacy issue: >> https://support.mozilla.org/en-US/kb/firefox-dns-over-https >> Benefits > > Yes, sure [1], but *not in each and every friggin' application*. I prefer apps that don't "phone home". > It'd be OK for the local DNS caching resolver to forward its > queries to some DOH responder "out there", *configurable by > the local sys admin. Locally, you have the same posibilities > (resolv.conf, nsswitch, hosts). Agreed. But how many home users have a local sys admin? That knows how to configure the local resolver? OK .. on this list, probably most. But *nix users are what percentage of all users? > [1] I know. Even with DNSSEC, your ISP can see it /is/ DNS > traffic, dnssec just adds a cryptographic signature to the data -- everything is still done "in the clear" (like Debian updates. or has buster switched to using https for downloading updates?) > whereas they have given up (have they)? on sniffing https. not that I've heard. There's something coming Real Soon Now that will prevent ISPs from seeing the name of the server you're connecting to but I don't remember what it's called right now :( Regards Lee
[toc] | [prev] | [next] | [standalone]
| From | tomas@tuxteam.de |
|---|---|
| Date | 2020-04-14 10:10 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVoNP-1Cp-5@gated-at.bofh.it> |
| In reply to | #221463 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote: > On 4/13/20, tomas wrote: > > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote: [...] > Agreed. But how many home users have a local sys admin? That knows > how to configure the local resolver? > > OK .. on this list, probably most. But *nix users are what percentage > of all users? I think "percentage" is important. But in the first place, we are here to make this *possible* at all! Otherwise we get 0%. Increasing percentage (aka education) is, of course, as important. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2020-04-14 13:40 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVs54-3v1-1@gated-at.bofh.it> |
| In reply to | #221463 |
On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote: > dnssec just adds a cryptographic signature to the data -- everything > is still done "in the clear" (like Debian updates. or has buster > switched to using https for downloading updates?) The apt-transport-https package is available, but is not installed by default. The Debian mirrors can be accessed via https, but again, this is not the default. (I.e. even if you install apt-transport-https, you still have to edit sources.list to use it.) Accessing the mirrors via https makes the packages un-cacheable, which makes the traffic volume significantly greater -- and the package lists are already signed, so there's no gain in trustworthiness of the packages. Some people may cite "privacy", as in "I don't want them to know which window manager I use", or something... I do not understand this argument, frankly. It sounds paranoid to me. I'd *love* to continue using http at work, but my workplace has been shutting down more and more plain http sites via their firewall. In the last few weeks, this includes the Debian mirrors. So, I had to switch my work machines to https. I really did not want to do that, because there are several of them, and now they can no longer share their package download bandwidth via a simple squid proxy. I'm not sure if I'll be willing to put the time into trying to come up with some other way to share downloads among them.
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-04-14 16:40 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVuTg-5eH-19@gated-at.bofh.it> |
| In reply to | #221502 |
[Multipart message — attachments visible in raw view] — view raw
On Ma, 14 apr 20, 07:32:58, Greg Wooledge wrote: > On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote: > > dnssec just adds a cryptographic signature to the data -- everything > > is still done "in the clear" (like Debian updates. or has buster > > switched to using https for downloading updates?) > > The apt-transport-https package is available, but is not installed > by default. Not required anymore (at least in buster). $ apt show apt-transport-https Package: apt-transport-https Version: 1.8.2 [...] Description: transitional package for https support This is a dummy transitional package - https support has been moved into the apt package in 1.5. It can be safely removed. > The Debian mirrors can be accessed via https, but again, > this is not the default. (I.e. even if you install apt-transport-https, > you still have to edit sources.list to use it.) This is still applicable. > Accessing the mirrors via https makes the packages un-cacheable, which > makes the traffic volume significantly greater -- and the package lists > are already signed, so there's no gain in trustworthiness of the packages. > > Some people may cite "privacy", as in "I don't want them to know which > window manager I use", or something... I do not understand this > argument, frankly. It sounds paranoid to me. Some people might not want to advertise to the world they are using packages like weboob (only in stretch) :) More seriously, there is the argument about using encryption even if not really needed in order to "hide" the cases where it is. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2020-04-15 01:20 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVD0u-1We-15@gated-at.bofh.it> |
| In reply to | #221502 |
On 4/14/20, Greg Wooledge <wooledg@eeg.ccf.org> wrote: > On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote: >> dnssec just adds a cryptographic signature to the data -- everything >> is still done "in the clear" (like Debian updates. or has buster >> switched to using https for downloading updates?) > > The apt-transport-https package is available, but is not installed > by default. The Debian mirrors can be accessed via https, but again, > this is not the default. (I.e. even if you install apt-transport-https, > you still have to edit sources.list to use it.) *sigh* I wasn't able to get that working :( This was right after I installed Debian for the first time, so I was pretty much totally clueless, but it was a compleat fail for me. > Accessing the mirrors via https makes the packages un-cacheable, which > makes the traffic volume significantly greater -- and the package lists > are already signed, so there's no gain in trustworthiness of the packages. > > Some people may cite "privacy", as in "I don't want them to know which > window manager I use", or something... I do not understand this > argument, frankly. It sounds paranoid to me. How about people that cite "security"? And yes, I take the simplistic approach that encrypted=good and clear-text=bad but clear-text allows things like https://www.guardicore.com/2019/01/a-vulnerability-in-debians-apt-allows-for-easy-lateral-movement-in-data-centers my understanding is that vuln wouldn't have existed if https had been used. > I'd *love* to continue using http at work, but my workplace has been > shutting down more and more plain http sites via their firewall. Getting rid of clear-text protocols is usually at the top of network audit checklists & with most people working from home now, it doesn't surprise me at all that network security is being "improved". > In the last few weeks, this includes the Debian mirrors. So, I had to > switch my work machines to https. I really did not want to do that, > because there are several of them, and now they can no longer share > their package download bandwidth via a simple squid proxy. > > I'm not sure if I'll be willing to put the time into trying to come up > with some other way to share downloads among them. Yeah.. it's extremely frustrating when 'they' do stupid stuff 'because security.' But if you talk to the people in the security group about what's going on -- if they'll talk to you at all - they've usually got at least a semi-reasonable explanation for why. (because the CIO said so being the one that frustrated me the most) Regards, Lee
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2020-04-15 13:50 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVOIh-FE-1@gated-at.bofh.it> |
| In reply to | #221564 |
On Tue, Apr 14, 2020 at 07:12:47PM -0400, Lee wrote: > On 4/14/20, Greg Wooledge <wooledg@eeg.ccf.org> wrote: > > Accessing the mirrors via https makes the packages un-cacheable, which > > makes the traffic volume significantly greater -- and the package lists > > are already signed, so there's no gain in trustworthiness of the packages. > > > > Some people may cite "privacy", as in "I don't want them to know which > > window manager I use", or something... I do not understand this > > argument, frankly. It sounds paranoid to me. > > How about people that cite "security"? And yes, I take the simplistic > approach that encrypted=good and clear-text=bad but clear-text allows > things like > https://www.guardicore.com/2019/01/a-vulnerability-in-debians-apt-allows-for-easy-lateral-movement-in-data-centers > > my understanding is that vuln wouldn't have existed if https had been used. That was a one-time bug, and was fixed quickly. People have blown it way out of proportion. The general answer for people who think "it's not https so it's not secure" is already given at <https://whydoesaptnotusehttps.com/>.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-04-15 16:50 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zVRwt-2oT-5@gated-at.bofh.it> |
| In reply to | #221576 |
On Wed 15 Apr 2020 at 07:49:28 (-0400), Greg Wooledge wrote: > On Tue, Apr 14, 2020 at 07:12:47PM -0400, Lee wrote: > > On 4/14/20, Greg Wooledge <wooledg@eeg.ccf.org> wrote: > > > Accessing the mirrors via https makes the packages un-cacheable, which > > > makes the traffic volume significantly greater -- and the package lists > > > are already signed, so there's no gain in trustworthiness of the packages. > > > > > > Some people may cite "privacy", as in "I don't want them to know which > > > window manager I use", or something... I do not understand this > > > argument, frankly. It sounds paranoid to me. > > > > How about people that cite "security"? And yes, I take the simplistic > > approach that encrypted=good and clear-text=bad but clear-text allows > > things like > > https://www.guardicore.com/2019/01/a-vulnerability-in-debians-apt-allows-for-easy-lateral-movement-in-data-centers > > > > my understanding is that vuln wouldn't have existed if https had been used. Looks like a sales pitch to me. (I didn't like their terms of use.) > That was a one-time bug, and was fixed quickly. People have blown it > way out of proportion. > > The general answer for people who think "it's not https so it's not secure" > is already given at <https://whydoesaptnotusehttps.com/>. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2020-04-17 05:30 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zWpRv-73P-1@gated-at.bofh.it> |
| In reply to | #221576 |
On Wed, 15 Apr 2020 07:49:28 -0400 Greg Wooledge <wooledg@eeg.ccf.org> wrote: > On Tue, Apr 14, 2020 at 07:12:47PM -0400, Lee wrote: > > On 4/14/20, Greg Wooledge <wooledg@eeg.ccf.org> wrote: > > > Accessing the mirrors via https makes the packages un-cacheable, which > > > makes the traffic volume significantly greater -- and the package lists > > > are already signed, so there's no gain in trustworthiness of the packages. > > > > > > Some people may cite "privacy", as in "I don't want them to know which > > > window manager I use", or something... I do not understand this > > > argument, frankly. It sounds paranoid to me. > > > > How about people that cite "security"? And yes, I take the simplistic > > approach that encrypted=good and clear-text=bad but clear-text allows > > things like > > https://www.guardicore.com/2019/01/a-vulnerability-in-debians-apt-allows-for-easy-lateral-movement-in-data-centers > > > > my understanding is that vuln wouldn't have existed if https had been used. > > That was a one-time bug, and was fixed quickly. People have blown it > way out of proportion. > > The general answer for people who think "it's not https so it's not secure" > is already given at <https://whydoesaptnotusehttps.com/>. As that site notes: > However there may be other security benefits to using HTTPS for apt > updates, in that it should greatly increase the difficulty for a > man-in-the-middle attacker to exploit future bugs in APT, or to IIUC, this is pretty much what happened to OpenWRT recently: https://arstechnica.com/information-technology/2020/03/openwrt-is-vulnerable-to-attacks-that-execute-malicious-code/ They were using SHA2565 checksums to verify packages, not GPG signing, but the vulnerability was caused by buggy code that allowed the hash check to be bypassed, which I suppose could hit a GPG based system as well ... Celejar
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2020-04-12 13:40 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zUJ7X-JD-5@gated-at.bofh.it> |
| In reply to | #221282 |
On Sunday 12 April 2020 06:35:44 tomas@tuxteam.de wrote: > On Sun, Apr 12, 2020 at 01:21:08PM +0300, Reco wrote: > > On Sun, Apr 12, 2020 at 12:10:45PM +0200, tomas@tuxteam.de wrote: > > > That's why I cringe at the idea that browsers want to start doing > > > name resolution over HTTPS. > > > > This simple one line of dnsmasq configuration will disable this > > problematic feature for good for Firefox (basically it creates a > > bogus NXDOMAIN response for this particular site): > > > > local=/use-application-dns.net/ > > I don't quite understand [1] how the dnsmasq config has a say on > whether the browser resolves things over HTTP (it won't ask the > resolver in the first place, would it?), but thanks for the pointer > anyway. > > Cheers > [1] That's not a rhethorical flourish, it's genuine. I know too > little about DNS-over-HTTP to be of any use at this point. > > -- tomás I don't either, but at some point in an https environment, it seems to me that a dns lookup is going to have to be translated into a plain dns lookup. Perhaps I'm being dense but I am not personally aware of an encrypted to https protocol for dns lookups. I have no such facility here in my two stage resolver that I've been aware of, but https Just Works. But density is relative, in a recent thread asking about installing more memory, it was said that he had started with a 4GB stick and that the op was adding another 8Gb stick. In my experience thats doomed to run at half speed because the two sticks don't match. Yet no one mentioned that with matching sticks, memory can be accessed at double speed, alternating between matching sticks by reading even addresses interleaved with reading odd addresses. With dis-similar sizes, this interleaving of addresses cannot be done. Sequential reads are the forced into half speed reads because of the memory's recovery speeds. Rule of thumb then is installing memory as pairs but consult the motherboards docs to find out if pairs are slots 0 and 1, or 0 and 2. Yet no on mentioned that effect on speed in that whole thread. Shame on us. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2020-04-12 15:40 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zUL06-1Ss-13@gated-at.bofh.it> |
| In reply to | #221284 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Apr 12, 2020 at 07:33:51AM -0400, Gene Heskett wrote: [...] > I don't either, but at some point in an https environment, it seems to me > that a dns lookup is going to have to be translated into a plain dns > lookup. No, that's not how it works. When the browser wants to resolve a name, it doesn't "do" DNS (when it's doing DOH, that is) but uses some "web-service-ish" protocol over https to some server out there (cloudflare, e.g.) which does the resolution and answers via https. Thus bypassing whatever scheme the sysadmin has set up for DNS. I don't have polite words for that. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Michael Howard <mike@dewberryfields.co.uk> |
|---|---|
| Date | 2020-04-12 15:50 +0200 |
| Subject | Re: DOH |
| Message-ID | <zUL9M-1VT-7@gated-at.bofh.it> |
| In reply to | #221295 |
On 12/04/2020 14:39, tomas@tuxteam.de wrote: > On Sun, Apr 12, 2020 at 07:33:51AM -0400, Gene Heskett wrote: > > [...] > >> I don't either, but at some point in an https environment, it seems to me >> that a dns lookup is going to have to be translated into a plain dns >> lookup. > No, that's not how it works. When the browser wants to resolve a > name, it doesn't "do" DNS (when it's doing DOH, that is) but uses > some "web-service-ish" protocol over https to some server out there > (cloudflare, e.g.) which does the resolution and answers via https. > > Thus bypassing whatever scheme the sysadmin has set up for DNS. > > I don't have polite words for that. > > Cheers > -- t Security has a lot to answer for. It's amazing how much is done in this day and age, in _all_ walks of life, in the name of so called security. -- Michael Howard
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2020-04-12 18:10 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zUNlf-3rO-17@gated-at.bofh.it> |
| In reply to | #221295 |
On Sunday 12 April 2020 09:39:09 tomas@tuxteam.de wrote: > On Sun, Apr 12, 2020 at 07:33:51AM -0400, Gene Heskett wrote: > > [...] > > > I don't either, but at some point in an https environment, it seems > > to me that a dns lookup is going to have to be translated into a > > plain dns lookup. > > No, that's not how it works. When the browser wants to resolve a > name, it doesn't "do" DNS (when it's doing DOH, that is) but uses > some "web-service-ish" protocol over https to some server out there > (cloudflare, e.g.) which does the resolution and answers via https. > > Thus bypassing whatever scheme the sysadmin has set up for DNS. > > I don't have polite words for that. > Neither do I, and it WILL BE EXPLOITED. Linux has been such a breath of fresh air when I found it in late 1998, that I've forgotten a monologue, about 4 or 5 minutes long I used in my early dealings with Nt-3.51 and its random deletions of important dll's that M$ used to make you buy a new license. Once, I might have been gullible enough to buy it, but at $600 for a new license twice in 2 years time on 2 different machines the same dll just vanished has to be malicious. But the crowning blow was when somebody in Redmond had the chutzpah to call me a pie-rat because I wanted a floppy fedexed to me with just that library on it. Screw em, and the camel that rode in on them... > Cheers > -- t Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Tixy <tixy@yxit.co.uk> |
|---|---|
| Date | 2020-04-12 14:40 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zUK42-1iV-9@gated-at.bofh.it> |
| In reply to | #221281 |
On Sun, 2020-04-12 at 13:21 +0300, Reco wrote: > On Sun, Apr 12, 2020 at 12:10:45PM +0200, tomas@tuxteam.de wrote: > > That's why I cringe at the idea that browsers want to start doing > > name resolution over HTTPS. > > This simple one line of dnsmasq configuration will disable this > problematic feature for good for Firefox (basically it creates a > bogus > NXDOMAIN response for this particular site): > > local=/use-application-dns.net/ > Technically, that doesn't disable it, just just disables any 'on by default' DoH [1]. For individual users worried about this, it would be simpler not to accept it when Firefox asks to enable it, or to disable it it with a config option. [2] That would be needed to be done anyway for mobile devices that can roam to different networks. [1] https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet [2] https://support.mozilla.org/en-US/kb/firefox-dns-over-https -- Tixy
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2020-04-12 15:50 +0200 |
| Subject | Re: DOH (was: geolocation services disabled and Gnome maps) |
| Message-ID | <zUL9M-1VT-1@gated-at.bofh.it> |
| In reply to | #221286 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Apr 12, 2020 at 01:34:07PM +0100, Tixy wrote: > On Sun, 2020-04-12 at 13:21 +0300, Reco wrote: > > On Sun, Apr 12, 2020 at 12:10:45PM +0200, tomas@tuxteam.de wrote: > > > That's why I cringe at the idea that browsers want to start doing > > > name resolution over HTTPS. > > > > This simple one line of dnsmasq configuration will disable this > > problematic feature for good for Firefox (basically it creates a > > bogus > > NXDOMAIN response for this particular site): > > > > local=/use-application-dns.net/ > > > > Technically, that doesn't disable it, just just disables any 'on by > default' DoH [1]. For individual users worried about this, it would be > simpler not to accept it when Firefox asks to enable it, or to disable > it it with a config option. [2] That would be needed to be done anyway > for mobile devices that can roam to different networks. > > [1] https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet > [2] https://support.mozilla.org/en-US/kb/firefox-dns-over-https Yep. That sounds less fragile. Thanks. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2020-04-12 15:00 +0200 |
| Message-ID | <zUKnn-1pT-5@gated-at.bofh.it> |
| In reply to | #221279 |
On 2020-04-12, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> On Sun, Apr 12, 2020 at 11:48:40AM +0300, Andrei POPESCU wrote:
>
> [...]
>
>> Just to clarify, the privacy concern here is the software accessing the
>> internet without explicit user consent, regardless of what it is using
>> this information for (internal only or providing it to other software).
In the end this turns out to be an outstanding bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924516
...
...geoclue is communicating with location.services.mozilla.com when it should
not.
Work around is to disable and mask geoclue.service.
I note that I do not have a geoclue.service to disable or mask, opened the Maps
app from my LXDE desktop (with org.gnome.system.location enabled set to false)
and Maps found me anyway (within a small stone's throw).
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web