Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.security > #5646 > unrolled thread
| Started by | "Rebecca N. Palmer" <rebecca_palmer@zoho.com> |
|---|---|
| First post | 2019-08-13 09:40 +0200 |
| Last post | 2019-08-24 18:50 +0200 |
| Articles | 20 on this page of 64 — 18 participants |
Back to article view | Back to linux.debian.security
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
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | "vince@vheuser.com" <vince@vheuser.com> |
|---|---|
| Date | 2020-04-01 20:10 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zQPYl-4rn-3@gated-at.bofh.it> |
| In reply to | #5783 |
Did the discussion of continuing support for DANE end?? Hope its not too late to weigh in here. Debian is used by a lot of people with differing security needs. And trust is a difficult thing to come by. Why would I trust that the Debian security team is not cooperating with the FBI/CIA to catch my radical friends. (Pick your favorite radical issue.) And if I can't trust that, why would I trust the GPG key that I download from some apparently valid site? DANE doesn't solve all the problems but it does tighten up one avenue the absence of which that makes Debian less secure. If I trust Paul or Elmar, personally, then DANE give me some hope that I am really dealing with their sites. Is that not correct? Vince H. On 2020/03/26 05:01 AM, Elmar Stellnberger wrote: > Am 26.03.20 um 03:50 schrieb Paul Wise: >> On Wed, 2020-03-25 at 11:27 +0100, Elmar Stellnberger wrote: >> >>> OpenPGP is no solution to the issue. >>> DANE is not gonna disappear. >> >> I guess we will have to agree to disagree, end of thread for me. >> > > I am far from not having to say more about it. Most people who provide signatures > store their private key on a machine also used for web browsing. I know this also > applies to Debian because keeping the key secure or at best offline would require some > considerable provisions and AFAIK none of you have implemented a separation of concerns > i.e. one computer for browsing and another one for secure ssh connections. > That would be required though to keep the secret key safe. We have an arbitrary code > execution bug in browsers every few month and that does not count all the zero day > exploits at all. Sites in the www are commonly spoofed by secret services. Even the > Snowden revelations do tell (operation Quantum insert). That way the secret key is > guaranteed to be compromised a few milliseconds after its creation. The NSA also has its > own key stealing programme. I wanna tell you that you are better off checking the > SHA512SUM. That one, as soon as you have retrieved a genuine one, can no more be spoofed. > Besides this it is a common attack vector to infect computers via online updates. Once > more they need to know the secret key in order to do so! > >
[toc] | [prev] | [next] | [standalone]
| From | Paul Wise <pabs@debian.org> |
|---|---|
| Date | 2020-04-02 02:00 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zQVr3-7CB-5@gated-at.bofh.it> |
| In reply to | #5784 |
On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote: > Did the discussion of continuing support for DANE end?? In case I mislead anyone, a clarification: Debian itself isn't going to actively work on removing support for DANE from anything nor removing our DANE/DNSSEC records. Support for DANE is never going to happen for the web (given the opinions of the major browser makers) and it could disappear in other upstream projects as the popularity of DoH/DoT and other things in the DNS space eclipse DANE/DNSSEC. Should that happen to the software Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC records. -- bye, pabs https://wiki.debian.org/PaulWise
[toc] | [prev] | [next] | [standalone]
| From | Lewis Yarema <lewisyarema91@gmail.com> |
|---|---|
| Date | 2020-04-02 11:20 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zR4b0-4Qe-7@gated-at.bofh.it> |
| In reply to | #5785 |
But we have the atea tool now. Haven't we? You can use it to download via DNSSEC/DANE. And I believe Elmar is going to continue support for it. Debian itself can always support DANE as long as there are working DNSSEC impementations. Just provide a TLSA record. And I would believe that to be valuable since the problem about DNSSEC/DANE support is a bit like the hen and egg problem.
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-02 17:00 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zR9u1-7V1-3@gated-at.bofh.it> |
| In reply to | #5786 |
Am 02.04.20 um 11:15 schrieb Lewis Yarema: > But we have the atea tool now. Haven't we? You can use it to download > via DNSSEC/DANE. And I believe Elmar is going to continue support for > it. Debian itself can always support DANE as long as there are working > DNSSEC impementations. Just provide a TLSA record. And I would believe > that to be valuable since the problem about DNSSEC/DANE support is a > bit like the hen and egg problem. > Yes, sure, I am going to support a̅tea in the future. Support of security related programs and especially of a̅tea have absolute priority for me. I do what I can. The program appears so important to me because according to my knowledge there is no other program you can use for download with user supplied security certificate. wget and curl do all require you to trust a possibly untrustworthy CA. Besides this you can use DANE without direct support by any program. I have described who to do that by use of dig or drill at https://www.elstel.org/DANE/.
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-03 13:40 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zRsQ1-33K-3@gated-at.bofh.it> |
| In reply to | #5788 |
Am 02.04.20 um 16:55 schrieb Elmar Stellnberger: > Am 02.04.20 um 11:15 schrieb Lewis Yarema: >> But we have the atea tool now. Haven't we? You can use it to download >> via DNSSEC/DANE. And I believe Elmar is going to continue support for >> it. Debian itself can always support DANE as long as there are working >> DNSSEC impementations. Just provide a TLSA record. And I would believe >> that to be valuable since the problem about DNSSEC/DANE support is a >> bit like the hen and egg problem. >> > > Yes, sure, I am going to support a̅tea in the future. Support of > security related programs and especially of a̅tea have absolute priority > for me. I do what I can. The program appears so important to me because > according to my knowledge there is no other program you can use for > download with user supplied security certificate. wget and curl do all > require you to trust a possibly untrustworthy CA. Besides this you can > use DANE without direct support by any program. I have described who to > do that by use of dig or drill at https://www.elstel.org/DANE/. > If there is someone else who has never heard about a̅tea: https://www.elstel.org/atea/ You may have missed my previous messages from debian-security: https://lists.debian.org/debian-security/2020/03/threads.html https://lists.debian.org/debian-security/2020/01/threads.html Vince asked me because he did not get these messages to read though he was subscribed. I also can´t explain why Patrick Schleizer did no more respond me though I have finally posted the message for him to this list. https://lists.debian.org/debian-security/2020/03/msg00017.html He is also subscribed and would need to have seen my posting. As it seems some people here don´t get my messages.
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-02 16:50 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zR9kl-7RH-3@gated-at.bofh.it> |
| In reply to | #5785 |
Am 02.04.20 um 01:57 schrieb Paul Wise: > On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote: > >> Did the discussion of continuing support for DANE end?? > > In case I mislead anyone, a clarification: > > Debian itself isn't going to actively work on removing support for > DANE from anything nor removing our DANE/DNSSEC records. > > Support for DANE is never going to happen for the web (given the > opinions of the major browser makers) and it could disappear in other > upstream projects as the popularity of DoH/DoT and other things in the > DNS space eclipse DANE/DNSSEC. Should that happen to the software > Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC > records. > What software is currently used for DNSSEC/DANE by Debian? What do you mean by DoH/DoT?
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-04 09:50 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zRLIZ-68t-9@gated-at.bofh.it> |
| In reply to | #5787 |
Am 02.04.20 um 16:49 schrieb Elmar Stellnberger: > Am 02.04.20 um 01:57 schrieb Paul Wise: >> On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote: >> >>> Did the discussion of continuing support for DANE end?? >> >> In case I mislead anyone, a clarification: >> >> Debian itself isn't going to actively work on removing support for >> DANE from anything nor removing our DANE/DNSSEC records. >> >> Support for DANE is never going to happen for the web (given the >> opinions of the major browser makers) and it could disappear in other >> upstream projects as the popularity of DoH/DoT and other things in the >> DNS space eclipse DANE/DNSSEC. Should that happen to the software >> Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC >> records. >> > > What software is currently used for DNSSEC/DANE by Debian? > What do you mean by DoH/DoT? > Dear Paul, Can you answer us that question: What software does Debian use that supports DANE? I do not know of any except dig and drill. Yours, Elmar Stellnberger
[toc] | [prev] | [next] | [standalone]
| From | William Gagnebé <william.gagnebe@gmail.com> |
|---|---|
| Date | 2020-04-05 12:20 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zSaxI-4Ad-11@gated-at.bofh.it> |
| In reply to | #5796 |
[Multipart message — attachments visible in raw view] — view raw
Hello, could you please *remove *me from the debian-security mailing list? It's been year (true story) that I'm asking for that, and I don't even know how it is possible coming from an IT group .. :D Please do this ecological contribution .. Regards Le sam. 4 avr. 2020 à 09:47, Elmar Stellnberger <estellnb@elstel.org> a écrit : > Am 02.04.20 um 16:49 schrieb Elmar Stellnberger: > > Am 02.04.20 um 01:57 schrieb Paul Wise: > >> On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote: > >> > >>> Did the discussion of continuing support for DANE end?? > >> > >> In case I mislead anyone, a clarification: > >> > >> Debian itself isn't going to actively work on removing support for > >> DANE from anything nor removing our DANE/DNSSEC records. > >> > >> Support for DANE is never going to happen for the web (given the > >> opinions of the major browser makers) and it could disappear in other > >> upstream projects as the popularity of DoH/DoT and other things in the > >> DNS space eclipse DANE/DNSSEC. Should that happen to the software > >> Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC > >> records. > >> > > > > What software is currently used for DNSSEC/DANE by Debian? > > What do you mean by DoH/DoT? > > > > Dear Paul, > > Can you answer us that question: What software does Debian use that > supports DANE? I do not know of any except dig and drill. > > Yours, > Elmar Stellnberger > >
[toc] | [prev] | [next] | [standalone]
| From | l0f4r0@tuta.io |
|---|---|
| Date | 2020-04-05 12:30 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zSaHn-4Dn-5@gated-at.bofh.it> |
| In reply to | #5797 |
Hi, 5 avr. 2020 à 12:00 de william.gagnebe@gmail.com: > could you please > remove > me from the debian-security mailing list? > It's been year (true story) that I'm asking for that, and I don't even know how it is possible coming from an IT group .. :D > > Please do this ecological contribution .. > Obviously you don't know that such action must be done by yourself: https://www.debian.org/MailingLists/unsubscribe Best regards, l0f4r0
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-07 17:50 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zSYEa-1kW-5@gated-at.bofh.it> |
| In reply to | #5796 |
Am 04.04.20 um 09:47 schrieb Elmar Stellnberger: > Am 02.04.20 um 16:49 schrieb Elmar Stellnberger: >> Am 02.04.20 um 01:57 schrieb Paul Wise: >>> On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote: >>> >>>> Did the discussion of continuing support for DANE end?? >>> >>> In case I mislead anyone, a clarification: >>> >>> Debian itself isn't going to actively work on removing support for >>> DANE from anything nor removing our DANE/DNSSEC records. >>> >>> Support for DANE is never going to happen for the web (given the >>> opinions of the major browser makers) and it could disappear in other >>> upstream projects as the popularity of DoH/DoT and other things in the >>> DNS space eclipse DANE/DNSSEC. Should that happen to the software >>> Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC >>> records. >>> >> >> What software is currently used for DNSSEC/DANE by Debian? >> What do you mean by DoH/DoT? >> > > Dear Paul, > > Can you answer us that question: What software does Debian use that > supports DANE? I do not know of any except dig and drill. > > Yours, > Elmar Stellnberger ping
[toc] | [prev] | [next] | [standalone]
| From | "Niall O'Reilly" <Niall.oReilly+lists@no8.be> |
|---|---|
| Date | 2020-04-02 18:30 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zRaT7-t0-9@gated-at.bofh.it> |
| In reply to | #5785 |
Hello. On 2 Apr 2020, at 0:57, Paul Wise wrote: > Support for DANE is never going to happen for the web (given the > opinions of the major browser makers) and it could disappear in other > upstream projects as the popularity of DoH/DoT and other things in the > DNS space eclipse DANE/DNSSEC. I'm surprised by the second part of this statement, "and it could disappear [...] as [...] other things [...] eclipse DANE/DNSSEC." DoH and DoT provide an encrypted query/response channel from the client to the resolver. DNSSEC provides an assurance that the resolver is not spoofing response data. DANE builds on DNSSEC to protect against a compromised (or even rogue) CA certifying an impostor instead of the legitimate operator of a service. These are complementary protections against corresponding distinct threats, not competing solutions to the same problem. Best regards, Niall O'Reilly
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2020-04-02 21:00 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zRdeh-1Me-7@gated-at.bofh.it> |
| In reply to | #5785 |
On 4/1/20, Paul Wise wrote:
> On Wed, Apr 1, 2020 at 6:01 PM vince@ wrote:
>
>> Did the discussion of continuing support for DANE end??
>
> In case I mislead anyone, a clarification:
>
> Debian itself isn't going to actively work on removing support for
> DANE from anything nor removing our DANE/DNSSEC records.
>
> Support for DANE is never going to happen for the web (given the
> opinions of the major browser makers)
Can you share a reference for that?
I can see browsers not trusting the client DNS since they can't tell
if the client resolver is using DNSSEC or not (ie. they can't tell if
the DANE answer is valid). But now that DOH is supported it seems
like browsers could trust DOH servers that [promise to] do DNSSEC, so
now they could trust DANE?
eg - the firefox DOH server seems to have DNSSEC enabled:
$ curl -H 'accept: application/dns-json' \
'https://mozilla.cloudflare-dns.com/dns-query?name=servfail.sidnlabs.nl&type=a'
{"Status": 2,"TC": false,"RD": true, "RA": true, "AD": false,"CD":
false,"Question":[{"name": "servfail.sidnlabs.nl.", "type":
1}],"Comment": "DNSSEC validation failure. Please check
http://dnsviz.net/d/servfail.sidnlabs.nl/dnssec/"}
so maybe the tlsa answer can be trusted?
$ curl -H 'accept: application/dns-json' \
'https://mozilla.cloudflare-dns.com/dns-query?name=_443._tcp.debian.org&type=tlsa'
{"Status": 0,"TC": false,"RD": true, "RA": true, "AD": true,"CD":
false,"Question":[{"name": "_443._tcp.debian.org.", "type":
52}],"Answer":[{"name": "_443._tcp.debian.org.", "type": 52, "TTL":
600, "data": "3 1 1
5F33491E2B2D267F7BFF096AD0DCB4AE5A22C0BE19DB0AB6728BED942F0719FC"}]}
Thanks,
Lee
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-02 21:40 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zRdQZ-2eP-9@gated-at.bofh.it> |
| In reply to | #5790 |
Am 02.04.20 um 20:50 schrieb Lee:
> On 4/1/20, Paul Wise wrote:
>> On Wed, Apr 1, 2020 at 6:01 PM vince@ wrote:
>>
>>> Did the discussion of continuing support for DANE end??
>>
>> In case I mislead anyone, a clarification:
>>
>> Debian itself isn't going to actively work on removing support for
>> DANE from anything nor removing our DANE/DNSSEC records.
>>
>> Support for DANE is never going to happen for the web (given the
>> opinions of the major browser makers)
>
> Can you share a reference for that?
>
> I can see browsers not trusting the client DNS since they can't tell
> if the client resolver is using DNSSEC or not (ie. they can't tell if
> the DANE answer is valid). But now that DOH is supported it seems
> like browsers could trust DOH servers that [promise to] do DNSSEC, so
> now they could trust DANE?
>
> eg - the firefox DOH server seems to have DNSSEC enabled:
>
> $ curl -H 'accept: application/dns-json' \
> 'https://mozilla.cloudflare-dns.com/dns-query?name=servfail.sidnlabs.nl&type=a'
> {"Status": 2,"TC": false,"RD": true, "RA": true, "AD": false,"CD":
> false,"Question":[{"name": "servfail.sidnlabs.nl.", "type":
> 1}],"Comment": "DNSSEC validation failure. Please check
> http://dnsviz.net/d/servfail.sidnlabs.nl/dnssec/"}
>
> so maybe the tlsa answer can be trusted?
>
> $ curl -H 'accept: application/dns-json' \
> 'https://mozilla.cloudflare-dns.com/dns-query?name=_443._tcp.debian.org&type=tlsa'
> {"Status": 0,"TC": false,"RD": true, "RA": true, "AD": true,"CD":
> false,"Question":[{"name": "_443._tcp.debian.org.", "type":
> 52}],"Answer":[{"name": "_443._tcp.debian.org.", "type": 52, "TTL":
> 600, "data": "3 1 1
> 5F33491E2B2D267F7BFF096AD0DCB4AE5A22C0BE19DB0AB6728BED942F0719FC"}]}
>
> Thanks,
> Lee
>
There are a few reasons why I believe that DANE / TLSA DNS RR answers
are quite trustworthy:
* 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.
* 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
I had also linked this report in my previous discussion at
debian-security.
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-03 13:50 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zRsZI-37b-3@gated-at.bofh.it> |
| In reply to | #5791 |
> There are a few reasons why I believe that DANE / TLSA DNS RR answers > are quite trustworthy: > > * 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. > > * 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 > > I had also linked this report in my previous discussion at > debian-security. > 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. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Lee <ler762@gmail.com> |
|---|---|
| Date | 2020-04-04 00:50 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zRDip-WR-1@gated-at.bofh.it> |
| In reply to | #5793 |
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
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-04 09:40 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zRLzk-64Z-13@gated-at.bofh.it> |
| In reply to | #5794 |
Am 04.04.20 um 00:46 schrieb Lee: > On 4/3/20, Elmar Stellnberger <estellnb@elstel.org> wrote: >> 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. > I think we have to separate two issues here: authenticity asserting that the answer is correct and confidentiality asserting that no one else knows about a message. Signing asserts authenticity while encryption can guarantee confidentiality. With GnuPG encrypted messages are also signed by default so that both features are provided. That does not tell however that both issues are clearly separated. Encryption by itself does not contribute anything to the authenticity of a reply, i.e. you do not know from whom it came. With signing the correctness of an answer can be asserted but the answer itself can be read in cleartext by everyone unless it is additionally encrypted.
[toc] | [prev] | [next] | [standalone]
| From | Bjørn Mork <bjorn@mork.no> |
|---|---|
| Date | 2020-04-14 09:30 +0200 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zVob8-1a0-9@gated-at.bofh.it> |
| In reply to | #5785 |
Paul Wise <pabs@debian.org> writes: > On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote: > >> Did the discussion of continuing support for DANE end?? > > In case I mislead anyone, a clarification: > > Debian itself isn't going to actively work on removing support for > DANE from anything nor removing our DANE/DNSSEC records. > > Support for DANE is never going to happen for the web (given the > opinions of the major browser makers) Well, there is one major vendor desperately looking for an "edge" (pun intended) over the others: https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494 They haven't announced browser support. Yet. But I don't think you should rule out DANE just yet. > and it could disappear in other > upstream projects as the popularity of DoH/DoT and other things in the > DNS space eclipse DANE/DNSSEC. Should that happen to the software > Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC > records. I really don't see how you come to that conclusion. The TLSA records won't break anything unless the vendors implmenet broken DANE support. So why would you *have* to remove the records? And DNSSEC is a different game. It's implemented by every caching resolver implmentatio worth mentioning. It's a critical part of the DNS. It is not going away. It is more likely to become mandatory. The DoT/DoH games might end up with even more centralized resolver services than today, but that will just increase the importance of DNSSEC to end users. You obviously cannot trust unsigned DNS data from a distant resolver. This has nothing to do with transport security. The problem with DoH is that you cannot trust a source with unknown management and jurisdiction. Bjørn
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-25 15:40 +0200 |
| Subject | arbitrary code execution on unformatted usb stick |
| Message-ID | <zZtcd-4tn-1@gated-at.bofh.it> |
| In reply to | #5806 |
[Multipart message — attachments visible in raw view] — view raw
Dear readers of the debian-security mailing list The first time I had lost my new coreboot i7 notebook when I plugged a vfat formatted usb stick into the notebook run merely offline where I developed the a̅tea. Suddenly low level operating system errors appeared and since a power off/power on it refuses to boot from any media: internal m2 and usb. The notebook is thus unusable. I have sent the computer for repair but I got it back in the exactly the same condition. If you like you can read https://www.elstel.org/uploads/laptop-note.pdf. It contains an error description (I have written it with my typewriter and the company scanned the document). Consequently I thought that there would be an arbitrary code execution bug in the vfat file system. I prepared an USB stick, created an msdos partition table with 7 partitions and used tar to read and write from the partitions (20-blueusb.rules). However it turned out sooner and later that this also caused arbitrary code executions. It made my offline Debian installation where I run an Apache server to create content for elstel.org several times unusable. I simply could not believe it. A program as simple as tar should not contain an arbitrary code execution bug! There was no other way the system could get in touch with the outside so the usb stick was definitely at fault. Today I have finally used cat and dd to stitch three text files together and read them back from a partition. That way I have avoided to use tar. It was on my most secure system which normally does not have any contact to other computers at all because the system with the Apache server for elstel.org was unsuable for another time. And see there I got the exactly same result without tar: After unexplainable operating system errors the system does not boot as soon as any SATA drive is attached. Flashing the BIOS does not help against this kind of error as there is also other firmware. I have seen 3 of my Kingston USB readers manipulated to not read a certain sdcard while 3 other readers of the same type and same shipping locked in a box did still read it (sdcard blue ray image to install a clean Debian10). Obviously the firmware of that device was altered. As with the USB card reader a computer has many devices each with its own firmware which can be altered to damage a computer. This time I am at loss. If I can not plug in an USB stick there is apparently ¿almost? no safe way to communicate with that computer. There needs to be an arbitrary code execution bug hidden in the kernel which gets executed as soon as a partition table is read in. As I do not have any filesystem on that USB stick and I have automounting disabled that should not be due to filesystem probing. As my experience with bug reporting at the Firefox browser I am quite sure at least some of them are bought by secret services due to their unwillingness to fix flagrant bugs. However I would never have believed this could be the case with the Linux kernel. A kernel developer could perhaps help me if he said what code exactly got executed on plugging in an USB stick. Finally I would need to use another operating system but I can´t as there is no other distribution than Debian which offers a blue ray image for offline installation. Downloading singleton files in a batch via tor is conspicuous to secret services and thus not viable. They would simply alter the download as they have done many times. I wonder how the people at the Iranian nuclear progam do their things? Yours Sincerely, Elmar Stellnberger
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-04-25 15:50 +0200 |
| Subject | Re: arbitrary code execution on unformatted usb stick |
| Message-ID | <zZtlU-4wJ-11@gated-at.bofh.it> |
| In reply to | #5807 |
Am 25.04.20 um 15:38 schrieb Elmar Stellnberger: > Dear readers of the debian-security mailing list > > The first time I had lost my new coreboot i7 notebook when I plugged > a vfat formatted usb stick into the notebook run merely offline where I > developed the a̅tea. Suddenly low level operating system errors appeared > and since a power off/power on it refuses to boot from any media: > internal m2 and usb. The notebook is thus unusable. I have sent the > computer for repair but I got it back in the exactly the same condition. > If you like you can read https://www.elstel.org/uploads/laptop-note.pdf. > It contains an error description (I have written it with my typewriter > and the company scanned the document). > Consequently I thought that there would be an arbitrary code > execution bug in the vfat file system. I prepared an USB stick, created > an msdos partition table with 7 partitions and used tar to read and > write from the partitions (20-blueusb.rules). However it turned out > sooner and later that this also caused arbitrary code executions. It > made my offline Debian installation where I run an Apache server to > create content for elstel.org several times unusable. I simply could not > believe it. A program as simple as tar should not contain an arbitrary > code execution bug! There was no other way the system could get in touch > with the outside so the usb stick was definitely at fault. > Today I have finally used cat and dd to stitch three text files > together and read them back from a partition. That way I have avoided to > use tar. It was on my most secure system which normally does not have > any contact to other computers at all because the system with the Apache > server for elstel.org was unsuable for another time. And see there I got > the exactly same result without tar: After unexplainable operating > system errors the system does not boot as soon as any SATA drive is > attached. Flashing the BIOS does not help against this kind of error as > there is also other firmware. I have seen 3 of my Kingston USB readers > manipulated to not read a certain sdcard while 3 other readers of the > same type and same shipping locked in a box did still read it (sdcard > blue ray image to install a clean Debian10). Obviously the firmware of > that device was altered. As with the USB card reader a computer has many > devices each with its own firmware which can be altered to damage a > computer. > This time I am at loss. If I can not plug in an USB stick there is > apparently ¿almost? no safe way to communicate with that computer. There > needs to be an arbitrary code execution bug hidden in the kernel which > gets executed as soon as a partition table is read in. As I do not have I do not believe the problem is about the msdos partition table as this one is even more simple than invoking tar. But there could (and finally needs) to be hidden something in the usb mass storage driver?! > any filesystem on that USB stick and I have automounting disabled that > should not be due to filesystem probing. As my experience with bug > reporting at the Firefox browser I am quite sure at least some of them > are bought by secret services due to their unwillingness to fix flagrant > bugs. However I would never have believed this could be the case with > the Linux kernel. A kernel developer could perhaps help me if he said > what code exactly got executed on plugging in an USB stick. Finally I > would need to use another operating system but I can´t as there is no > other distribution than Debian which offers a blue ray image for offline > installation. Downloading singleton files in a batch via tor is > conspicuous to secret services and thus not viable. They would simply > alter the download as they have done many times. I wonder how the people > at the Iranian nuclear progam do their things? > > Yours Sincerely, > Elmar Stellnberger
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-05-02 17:00 +0200 |
| Subject | Re: arbitrary code execution on unformatted usb stick |
| Message-ID | <A21Mu-2uw-1@gated-at.bofh.it> |
| In reply to | #5807 |
Am 25.04.20 um 15:38 schrieb Elmar Stellnberger: > Dear readers of the debian-security mailing list > > The first time I had lost my new coreboot i7 notebook when I plugged > a vfat formatted usb stick into the notebook run merely offline where I > developed the a̅tea. Suddenly low level operating system errors appeared > and since a power off/power on it refuses to boot from any media: > internal m2 and usb. The notebook is thus unusable. I have sent the > computer for repair but I got it back in the exactly the same condition. > If you like you can read https://www.elstel.org/uploads/laptop-note.pdf. > It contains an error description (I have written it with my typewriter > and the company scanned the document). > Consequently I thought that there would be an arbitrary code > execution bug in the vfat file system. I prepared an USB stick, created > an msdos partition table with 7 partitions and used tar to read and > write from the partitions (20-blueusb.rules). However it turned out > sooner and later that this also caused arbitrary code executions. It > made my offline Debian installation where I run an Apache server to > create content for elstel.org several times unusable. I simply could not > believe it. A program as simple as tar should not contain an arbitrary > code execution bug! There was no other way the system could get in touch > with the outside so the usb stick was definitely at fault. > Today I have finally used cat and dd to stitch three text files > together and read them back from a partition. That way I have avoided to > use tar. It was on my most secure system which normally does not have > any contact to other computers at all because the system with the Apache > server for elstel.org was unsuable for another time. And see there I got > the exactly same result without tar: After unexplainable operating > system errors the system does not boot as soon as any SATA drive is > attached. Flashing the BIOS does not help against this kind of error as > there is also other firmware. I have seen 3 of my Kingston USB readers > manipulated to not read a certain sdcard while 3 other readers of the > same type and same shipping locked in a box did still read it (sdcard > blue ray image to install a clean Debian10). Obviously the firmware of > that device was altered. As with the USB card reader a computer has many > devices each with its own firmware which can be altered to damage a > computer. > This time I am at loss. If I can not plug in an USB stick there is > apparently ¿almost? no safe way to communicate with that computer. There > needs to be an arbitrary code execution bug hidden in the kernel which > gets executed as soon as a partition table is read in. As I do not have > any filesystem on that USB stick and I have automounting disabled that > should not be due to filesystem probing. As my experience with bug > reporting at the Firefox browser I am quite sure at least some of them > are bought by secret services due to their unwillingness to fix flagrant > bugs. However I would never have believed this could be the case with > the Linux kernel. A kernel developer could perhaps help me if he said > what code exactly got executed on plugging in an USB stick. Finally I > would need to use another operating system but I can´t as there is no > other distribution than Debian which offers a blue ray image for offline > installation. Downloading singleton files in a batch via tor is > conspicuous to secret services and thus not viable. They would simply > alter the download as they have done many times. I wonder how the people > at the Iranian nuclear progam do their things? > > Yours Sincerely, > Elmar Stellnberger On from the beginning I had been in doubt about the conclusion of what I reported in my last email. Such a bug in the usb mass storage driver of the Linux kernel would be extremely hard to hide. From what I believe now that supposed bug does not exist. Very likely they have a remote control of that offline PC used to maintain elstel.org. They are badgering me there too. I already had that with a previous offline computer which is of another model/make. I know it for sure with that computer since they have hindered me there to program a̅tea. I know it from other occasions as well. They knew on my online computer what I was doing offline before. Impossible if they have no connection. It is for them exactly the way as if that computer were online connected with a LAN cable or Wifi. They can do everything there. There was nothing apparently visible on the mainboard but electronic components are small and a component could have been replaced. This time it was most likely before I have received the mainboard and assembled my computer. Consequently as there is no one who would help me and even no one whom I can meet in person who would be interested in what I have to tell from 2011 I will have to give up my security related engagement. Just telling other people about what has happened could help a lot (You remember my German email from last time?). There is for sure a bug in the vfat driver. My System76 notebook was clean as otherwise they would never have left me develop a̅tea on it up to the state in which the tool is at the present time. However there are some things that would need to be done for a̅tea. That DoH/DoT shit in libunbound has an arbitrary code execution bug which concerns a̅tea every time you do not state the server certificate on the command line. You can download the server certificate securely with dig or drill so the tool is basically already fully functional. I would replace libunbound with direct system calls for DNS and verify the trust chain up to the final RRSIG manually by the program. If that condition was met, a̅tea would be fully secure and functional. We have also been talking about missing DANE support for web browsers. I know an easy-to-implement workaround: A https proxy with a Firefox-local configured certification authority. It would forward DANE-enabled sites 1:1 with self-generated certificates. Something that would work for all browsers you can think of. Unfortunately I have no way to implement that as the ultimate defenders of our freedom would simply turn my computer off if I attempted to program anything the like. This is bitter truth!
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.debian.security
csiph-web