Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.security > #5794
| From | Lee <ler762@gmail.com> |
|---|---|
| Newsgroups | linux.debian.security |
| Subject | Re: debcheckroot v2.0 released |
| Date | 2020-04-04 00:50 +0200 |
| Message-ID | <zRDip-WR-1@gated-at.bofh.it> (permalink) |
| References | (13 earlier) <zQPYl-4rn-3@gated-at.bofh.it> <zQVr3-7CB-5@gated-at.bofh.it> <zRdeh-1Me-7@gated-at.bofh.it> <zRdQZ-2eP-9@gated-at.bofh.it> <zRsZI-37b-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 4/3/20, Elmar Stellnberger <estellnb@elstel.org> wrote: >> There are a few reasons why I believe that DANE / TLSA DNS RR answers >> are quite trustworthy: Yes, DANE / TLSA DNS RR answers seem trustworthy. What I don't consider trustworthy is the clear-text traffic between the client and the DNSSEC enabled resolver. Let's say that I'm using 1.1.1.1 as my resolver. Cloudflare comes up with a trustworthy answer, but I don't trust the clear-text traffic from Cloudflare to my PC. With DOH, I can trust the answer that comes back from Cloudlfare to my PC. >> * DNS responses are much faster than establishing a TCP connection >> (1.5RTT), usually only about 40ms also because DNS servers tend to be >> near the user if not provided by the ISP while the server you wanna >> contact is usually in another country or another federal state. As we >> know from the Snowden Revelations spoofing connections only works if the >> spoofed response is faster than the original response. My idea about it >> is that the NSA and related intelligence simply do not have an >> infrastructure to spoof DNS responses. Maybe not.. but I keep going back to the basic idea (prejudice?) that clear-text traffic is inherently untrustworthy. What any particular group can/can't do is not an interesting question to me. >> * There is a public/private key signing infrastructure for DANE as well >> but I consider that more secure than a gpg private key used on a system >> with emailing or web browsing. I believe it is much more hard to get >> into a server than is to get into a client. >> >> Finally DANE has been invented for the reason to restore trust in the >> internet - as it was there initially when there was no operation Quantum >> insert or similar operations. I´d believe the DANE system has been >> designed secure as to serve its purpose. Finally my own practical >> experience with DANE is very positive. It appeared to be the only way to >> prevent site spoofing: >> https://lists.debian.org/debian-security/2020/01/threads.html >> https://lists.debian.org/debian-security/2020/02/threads.html >> https://lists.debian.org/debian-security/2020/03/threads.html >> >> The reason why browser developers have not adopted DANE yet is that >> they side with intelligence (secret services) as the following bug >> report shows me: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 If I'm understanding your bug report correctly, I'm not at all surprised they didn't change anything. It seems like what you want is the modern equivalent of the Cert Patrol addon; it's a shame that functionality isn't in firefox any more :( > Finally I have forgotten about the most important reason why DANE is > much more secure than other methods: > > * There is a regular, secure and automatic key rotation for DANE. With > GnuPG keys can be happily stolen as they remain valid for a year or more > and as there is no secure way to redistribute a new key. Yes, GPG Key distribution/revocation seems to be a weak point. > Concerning DoH/DoT I would rather believe these technologies to be > detrimental as encryption adds an additional error prone overhead but > does not contribute anything to the authenticity of the reply. I don't trust clear-text communications; it seems like DoH/DoT solves that problem.. at least for dnssec enabled domains. While encryption adds an additional error prone overhead, I'll still take that risk over the risk of using a clear-text communications channel. > Encryption can be a source of arbitrary code execution exploits if not > implemented properly. Encrypting DNS would have other application > purposes and makes sense as long as you use a proxy. If you connect > directly hiding the domain name is ineffective because someone who spys > at the connection also knows the IPs you connect to and via SNI the > cleartext of the domain you surf at. Yes, but "trusting the answer" and "keeping my communications private" are not quite the same thing. If we're talking about "trusting the answer" I'll take DoT or running my own dnssec enabled resolver. When I'm more concerned about "keeping my communications private" I'll take TOR & accept the trade-off of slower speed. Regards, Lee
Back to linux.debian.security | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Have I caught a firmware attack in the act? Or am I just paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-13 09:40 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Paul Wise <pabs@debian.org> - 2019-08-14 07:10 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-14 17:40 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-15 23:20 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Davide Prina <davide.prina@gmail.com> - 2019-08-16 10:40 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? CMH <chouck@binghamton.edu> - 2019-08-16 14:20 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Andrei Grosu <andrei_grosu@fastmail.net> - 2019-08-16 19:20 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 19:20 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 19:10 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 19:30 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 21:20 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-17 11:50 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-17 13:20 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-23 09:30 +0200
Re: Have I caught a firmware attack in the act? Or am I just paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-23 21:00 +0200
debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-15 17:20 +0100
Verified Boot, Secure Boot, dm-verity, debcheckroot Patrick Schleizer <adrelanos@riseup.net> - 2019-11-16 14:00 +0100
Re: Verified Boot, Secure Boot, dm-verity, debcheckroot Elmar Stellnberger <estellnb@gmail.com> - 2019-11-16 15:30 +0100
Re: Verified Boot, Secure Boot, dm-verity, debcheckroot Sylvain Beucler <beuc@beuc.net> - 2019-11-16 15:40 +0100
Re: Verified Boot, Secure Boot, dm-verity, debcheckroot Elmar Stellnberger <estellnb@gmail.com> - 2019-11-16 15:40 +0100
Re: debcheckroot v2.0 released Patrick Schleizer <adrelanos@riseup.net> - 2019-11-19 13:40 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-20 12:30 +0100
Re: debcheckroot v2.0 released Patrick Schleizer <adrelanos@riseup.net> - 2019-11-25 12:40 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-25 18:00 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-12-10 17:40 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-27 12:10 +0100
Re: debcheckroot v2.0 released Cindy Sue Causey <butterflybytes@gmail.com> - 2020-01-17 14:40 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-01-17 17:00 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-01-17 17:20 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 20:20 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 20:50 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 21:00 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 21:00 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-23 17:10 +0100
Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-03-24 04:40 +0100
Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-03-24 11:20 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-03-24 15:50 +0100
Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-03-25 03:00 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-03-25 11:30 +0100
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-03-26 11:10 +0100
Re: debcheckroot v2.0 released "vince@vheuser.com" <vince@vheuser.com> - 2020-04-01 20:10 +0200
Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-04-02 02:00 +0200
Re: debcheckroot v2.0 released Lewis Yarema <lewisyarema91@gmail.com> - 2020-04-02 11:20 +0200
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-02 17:00 +0200
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-03 13:40 +0200
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-02 16:50 +0200
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-04 09:50 +0200
Re: debcheckroot v2.0 released William Gagnebé <william.gagnebe@gmail.com> - 2020-04-05 12:20 +0200
Re: debcheckroot v2.0 released l0f4r0@tuta.io - 2020-04-05 12:30 +0200
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-07 17:50 +0200
Re: debcheckroot v2.0 released "Niall O'Reilly" <Niall.oReilly+lists@no8.be> - 2020-04-02 18:30 +0200
Re: debcheckroot v2.0 released Lee <ler762@gmail.com> - 2020-04-02 21:00 +0200
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-02 21:40 +0200
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-03 13:50 +0200
Re: debcheckroot v2.0 released Lee <ler762@gmail.com> - 2020-04-04 00:50 +0200
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-04 09:40 +0200
Re: debcheckroot v2.0 released Bjørn Mork <bjorn@mork.no> - 2020-04-14 09:30 +0200
arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-04-25 15:40 +0200
Re: arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-04-25 15:50 +0200
Re: arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-05-02 17:00 +0200
Re: arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-05-02 17:10 +0200
Fwd: Re: arbitrary code execution on unformatted usb stick estellnb@elstel.org - 2020-05-02 20:50 +0200
Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-21 17:40 +0100
Probably a false alarm Re: Have I caught a firmware attack in the act? Or am I just paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-24 18:50 +0200
csiph-web