Re: debcheckroot v2.0 released
Paul Wise writes: > On Wed, Apr 1, 2020 at 6:01 PM vi...@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
Re: debcheckroot v2.0 released
Hi Paul, I would like to make use of DANE. What software can I use? Odo 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 vi...@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 >
Re: debcheckroot v2.0 released
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 vi...@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
Re: debcheckroot v2.0 released
Hi, 5 avr. 2020 à 12:00 de william.gagn...@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
Re: debcheckroot v2.0 released
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 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 vi...@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 > >
Re: debcheckroot v2.0 released
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 vi...@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
Re: debcheckroot v2.0 released
Am 04.04.20 um 00:46 schrieb Lee: On 4/3/20, Elmar Stellnberger 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.
Re: debcheckroot v2.0 released
On 4/3/20, Elmar Stellnberger 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
Re: debcheckroot v2.0 released
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.
Re: debcheckroot v2.0 released
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.
Re: debcheckroot v2.0 released
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.
Re: debcheckroot v2.0 released
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
Re: debcheckroot v2.0 released
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
Re: debcheckroot v2.0 released
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/.
Re: debcheckroot v2.0 released
Am 02.04.20 um 01:57 schrieb Paul Wise: On Wed, Apr 1, 2020 at 6:01 PM vi...@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?
Re: debcheckroot v2.0 released
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.
Re: debcheckroot v2.0 released
On Wed, Apr 1, 2020 at 6:01 PM vi...@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
Re: debcheckroot v2.0 released
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!
Re: debcheckroot v2.0 released
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!
Re: debcheckroot v2.0 released
Am 25.03.20 um 02:50 schrieb Paul Wise: On Tue, 2020-03-24 at 15:48 +0100, Elmar Stellnberger wrote: I hope this is gonna happen anytime soon. DANE and thus a valid TLSA record is of very high value and importance for getting a genuine download of Debian. As I have mentioned before downloads via Tor can be spoofed like my last Debian Live 10 download which turned out to be infected by debchecheckrooting against the Debian 10 DL-BD. TBH, very few people care about DNSSEC and vastly fewer than that care about DANE so I expect at some point support for both will disappear from both the DNS root servers and all DNS software. You shouldn't be relying on DNSSEC/DANE/TLS to verify Debian image downloads anyway, since they have OpenPGP signatures: https://www.debian.org/CD/faq/#verify https://www.debian.org/CD/verify OpenPGP is no solution to the issue. You need to download the public key and this is usually done over insecure https without DANE. Furthermore it is a vibrant issue that the private key can be stolen even if it is stored offline. How does Debian guard its private key? Is the key used to sign Debian CD images put offline? What security measures do apply? DANE is not gonna disappear. There is no DANE support for the www yet but mail servers do increasingly use DANE. Many public hosters support DNSSEC these days and adding a TLSA record is usually little work if you are in the possession of the server infrastructure. Third, as we have a tool to download over DANE/https now (a̅tea) I would suggest that we should make use of it. According to my experience use of DANE is the only way around this security nightmare. It has proven to hold strong and secure in practice. DANE per se will never disappear as it is the decision of the server maintainers whether to provide a TLSA record or not. DNSSEC per se is used more than DANE.
Re: debcheckroot v2.0 released
On Tue, 2020-03-24 at 15:48 +0100, Elmar Stellnberger wrote: > I hope this is gonna happen anytime soon. DANE and thus a valid TLSA > record is of very high value and importance for getting a genuine > download of Debian. As I have mentioned before downloads via Tor can be > spoofed like my last Debian Live 10 download which turned out to be > infected by debchecheckrooting against the Debian 10 DL-BD. TBH, very few people care about DNSSEC and vastly fewer than that care about DANE so I expect at some point support for both will disappear from both the DNS root servers and all DNS software. You shouldn't be relying on DNSSEC/DANE/TLS to verify Debian image downloads anyway, since they have OpenPGP signatures: https://www.debian.org/CD/faq/#verify https://www.debian.org/CD/verify -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: debcheckroot v2.0 released
Am 24.03.20 um 11:18 schrieb Paul Wise: On Tue, Mar 24, 2020 at 3:33 AM Paul Wise wrote: I've forwarded this to the Debian sysadmins IRC channel. I think it is related to the fact that the cdimage.d.o server is not managed by the Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to get certs, and then of course the TLSA records got outdated after the renewal. For other debian.org domains that are not managed by the Debian sysadmins, we centrally create the certs and propagate them to external services (like the CDNs for deb.d.o). The cdimage.d.o server isn't a CDN and probably doesn't have cert APIs but we can probably use the same approach to fix this. The result was that the mismatch was caused by a bug in the Debian sysadmin puppet. The fix was to remove the TLSA records for this domain due to the aforementioned management disconnect. If the cert management for cdimage.d.o changes to the deb.d.o setup then the TLSA records will return and be correct. I hope this is gonna happen anytime soon. DANE and thus a valid TLSA record is of very high value and importance for getting a genuine download of Debian. As I have mentioned before downloads via Tor can be spoofed like my last Debian Live 10 download which turned out to be infected by debchecheckrooting against the Debian 10 DL-BD.
Re: debcheckroot v2.0 released
On Tue, Mar 24, 2020 at 3:33 AM Paul Wise wrote: > I've forwarded this to the Debian sysadmins IRC channel. I think it is > related to the fact that the cdimage.d.o server is not managed by the > Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to > get certs, and then of course the TLSA records got outdated after the > renewal. For other debian.org domains that are not managed by the > Debian sysadmins, we centrally create the certs and propagate them to > external services (like the CDNs for deb.d.o). The cdimage.d.o server > isn't a CDN and probably doesn't have cert APIs but we can probably > use the same approach to fix this. The result was that the mismatch was caused by a bug in the Debian sysadmin puppet. The fix was to remove the TLSA records for this domain due to the aforementioned management disconnect. If the cert management for cdimage.d.o changes to the deb.d.o setup then the TLSA records will return and be correct. -- bye, pabs https://wiki.debian.org/PaulWise
Re: debcheckroot v2.0 released
On Mon, Mar 23, 2020 at 4:00 PM Elmar Stellnberger wrote: > The only site which is still making problems is cdimage.debian.org. > Could any good Christ from the Debian community have a look at this > issue. The server maintainers would need to complain about the rogue cert! I've forwarded this to the Debian sysadmins IRC channel. I think it is related to the fact that the cdimage.d.o server is not managed by the Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to get certs, and then of course the TLSA records got outdated after the renewal. For other debian.org domains that are not managed by the Debian sysadmins, we centrally create the certs and propagate them to external services (like the CDNs for deb.d.o). The cdimage.d.o server isn't a CDN and probably doesn't have cert APIs but we can probably use the same approach to fix this. -- bye, pabs https://wiki.debian.org/PaulWise
Re: debcheckroot v2.0 released
I have just released a̅tea v0.6: https://www.elstel.org/atea/ . It now implements SNI (Server Name Indication) and can thus also be successfully used to download files like my public gpg key from elstel.org. atea tii-cert -rv https://cdimage.debian.org TLSA record (first three bytes are for TLSA-mode): 03:01:01:0c:8e:2d:2b:49:50:6b:cc:77:f7:70:5d:ee:69:fe:a2:30:93:55:5e:88:a2:68:4c:79:8b:8c:e1:84:2b:32:6f hash of the server certificate: 7d:86:1f:c8:c6:d0:54:ec:74:81:3e:c4:0d:7e:14:45:50:1f:0d:0a:50:11:f1:44:bf:85:cc:6e:2f:8f:cd:ee certificate signature in TLSA record did not match (https://cdimage.debian.org) server cert written to 'cdimage.debian.org-rogue.pem'. The only site which is still making problems is cdimage.debian.org. Could any good Christ from the Debian community have a look at this issue. The server maintainers would need to complain about the rogue cert! Am 04.03.20 um 20:57 schrieb Elmar Stellnberger: If anyone wants to play with atea use it under GPLv3. I forgot to add the license header in the file but this email should entitle you to use the program under GPLv3. Elmar Am 04.03.20 um 20:51 schrieb Elmar Stellnberger: Hint: You can use -v to get a more verbose output if atea fails which includes the sha256 hash of the certificate (-vv would also be possible). From version 0.5 on atea should also do it without the --sys-keyfile option. For me atea succeeds with domains like mail.dotplex.com, secure.dotplex.de or web4.dotplex.com. Pages like ssl-tools.net do already cause problems and my own domain www.elstel.org could sometimes be reached em ordem and sometimes not (see the two certificates in the https://www.elstel.org/DANE/ tar file which have the same start and ending date, one of them is a rogue certificate). The only domain where I have never succeeded is cdimage.debian.org. Is it permanently spoofed or did the Debian maintainers just enter a wrong hash in the TLSA record? Am 04.03.20 um 20:41 schrieb Elmar Stellnberger: It would be a question if anyone has tried to download a SHA512SUMS file from cdimage.debian.org with atea? As it turned out downloading this file with tails/tor is NOT sufficient. I have verified a Debian Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. Debcheckroot reported several infected packages like mkinitramfs, ispell and several pam-modules though mounting the squashfs may already have triggered some malware. Yours Sincerely Elmar Stellnberger Am 04.03.20 um 20:04 schrieb Elmar Stellnberger: Hi folks You can now download the indicated program at https://www.elstel.org/atea/ and read some documentation at https://www.elstel.org/DANE/. Kind Regards, Elmar Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: Hi Cindy Sue! Hi folks! I must confess there is little you can do about missing emails with debcheckroot. You can spot rootkits with hindsight but intelligence can also break in and go without leaving any trace. What would to my mind be necessary for a more secure email communication is a better penetration of DANE. Many CAs are known to issue rogue certificates to secret services so the public key is the only thing that may be trustworthy of a certificate. If that public key is signed and bound to a domain with DNSSEC (this is then called DANE) it shall be safe. I would guess that email dispatching was If safe if encrypted and saved by DANE all the way to its target. F.i. it seems likely that intelligence just tries to halt email delivery if some suspicious email is in the queue until they have assessed what they wanna do about it. And it is questionable how those emails which seem to be sent successfully but which do not reach their target get lost. Something I as an end user can do about the emailing problem is to write and send my emails on a secure machine. If I am using webmail or an emailing program this requires to preconfigure certificates known to be safe and to only allow these. All CAs need to be disabled since the average user will never know which CAs issue rogue certificates. According to my knowledge any simple web page invocation immediately results in a cracked system if it is using a spoofed certificate which can not be excluded for any simple web search. Luckily my hoster provides DANE for the machines used for email delivery, webmailing and my website configuration panel. And I am still using a Debian 8 read only stick to boot such a secure system. Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as long as I only visit these two web pages of my hoster. Unfortunately newer versions of Firefox have a special implementation for so called HSTS (http strict transport security) certificates. You can not add a security exception for such a certificate but you need to configure all dependent certification authorities for such a certificate. However with the first CA you acknowledge you compromise your system`s sec
Re: debcheckroot v2.0 released
https://www.elstel.org/Teorema.html.en Teorema - a modern portuguese short story, freshly translated into English and German :: Debianopolis - o povo cristão Am 04.03.20 um 20:41 schrieb Elmar Stellnberger: It would be a question if anyone has tried to download a SHA512SUMS file from cdimage.debian.org with atea? As it turned out downloading this file with tails/tor is NOT sufficient. I have verified a Debian Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. Debcheckroot reported several infected packages like mkinitramfs, ispell and several pam-modules though mounting the squashfs may already have triggered some malware. Yours Sincerely Elmar Stellnberger Am 04.03.20 um 20:04 schrieb Elmar Stellnberger: Hi folks You can now download the indicated program at https://www.elstel.org/atea/ and read some documentation at https://www.elstel.org/DANE/. Kind Regards, Elmar
Re: debcheckroot v2.0 released
If anyone wants to play with atea use it under GPLv3. I forgot to add the license header in the file but this email should entitle you to use the program under GPLv3. Elmar Am 04.03.20 um 20:51 schrieb Elmar Stellnberger: Hint: You can use -v to get a more verbose output if atea fails which includes the sha256 hash of the certificate (-vv would also be possible). From version 0.5 on atea should also do it without the --sys-keyfile option. For me atea succeeds with domains like mail.dotplex.com, secure.dotplex.de or web4.dotplex.com. Pages like ssl-tools.net do already cause problems and my own domain www.elstel.org could sometimes be reached em ordem and sometimes not (see the two certificates in the https://www.elstel.org/DANE/ tar file which have the same start and ending date, one of them is a rogue certificate). The only domain where I have never succeeded is cdimage.debian.org. Is it permanently spoofed or did the Debian maintainers just enter a wrong hash in the TLSA record? Am 04.03.20 um 20:41 schrieb Elmar Stellnberger: It would be a question if anyone has tried to download a SHA512SUMS file from cdimage.debian.org with atea? As it turned out downloading this file with tails/tor is NOT sufficient. I have verified a Debian Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. Debcheckroot reported several infected packages like mkinitramfs, ispell and several pam-modules though mounting the squashfs may already have triggered some malware. Yours Sincerely Elmar Stellnberger Am 04.03.20 um 20:04 schrieb Elmar Stellnberger: Hi folks You can now download the indicated program at https://www.elstel.org/atea/ and read some documentation at https://www.elstel.org/DANE/. Kind Regards, Elmar Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: Hi Cindy Sue! Hi folks! I must confess there is little you can do about missing emails with debcheckroot. You can spot rootkits with hindsight but intelligence can also break in and go without leaving any trace. What would to my mind be necessary for a more secure email communication is a better penetration of DANE. Many CAs are known to issue rogue certificates to secret services so the public key is the only thing that may be trustworthy of a certificate. If that public key is signed and bound to a domain with DNSSEC (this is then called DANE) it shall be safe. I would guess that email dispatching was If safe if encrypted and saved by DANE all the way to its target. F.i. it seems likely that intelligence just tries to halt email delivery if some suspicious email is in the queue until they have assessed what they wanna do about it. And it is questionable how those emails which seem to be sent successfully but which do not reach their target get lost. Something I as an end user can do about the emailing problem is to write and send my emails on a secure machine. If I am using webmail or an emailing program this requires to preconfigure certificates known to be safe and to only allow these. All CAs need to be disabled since the average user will never know which CAs issue rogue certificates. According to my knowledge any simple web page invocation immediately results in a cracked system if it is using a spoofed certificate which can not be excluded for any simple web search. Luckily my hoster provides DANE for the machines used for email delivery, webmailing and my website configuration panel. And I am still using a Debian 8 read only stick to boot such a secure system. Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as long as I only visit these two web pages of my hoster. Unfortunately newer versions of Firefox have a special implementation for so called HSTS (http strict transport security) certificates. You can not add a security exception for such a certificate but you need to configure all dependent certification authorities for such a certificate. However with the first CA you acknowledge you compromise your system`s security. Older versions of Firefox did not have this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 I am currently looking forward to test which versions of Debian 9 would work. Firefox from Debian 10 does no more work. If you have good luck your webmailing server supports DANE but does not use HSTS. Then you can use a current Debian. With Debian 8 you simply need to delete libnssckbi.so from libnss3 to disable all default CAs. You can not delete them by hand. If you do you need to mark every singleton CA but that does not prevent all deleted CAs to reappear a second after you have deleted them. That is why you needed to delete the .so. With newer versions of Firefox deleting libnssckbi.so does not stay without side effects: You can then not acknowledge security exceptions by hand any more. I have written a script to do that automatically though and I am likely to publish it at https://www.elstel.org/DANE
Re: debcheckroot v2.0 released
Hint: You can use -v to get a more verbose output if atea fails which includes the sha256 hash of the certificate (-vv would also be possible). From version 0.5 on atea should also do it without the --sys-keyfile option. For me atea succeeds with domains like mail.dotplex.com, secure.dotplex.de or web4.dotplex.com. Pages like ssl-tools.net do already cause problems and my own domain www.elstel.org could sometimes be reached em ordem and sometimes not (see the two certificates in the https://www.elstel.org/DANE/ tar file which have the same start and ending date, one of them is a rogue certificate). The only domain where I have never succeeded is cdimage.debian.org. Is it permanently spoofed or did the Debian maintainers just enter a wrong hash in the TLSA record? Am 04.03.20 um 20:41 schrieb Elmar Stellnberger: It would be a question if anyone has tried to download a SHA512SUMS file from cdimage.debian.org with atea? As it turned out downloading this file with tails/tor is NOT sufficient. I have verified a Debian Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. Debcheckroot reported several infected packages like mkinitramfs, ispell and several pam-modules though mounting the squashfs may already have triggered some malware. Yours Sincerely Elmar Stellnberger Am 04.03.20 um 20:04 schrieb Elmar Stellnberger: Hi folks You can now download the indicated program at https://www.elstel.org/atea/ and read some documentation at https://www.elstel.org/DANE/. Kind Regards, Elmar Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: Hi Cindy Sue! Hi folks! I must confess there is little you can do about missing emails with debcheckroot. You can spot rootkits with hindsight but intelligence can also break in and go without leaving any trace. What would to my mind be necessary for a more secure email communication is a better penetration of DANE. Many CAs are known to issue rogue certificates to secret services so the public key is the only thing that may be trustworthy of a certificate. If that public key is signed and bound to a domain with DNSSEC (this is then called DANE) it shall be safe. I would guess that email dispatching was safe if encrypted and saved by DANE all the way to its target. F.i. it seems likely that intelligence just tries to halt email delivery if some suspicious email is in the queue until they have assessed what they wanna do about it. And it is questionable how those emails which seem to be sent successfully but which do not reach their target get lost. Something I as an end user can do about the emailing problem is to write and send my emails on a secure machine. If I am using webmail or an emailing program this requires to preconfigure certificates known to be safe and to only allow these. All CAs need to be disabled since the average user will never know which CAs issue rogue certificates. According to my knowledge any simple web page invocation immediately results in a cracked system if it is using a spoofed certificate which can not be excluded for any simple web search. Luckily my hoster provides DANE for the machines used for email delivery, webmailing and my website configuration panel. And I am still using a Debian 8 read only stick to boot such a secure system. Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as long as I only visit these two web pages of my hoster. Unfortunately newer versions of Firefox have a special implementation for so called HSTS (http strict transport security) certificates. You can not add a security exception for such a certificate but you need to configure all dependent certification authorities for such a certificate. However with the first CA you acknowledge you compromise your system`s security. Older versions of Firefox did not have this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 I am currently looking forward to test which versions of Debian 9 would work. Firefox from Debian 10 does no more work. If you have good luck your webmailing server supports DANE but does not use HSTS. Then you can use a current Debian. With Debian 8 you simply need to delete libnssckbi.so from libnss3 to disable all default CAs. You can not delete them by hand. If you do you need to mark every singleton CA but that does not prevent all deleted CAs to reappear a second after you have deleted them. That is why you needed to delete the .so. With newer versions of Firefox deleting libnssckbi.so does not stay without side effects: You can then not acknowledge security exceptions by hand any more. I have written a script to do that automatically though and I am likely to publish it at https://www.elstel.org/DANE/ in the future if sufficient interest is given in the issue. Once I know the last good Firefox version I could also approach to resolve the bug from above for newer Firefox versions. Unfortunately Dana Keeler has given this bug a
Re: debcheckroot v2.0 released
It would be a question if anyone has tried to download a SHA512SUMS file from cdimage.debian.org with atea? As it turned out downloading this file with tails/tor is NOT sufficient. I have verified a Debian Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. Debcheckroot reported several infected packages like mkinitramfs, ispell and several pam-modules though mounting the squashfs may already have triggered some malware. Yours Sincerely Elmar Stellnberger Am 04.03.20 um 20:04 schrieb Elmar Stellnberger: Hi folks You can now download the indicated program at https://www.elstel.org/atea/ and read some documentation at https://www.elstel.org/DANE/. Kind Regards, Elmar Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: Hi Cindy Sue! Hi folks! I must confess there is little you can do about missing emails with debcheckroot. You can spot rootkits with hindsight but intelligence can also break in and go without leaving any trace. What would to my mind be necessary for a more secure email communication is a better penetration of DANE. Many CAs are known to issue rogue certificates to secret services so the public key is the only thing that may be trustworthy of a certificate. If that public key is signed and bound to a domain with DNSSEC (this is then called DANE) it shall be safe. I would guess that email dispatching was safe if encrypted and saved by DANE all the way to its target. F.i. it seems likely that intelligence just tries to halt email delivery if some suspicious email is in the queue until they have assessed what they wanna do about it. And it is questionable how those emails which seem to be sent successfully but which do not reach their target get lost. Something I as an end user can do about the emailing problem is to write and send my emails on a secure machine. If I am using webmail or an emailing program this requires to preconfigure certificates known to be safe and to only allow these. All CAs need to be disabled since the average user will never know which CAs issue rogue certificates. According to my knowledge any simple web page invocation immediately results in a cracked system if it is using a spoofed certificate which can not be excluded for any simple web search. Luckily my hoster provides DANE for the machines used for email delivery, webmailing and my website configuration panel. And I am still using a Debian 8 read only stick to boot such a secure system. Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as long as I only visit these two web pages of my hoster. Unfortunately newer versions of Firefox have a special implementation for so called HSTS (http strict transport security) certificates. You can not add a security exception for such a certificate but you need to configure all dependent certification authorities for such a certificate. However with the first CA you acknowledge you compromise your system`s security. Older versions of Firefox did not have this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 I am currently looking forward to test which versions of Debian 9 would work. Firefox from Debian 10 does no more work. If you have good luck your webmailing server supports DANE but does not use HSTS. Then you can use a current Debian. With Debian 8 you simply need to delete libnssckbi.so from libnss3 to disable all default CAs. You can not delete them by hand. If you do you need to mark every singleton CA but that does not prevent all deleted CAs to reappear a second after you have deleted them. That is why you needed to delete the .so. With newer versions of Firefox deleting libnssckbi.so does not stay without side effects: You can then not acknowledge security exceptions by hand any more. I have written a script to do that automatically though and I am likely to publish it at https://www.elstel.org/DANE/ in the future if sufficient interest is given in the issue. Once I know the last good Firefox version I could also approach to resolve the bug from above for newer Firefox versions. Unfortunately Dana Keeler has given this bug a resolved invalid so that it is unsure whether they would accept the bugfix upstreams. According to Dana`s comments the bug should in deed be marked as WONTFIX. That would be correct. If you like vote or comment for/on this bug. Elmar Am 17.01.20 um 14:29 schrieb Cindy Sue Causey: On 11/27/19, Elmar Stellnberger wrote: Am 25.11.19 um 12:35 schrieb Patrick Schleizer: Yes, forget about NSA and alike. Let's not assume quasi-omnipotent attackers. That leads to defeatist mindset which isn't productive. I would not let myself be defeated easily. Who has thought about emails in your inbox which are deleted before you can see them? Easily doable. They would just need to know your password. Or about outgoing emails which do not reach their target. As far as I have learnt to know it you can see them in the sent folder
Re: debcheckroot v2.0 released
Hi folks You can now download the indicated program at https://www.elstel.org/atea/ and read some documentation at https://www.elstel.org/DANE/. Kind Regards, Elmar Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: Hi Cindy Sue! Hi folks! I must confess there is little you can do about missing emails with debcheckroot. You can spot rootkits with hindsight but intelligence can also break in and go without leaving any trace. What would to my mind be necessary for a more secure email communication is a better penetration of DANE. Many CAs are known to issue rogue certificates to secret services so the public key is the only thing that may be trustworthy of a certificate. If that public key is signed and bound to a domain with DNSSEC (this is then called DANE) it shall be safe. I would guess that email dispatching was safe if encrypted and saved by DANE all the way to its target. F.i. it seems likely that intelligence just tries to halt email delivery if some suspicious email is in the queue until they have assessed what they wanna do about it. And it is questionable how those emails which seem to be sent successfully but which do not reach their target get lost. Something I as an end user can do about the emailing problem is to write and send my emails on a secure machine. If I am using webmail or an emailing program this requires to preconfigure certificates known to be safe and to only allow these. All CAs need to be disabled since the average user will never know which CAs issue rogue certificates. According to my knowledge any simple web page invocation immediately results in a cracked system if it is using a spoofed certificate which can not be excluded for any simple web search. Luckily my hoster provides DANE for the machines used for email delivery, webmailing and my website configuration panel. And I am still using a Debian 8 read only stick to boot such a secure system. Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as long as I only visit these two web pages of my hoster. Unfortunately newer versions of Firefox have a special implementation for so called HSTS (http strict transport security) certificates. You can not add a security exception for such a certificate but you need to configure all dependent certification authorities for such a certificate. However with the first CA you acknowledge you compromise your system`s security. Older versions of Firefox did not have this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 I am currently looking forward to test which versions of Debian 9 would work. Firefox from Debian 10 does no more work. If you have good luck your webmailing server supports DANE but does not use HSTS. Then you can use a current Debian. With Debian 8 you simply need to delete libnssckbi.so from libnss3 to disable all default CAs. You can not delete them by hand. If you do you need to mark every singleton CA but that does not prevent all deleted CAs to reappear a second after you have deleted them. That is why you needed to delete the .so. With newer versions of Firefox deleting libnssckbi.so does not stay without side effects: You can then not acknowledge security exceptions by hand any more. I have written a script to do that automatically though and I am likely to publish it at https://www.elstel.org/DANE/ in the future if sufficient interest is given in the issue. Once I know the last good Firefox version I could also approach to resolve the bug from above for newer Firefox versions. Unfortunately Dana Keeler has given this bug a resolved invalid so that it is unsure whether they would accept the bugfix upstreams. According to Dana`s comments the bug should in deed be marked as WONTFIX. That would be correct. If you like vote or comment for/on this bug. Elmar Am 17.01.20 um 14:29 schrieb Cindy Sue Causey: On 11/27/19, Elmar Stellnberger wrote: Am 25.11.19 um 12:35 schrieb Patrick Schleizer: Yes, forget about NSA and alike. Let's not assume quasi-omnipotent attackers. That leads to defeatist mindset which isn't productive. I would not let myself be defeated easily. Who has thought about emails in your inbox which are deleted before you can see them? Easily doable. They would just need to know your password. Or about outgoing emails which do not reach their target. As far as I have learnt to know it you can see them in the sent folder but they never appear on the other side, not even in the spam-box. The worse thing is however if someone wants to contact you and you do not even know about it, the other one just thinking you did not reply. There have been two situations that, no, I can't name just this second, so this is anecdotal material *until I stumble back upon* the very real cases, BUT... Twice in the last maybe six months, there has been chatter about the receiving end's server(s) stopping the flow of incoming emails for unknown reasons. The occurrences w
Re: debcheckroot v2.0 released
The programs which I use for secure DANE web browsing should be uploaded at: https://www.elstel.org/DANE/ documentation follows later Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: Hi Cindy Sue! Hi folks! I must confess there is little you can do about missing emails with debcheckroot. You can spot rootkits with hindsight but intelligence can also break in and go without leaving any trace. What would to my mind be necessary for a more secure email communication is a better penetration of DANE. Many CAs are known to issue rogue certificates to secret services so the public key is the only thing that may be trustworthy of a certificate. If that public key is signed and bound to a domain with DNSSEC (this is then called DANE) it shall be safe. I would guess that email dispatching was safe if encrypted and saved by DANE all the way to its target. F.i. it seems likely that intelligence just tries to halt email delivery if some suspicious email is in the queue until they have assessed what they wanna do about it. And it is questionable how those emails which seem to be sent successfully but which do not reach their target get lost. Something I as an end user can do about the emailing problem is to write and send my emails on a secure machine. If I am using webmail or an emailing program this requires to preconfigure certificates known to be safe and to only allow these. All CAs need to be disabled since the average user will never know which CAs issue rogue certificates. According to my knowledge any simple web page invocation immediately results in a cracked system if it is using a spoofed certificate which can not be excluded for any simple web search. Luckily my hoster provides DANE for the machines used for email delivery, webmailing and my website configuration panel. And I am still using a Debian 8 read only stick to boot such a secure system. Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as long as I only visit these two web pages of my hoster. Unfortunately newer versions of Firefox have a special implementation for so called HSTS (http strict transport security) certificates. You can not add a security exception for such a certificate but you need to configure all dependent certification authorities for such a certificate. However with the first CA you acknowledge you compromise your system`s security. Older versions of Firefox did not have this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 I am currently looking forward to test which versions of Debian 9 would work. Firefox from Debian 10 does no more work. If you have good luck your webmailing server supports DANE but does not use HSTS. Then you can use a current Debian. With Debian 8 you simply need to delete libnssckbi.so from libnss3 to disable all default CAs. You can not delete them by hand. If you do you need to mark every singleton CA but that does not prevent all deleted CAs to reappear a second after you have deleted them. That is why you needed to delete the .so. With newer versions of Firefox deleting libnssckbi.so does not stay without side effects: You can then not acknowledge security exceptions by hand any more. I have written a script to do that automatically though and I am likely to publish it at https://www.elstel.org/DANE/ in the future if sufficient interest is given in the issue. Once I know the last good Firefox version I could also approach to resolve the bug from above for newer Firefox versions. Unfortunately Dana Keeler has given this bug a resolved invalid so that it is unsure whether they would accept the bugfix upstreams. According to Dana`s comments the bug should in deed be marked as WONTFIX. That would be correct. If you like vote or comment for/on this bug. Elmar
Re: debcheckroot v2.0 released
Hi Cindy Sue! Hi folks! I must confess there is little you can do about missing emails with debcheckroot. You can spot rootkits with hindsight but intelligence can also break in and go without leaving any trace. What would to my mind be necessary for a more secure email communication is a better penetration of DANE. Many CAs are known to issue rogue certificates to secret services so the public key is the only thing that may be trustworthy of a certificate. If that public key is signed and bound to a domain with DNSSEC (this is then called DANE) it shall be safe. I would guess that email dispatching was safe if encrypted and saved by DANE all the way to its target. F.i. it seems likely that intelligence just tries to halt email delivery if some suspicious email is in the queue until they have assessed what they wanna do about it. And it is questionable how those emails which seem to be sent successfully but which do not reach their target get lost. Something I as an end user can do about the emailing problem is to write and send my emails on a secure machine. If I am using webmail or an emailing program this requires to preconfigure certificates known to be safe and to only allow these. All CAs need to be disabled since the average user will never know which CAs issue rogue certificates. According to my knowledge any simple web page invocation immediately results in a cracked system if it is using a spoofed certificate which can not be excluded for any simple web search. Luckily my hoster provides DANE for the machines used for email delivery, webmailing and my website configuration panel. And I am still using a Debian 8 read only stick to boot such a secure system. Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as long as I only visit these two web pages of my hoster. Unfortunately newer versions of Firefox have a special implementation for so called HSTS (http strict transport security) certificates. You can not add a security exception for such a certificate but you need to configure all dependent certification authorities for such a certificate. However with the first CA you acknowledge you compromise your system`s security. Older versions of Firefox did not have this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 I am currently looking forward to test which versions of Debian 9 would work. Firefox from Debian 10 does no more work. If you have good luck your webmailing server supports DANE but does not use HSTS. Then you can use a current Debian. With Debian 8 you simply need to delete libnssckbi.so from libnss3 to disable all default CAs. You can not delete them by hand. If you do you need to mark every singleton CA but that does not prevent all deleted CAs to reappear a second after you have deleted them. That is why you needed to delete the .so. With newer versions of Firefox deleting libnssckbi.so does not stay without side effects: You can then not acknowledge security exceptions by hand any more. I have written a script to do that automatically though and I am likely to publish it at https://www.elstel.org/DANE/ in the future if sufficient interest is given in the issue. Once I know the last good Firefox version I could also approach to resolve the bug from above for newer Firefox versions. Unfortunately Dana Keeler has given this bug a resolved invalid so that it is unsure whether they would accept the bugfix upstreams. According to Dana`s comments the bug should in deed be marked as WONTFIX. That would be correct. If you like vote or comment for/on this bug. Elmar Am 17.01.20 um 14:29 schrieb Cindy Sue Causey: On 11/27/19, Elmar Stellnberger wrote: Am 25.11.19 um 12:35 schrieb Patrick Schleizer: Yes, forget about NSA and alike. Let's not assume quasi-omnipotent attackers. That leads to defeatist mindset which isn't productive. I would not let myself be defeated easily. Who has thought about emails in your inbox which are deleted before you can see them? Easily doable. They would just need to know your password. Or about outgoing emails which do not reach their target. As far as I have learnt to know it you can see them in the sent folder but they never appear on the other side, not even in the spam-box. The worse thing is however if someone wants to contact you and you do not even know about it, the other one just thinking you did not reply. There have been two situations that, no, I can't name just this second, so this is anecdotal material *until I stumble back upon* the very real cases, BUT... Twice in the last maybe six months, there has been chatter about the receiving end's server(s) stopping the flow of incoming emails for unknown reasons. The occurrences were purely "glitches", NOT on purpose. It was either machine failure or accidentally Human-instigated mis-code or something that provoked the situations. End users found out when a sudden flood of sometimes OLD email suddenly
Re: debcheckroot v2.0 released
On 11/27/19, Elmar Stellnberger wrote: > > Am 25.11.19 um 12:35 schrieb Patrick Schleizer: >> Yes, forget about NSA and alike. Let's not assume quasi-omnipotent >> attackers. That leads to defeatist mindset which isn't productive. > >I would not let myself be defeated easily. Who has thought about > emails in your inbox which are deleted before you can see them? Easily > doable. They would just need to know your password. Or about outgoing > emails which do not reach their target. As far as I have learnt to know > it you can see them in the sent folder but they never appear on the > other side, not even in the spam-box. The worse thing is however if > someone wants to contact you and you do not even know about it, the > other one just thinking you did not reply. There have been two situations that, no, I can't name just this second, so this is anecdotal material *until I stumble back upon* the very real cases, BUT... Twice in the last maybe six months, there has been chatter about the receiving end's server(s) stopping the flow of incoming emails for unknown reasons. The occurrences were purely "glitches", NOT on purpose. It was either machine failure or accidentally Human-instigated mis-code or something that provoked the situations. End users found out when a sudden flood of sometimes OLD email suddenly hit their email inboxes. The last one was just in last few weeks. If and when I re-encounter that information, I'll post for posterity. :) As for the once formerly viewed and then now missing emails, been there, done there. Things being what they are in my own #Life, I've most definitely... "wondered" how the emails "disappeared" when they are NOT something I would have EVER deleted. It affects very few, less than a handful of correspondences. Sanity is found in realizing I have a VERY LARGE inbox.. and I'm surely just not using the right words for my queries. I've convinced myself that I'm using words that convey the same thoughts as the original messages but are not a search string-friendly match for the specific words that were originally written. :) Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: debcheckroot v2.0 released
Am 25.11.19 um 17:52 schrieb Elmar Stellnberger: Not using apt/dpkg comes at the expense of not being able to fully verify the whole system. What if there are outdated packages on the system which aren't available from anymore from repository? Using snapshot.debian.org? I have just extended debcheckroot to also support file repos. Now it can check 100% of the packages I have installed. That was necessary because f.i. the printer driver is vendor specific and can not be fetched from an online repo. I will publish that as debcheckroot v2.2 soon. Outdated packages are a problem though; I have supposed that Debian would maintain sha256sums for packages not available online any more. However I do not see any good possibility to resolve this without support from the distributors. However I am not sure whether outdated updates would still be available on snapshot.debian.org; I would not believe so, though perhaps anyone else reading this list could help us. If it is not about updates but about singleton packages one could download specific packages from snapshot by hand if you really come across having installed such a package. If debcheckroot can not find many packages that may point to an intentionally altered package database and thus to a possible infection of your system. I have seen many ways how to avoid scrutiny by debcheckroot in the past and this may just be an easy way to achieve this. Remember that with a freshly updated system + packages you downloaded manually, 100% of all packages should be verifiable. I do think of the theoretically constructed case that a package is still installed that is no more available via the update repo as rather improbable as normally the base version of all packages is available in the base repo. If a newer version is available in the update repo the update should have been installed as well.
Re: debcheckroot v2.0 released
Am 25.11.19 um 12:35 schrieb Patrick Schleizer: Yes, forget about NSA and alike. Let's not assume quasi-omnipotent attackers. That leads to defeatist mindset which isn't productive. I would not let myself be defeated easily. Who has thought about emails in your inbox which are deleted before you can see them? Easily doable. They would just need to know your password. Or about outgoing emails which do not reach their target. As far as I have learnt to know it you can see them in the sent folder but they never appear on the other side, not even in the spam-box. The worse thing is however if someone wants to contact you and you do not even know about it, the other one just thinking you did not reply. The NSA & 5 Eyes are not just the most omni-potent but also the most-ubiquitous attackers so it should pay off trying to shield against them. There are as much unsuspecting users out there that you can not count. Shouldn´t we motivate them to check their machines? Sometimes it can be as easy as to sport executables in /bin which do not belong there and can normally be found in /usr/bin.
Re: debcheckroot v2.0 released
Am 21.11.19 um 13:59 schrieb Odo Poppinger: Am 20.11.19 um 12:29 schrieb Elmar Stellnberger: debcheckroot is targeted at technically experienced users. No way to hunt rootkits authored by the NSA otherwise. You have to be a tough user to take this challenge! Well you can of course also use it for other kinds of rootkits by other governments or from criminals but interpreting the results requires some kind of knowledge about a Linux system. You need to know what the kernel is, what an initrd is, what you can find under /bin, /usr/bin, /sbin and /usr/sbin. The tool has primarily been written against 5 eyes rootkits but I think it is still missing some features to take this challenge. f.i. it should be possible to unpack *.deb-s in an own boot run, separate from downloading and verification. That would shield against attacks targeted at the unpacking which affect the very system debcheckroot runs on. Supporting file only repos for customly downloaded and installed packages like my printer driver would also be an issue. Why not simply use sha256 - lists as can already be used and generated with debcheckroot (as far as I have seen)? That would resolve the problem of a possible infection of the host system running debcheckroot because there are no archives that need to be unpacked when using plain sha256 file lists. We would only need some official support by Debian for this, i.e. someone who creates/updates these sha256 lists every time the updates repository is updated and puts them online in a publicly known place. You can avoid an infection of the host system by generating sha256sums in one boot run with -t my.shalis --no-verify and use this on another boot with -u my.shalis --only --offline. I have now documented these options on the official webpage https://www.elstel.org/debcheckroot/. Options to download on a separate machine are also documented. Besides this I have revised the documentation as a whole so it may be worth reading it once more. Today in the evening I have released debcheckroot-v2.2. You may view all the updates at https://www.elstel.org/ViewRSS.php?ctgs=programs&lang=en or via https://www.elstel.org/ViewRSS.php?srcs=debcheckroot&lang=en
Re: debcheckroot v2.0 released
Am 25.11.19 um 12:35 schrieb Patrick Schleizer: How often did you see initrd being infected? recently only once. So the attackers may change their vector; they have already done so multiple times. Not using apt/dpkg comes at the expense of not being able to fully verify the whole system. What if there are outdated packages on the system which aren't available from anymore from repository? Using snapshot.debian.org? I have just extended debcheckroot to also support file repos. Now it can check 100% of the packages I have installed. That was necessary because f.i. the printer driver is vendor specific and can not be fetched from an online repo. I will publish that as debcheckroot v2.2 soon. Outdated packages are a problem though; I have supposed that Debian would maintain sha256sums for packages not available online any more. However I do not see any good possibility to resolve this without support from the distributors. However I am not sure whether outdated updates would still be available on snapshot.debian.org; I would not believe so, though perhaps anyone else reading this list could help us. If it is not about updates but about singleton packages one could download specific packages from snapshot by hand if you really come across having installed such a package. Also, for quickly repeatable verification it would be best to prepare as much as possible in background / during upgrade. Other tasks can be done at the same time. Then booting from read-only to debcheckroot purposes could safe a lot time. The less time it needs, the more it gets within reach to automate the process without sacrificing much boot time. Also by not using apt/dpkg, any packages downloaded would have to be gpg verified manually. I also don't see debcheckroot make use of gpg signature verification of downloaded files? Reinventing apt is difficult. See these attack on package managers: https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html Package metadata could be outdated. Downloaded package contents could be malicious or altered to pass verification. Yes, tor is no ultimate remedy to this. As long as there are little downloads anonymity may be compromised. The best way to shield against such attacks may be to first generate sha256sum lists in a singleton boot and then later on use them in another boot so that no malware from unpacking packages can persist in memory. However that is no remedy to altered package content. The only way I know to avoid this is to only install from blue ray media without using online updates. That article https://www.elstel.org/software/GnuPG-usage.html.en starts with "How to use GnuPG securely". That isn't the best way to communicate "Key signatures are not trustworthy in general" which is a pretty broad claim. If "Key signatures are not trustworthy in general" then all apt package downloads could be considered compromised since APT relies on gnupg for verification. With that was true, and with mindset, and that being unfixable, we could as well as give up. Yes, that is what I presume. apt can install compromised updates. I know this is at least an attack vector for Windows. To repeat it I would at least doubt if not presume about any key which is stored online that it is compromised. Most times people connect with ssh to such machines and have a local certificate on the computer from which they connect. The certificate can be copied and the password will be keylogged. Only a very few people employ security strategies like switching keyboard and monitor to a computer where you do not web-browse or email. I have devices for that but most people don´t and as long as the distributors do not advertise it I presume that they do not follow such a strategy. Finally it would still be possible to get the key by physical access to that computer. I would also believe that for a distro like Debian this would pay of for intelligence services. To me personally I don´t have a defeatist mindset even not if the NSA/CIA or similar services are attacking me. They have once deleted the partition table on a computer used only offline to analyse some rootkit. Those who hack me also have physical access to my computers. There is no way for a defeatist mindset though as I can not let my human rights including that to live be violated. To a rootkit hunter which laymen can use it's a long way to go. Some debcheckroot is targeted at technically experienced users. That's sad. Understood. No it isn´t. People who care about security need to acquaint themselves with some basic facts on how the system they use is working. As it is Linux all the information should be available for the interested user. - and people do not only need to do so for use of debcheckroot. No way to hunt rootkits authored by the NSA otherwise. Yes, forget about NSA and alike. Let's not assume quasi-omnipotent attackers. That leads to defeatist
Re: debcheckroot v2.0 released
Elmar Stellnberger: >>> Things debcheckroot does not check at the moment are the initrd and >> the MBR (master boot record). You may unpack the initrd by hand and >> check the files contained there against a sha256sum list generated by >> debcheckroot. The MBR can first be backuped by confinedrv/diskutils. >> Then reinstall it with Grub from a fresh boot CD and look if the boot >> sector has altered. Under normal circumstances Grub would install the >> exactly same code into the MBR. >> >> >> I guess "nobody" is going to do that. Sounds complicated. And I am > > The issue is that you do not need to check the initrd in deed under > normal circumstances. If the initrd is infected so will be > /sbin/mkinitramfs. Not necessarily. There are a lot more options to write a malicious initrd other than infecting /sbin/mkinitramfs. A rootkit could re-mount the real /sbin/mkinitramfs to a compromised hidden file /sbin/mkinitramfs, use LD_PRELOAD tricks and probably much more. > I have never seen the initrd being infected alone as > this would need to be updated on every new kernel configuration update > like when you install firmware. How often did you see initrd being infected? >> I would also suggest a different design / additional feature. Rather >> than requiring a network connection or DVD, could you add a feature >> please similar to "apt-file" or "command-not-found"? What I mean by that: >> >> These tools download a cache while the system is running. debcheckroot >> could download/generate/prepare all the sha256 files on the disk. Yes, >> within the running system. Don't worry about verifying integrity of >> these files just yet. That will be answered later. Yes, these sha256 >> files could be maliciously altered. But that is something you can check >> later at debcheckroot runtime. > > What you suggest here does not make sense to me. If you have to check > ®enerate these sha256 lists later on it is the same work as if you do > not use them. Later on you don't have to re-generate the sha256 lists. Just verify their signatures. >> Generating the (sha256) files required for later verification could be >> done using an apt or dpkg hook. > > No, it is a feature of the tool that it does not require the dpkg > infrastructure. - an important one. I have even successfully verified an > old Debian6 installation with debcheckroot-v2.0. - no binaries required, > only plain Python available almost everywhere. Not using apt/dpkg comes at the expense of not being able to fully verify the whole system. What if there are outdated packages on the system which aren't available from anymore from repository? Using snapshot.debian.org? Also, for quickly repeatable verification it would be best to prepare as much as possible in background / during upgrade. Other tasks can be done at the same time. Then booting from read-only to debcheckroot purposes could safe a lot time. The less time it needs, the more it gets within reach to automate the process without sacrificing much boot time. Also by not using apt/dpkg, any packages downloaded would have to be gpg verified manually. I also don't see debcheckroot make use of gpg signature verification of downloaded files? Reinventing apt is difficult. See these attack on package managers: https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html Package metadata could be outdated. Downloaded package contents could be malicious or altered to pass verification. >> Then, later when debcheckroot runs, it would rely on these files. But to >> check that these files haven't been altered, it could check them against >> repository signing keys. So debcheckroot would need a bit root of trust >> built-in or better configurable. For example, it could be sufficient to >> point debcheckroot at clean Debian repository signing keys. These would >> then be used to check the sha256 files. > > Key signatures are not trustworthy in general. I have argued this a 100 > times; see also https://www.elstel.org/software/GnuPG-usage.html.en That article https://www.elstel.org/software/GnuPG-usage.html.en starts with "How to use GnuPG securely". That isn't the best way to communicate "Key signatures are not trustworthy in general" which is a pretty broad claim. If "Key signatures are not trustworthy in general" then all apt package downloads could be considered compromised since APT relies on gnupg for verification. With that was true, and with mindset, and that being unfixable, we could as well as give up. >> To a rootkit hunter which laymen can use it's a long way to go. Some > > debcheckroot is targeted at technically experienced users. That's sad. Understood. > No way to > hunt rootkits authored by the NSA otherwise. Yes, forget about NSA and alike. Let's not assume quasi-omnipotent attackers. That leads to defeatist mindset which isn't productive. > Well you can of course also use it for other > kinds of rootkits by other governments or from criminals
Re: debcheckroot v2.0 released
Yes, that is a very good idea!: * debcheckroot with sha256-lists is considerably faster because it does not need to download and unpack all packages * unknown/forgotten packages of elder versions could still be checked because the sha256sums are not forgotten * You can generate sha256sums incrementally with debcheckroot, i.e. extend an existing list only for the new packages Great! I remember there were semi-public sha256-sum file lists for Windows. Why not have this for important Linux distributions as well? It should not be too hard to do. Furthermore once you have such a sha256-list you are independent from a specific tool. There is no serious checking against malware if you do not have the sha256s!!
Re: debcheckroot v2.0 released
Am 21.11.19 um 13:59 schrieb Odo Poppinger: Am 20.11.19 um 12:29 schrieb Elmar Stellnberger: debcheckroot is targeted at technically experienced users. No way to hunt rootkits authored by the NSA otherwise. You have to be a tough user to take this challenge! Well you can of course also use it for other kinds of rootkits by other governments or from criminals but interpreting the results requires some kind of knowledge about a Linux system. You need to know what the kernel is, what an initrd is, what you can find under /bin, /usr/bin, /sbin and /usr/sbin. The tool has primarily been written against 5 eyes rootkits but I think it is still missing some features to take this challenge. f.i. it should be possible to unpack *.deb-s in an own boot run, separate from downloading and verification. That would shield against attacks targeted at the unpacking which affect the very system debcheckroot runs on. Supporting file only repos for customly downloaded and installed packages like my printer driver would also be an issue. Why not simply use sha256 - lists as can already be used and generated with debcheckroot (as far as I have seen)? That would resolve the problem of a possible infection of the host system running debcheckroot because there are no archives that need to be unpacked when using plain sha256 file lists. We would only need some official support by Debian for this, i.e. someone who creates/updates these sha256 lists every time the updates repository is updated and puts them online in a publicly known place. Yes, that is a very good idea!: * debcheckroot with sha256-lists is considerably faster because it does not need to download and unpack all packages * unknown/forgotten packages of elder versions could still be checked because the sha256sums are not forgotten * You can generate sha256sums incrementally with debcheckroot, i.e. extend an existing list only for the new packages
Re: debcheckroot v2.0 released
Am 20.11.19 um 12:29 schrieb Elmar Stellnberger: debcheckroot is targeted at technically experienced users. No way to hunt rootkits authored by the NSA otherwise. You have to be a tough user to take this challenge! Well you can of course also use it for other kinds of rootkits by other governments or from criminals but interpreting the results requires some kind of knowledge about a Linux system. You need to know what the kernel is, what an initrd is, what you can find under /bin, /usr/bin, /sbin and /usr/sbin. The tool has primarily been written against 5 eyes rootkits but I think it is still missing some features to take this challenge. f.i. it should be possible to unpack *.deb-s in an own boot run, separate from downloading and verification. That would shield against attacks targeted at the unpacking which affect the very system debcheckroot runs on. Supporting file only repos for customly downloaded and installed packages like my printer driver would also be an issue. Why not simply use sha256 - lists as can already be used and generated with debcheckroot (as far as I have seen)? That would resolve the problem of a possible infection of the host system running debcheckroot because there are no archives that need to be unpacked when using plain sha256 file lists. We would only need some official support by Debian for this, i.e. someone who creates/updates these sha256 lists every time the updates repository is updated and puts them online in a publicly known place.
Re: debcheckroot v2.0 released
Am 19.11.19 um 13:29 schrieb Patrick Schleizer: Anyone using this yet? I would speculate, not many are using it. It needs step by step instructions. Otherwise, most users are lost at hello. Well, I have a couple of downloads every day, the more serious ones with wget. Things debcheckroot does not check at the moment are the initrd and the MBR (master boot record). You may unpack the initrd by hand and check the files contained there against a sha256sum list generated by debcheckroot. The MBR can first be backuped by confinedrv/diskutils. Then reinstall it with Grub from a fresh boot CD and look if the boot sector has altered. Under normal circumstances Grub would install the exactly same code into the MBR. I guess "nobody" is going to do that. Sounds complicated. And I am The issue is that you do not need to check the initrd in deed under normal circumstances. If the initrd is infected so will be /sbin/mkinitramfs. I have never seen the initrd being infected alone as this would need to be updated on every new kernel configuration update like when you install firmware. [tor-dev] First-time tails/tor user feedback https://lists.torproject.org/pipermail/tor-dev/2012-April/003472.html Eliminating Stop-Points in the Installation and Use ofAnonymity Systems: a Usability Evaluation of the Tor Browser Bundle https://petsymposium.org/2012/papers/hotpets12-1-usability.pdf I would also suggest a different design / additional feature. Rather than requiring a network connection or DVD, could you add a feature please similar to "apt-file" or "command-not-found"? What I mean by that: These tools download a cache while the system is running. debcheckroot could download/generate/prepare all the sha256 files on the disk. Yes, within the running system. Don't worry about verifying integrity of these files just yet. That will be answered later. Yes, these sha256 files could be maliciously altered. But that is something you can check later at debcheckroot runtime. What you suggest here does not make sense to me. If you have to check ®enerate these sha256 lists later on it is the same work as if you do not use them. Generating the (sha256) files required for later verification could be done using an apt or dpkg hook. No, it is a feature of the tool that it does not require the dpkg infrastructure. - an important one. I have even successfully verified an old Debian6 installation with debcheckroot-v2.0. - no binaries required, only plain Python available almost everywhere. Then, later when debcheckroot runs, it would rely on these files. But to check that these files haven't been altered, it could check them against repository signing keys. So debcheckroot would need a bit root of trust built-in or better configurable. For example, it could be sufficient to point debcheckroot at clean Debian repository signing keys. These would then be used to check the sha256 files. Key signatures are not trustworthy in general. I have argued this a 100 times; see also https://www.elstel.org/software/GnuPG-usage.html.en The advantage of this would be that debcheckroot can be run from Live USD or Live DVD. Offline. No need for a network connection since all files to be verified would already be prepared. debcheckroot can already perfectly run offline from the live cd of any distribution. I think you didn´t read the docs. To a rootkit hunter which laymen can use it's a long way to go. Some debcheckroot is targeted at technically experienced users. No way to hunt rootkits authored by the NSA otherwise. You have to be a tough user to take this challenge! Well you can of course also use it for other kinds of rootkits by other governments or from criminals but interpreting the results requires some kind of knowledge about a Linux system. You need to know what the kernel is, what an initrd is, what you can find under /bin, /usr/bin, /sbin and /usr/sbin. The tool has primarily been written against 5 eyes rootkits but I think it is still missing some features to take this challenge. f.i. it should be possible to unpack *.deb-s in an own boot run, separate from downloading and verification. That would shield against attacks targeted at the unpacking which affect the very system debcheckroot runs on. Supporting file only repos for customly downloaded and installed packages like my printer driver would also be an issue. Once, the more people are using debcheckroot via Tails the harder it will get for intelligence to spoof these downloads. Effectiveness of debcheckroot is also an issue of a critical mass of users who apply the tool at least from time to time. Most people do not take the threat posed by rootkits authored by western intelligence serious, though. I believe only a very few users are using Tails with --download-only as this was not well supported with debcheckroot-v2.0 but nobody had complained. It would have been possible to download via Tor using deblive linked
Re: debcheckroot v2.0 released
Anyone using this yet? I would speculate, not many are using it. It needs step by step instructions. Otherwise, most users are lost at hello. > Things debcheckroot does not check at the moment are the initrd and the MBR (master boot record). You may unpack the initrd by hand and check the files contained there against a sha256sum list generated by debcheckroot. The MBR can first be backuped by confinedrv/diskutils. Then reinstall it with Grub from a fresh boot CD and look if the boot sector has altered. Under normal circumstances Grub would install the exactly same code into the MBR. I guess "nobody" is going to do that. Sounds complicated. And I am saying that as a fairly technical user. (Maintaining Debian derivative distributions...) Users need very detailed step-by-step instructions. This is my experience from over 7 years of Whonix user support. Murphy's law. Anything can go wrong, will go wrong. Keep it simple stupid (KISS). Some stuff on usability: Quote To Toggle, or not to Toggle: The End of Torbutton https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton > mike, am i completely anonymized if i log onto my facebook account? im using firefox 3.6 with tor and no script on windows 7 machine. thank you. Quote https://www.bbc.com/news/technology-20445632 > In order to make sure the mobile phone frequencies are not being tracked, I would fill up a washbasin with water and put the lid of a rice cooker over my head while I made a phone call," said one interviewee, a 28-year-old man who left the country in November 2010. [tor-dev] First-time tails/tor user feedback https://lists.torproject.org/pipermail/tor-dev/2012-April/003472.html Eliminating Stop-Points in the Installation and Use ofAnonymity Systems: a Usability Evaluation of the Tor Browser Bundle https://petsymposium.org/2012/papers/hotpets12-1-usability.pdf I would also suggest a different design / additional feature. Rather than requiring a network connection or DVD, could you add a feature please similar to "apt-file" or "command-not-found"? What I mean by that: These tools download a cache while the system is running. debcheckroot could download/generate/prepare all the sha256 files on the disk. Yes, within the running system. Don't worry about verifying integrity of these files just yet. That will be answered later. Yes, these sha256 files could be maliciously altered. But that is something you can check later at debcheckroot runtime. Generating the (sha256) files required for later verification could be done using an apt or dpkg hook. Then, later when debcheckroot runs, it would rely on these files. But to check that these files haven't been altered, it could check them against repository signing keys. So debcheckroot would need a bit root of trust built-in or better configurable. For example, it could be sufficient to point debcheckroot at clean Debian repository signing keys. These would then be used to check the sha256 files. The advantage of this would be that debcheckroot can be run from Live USD or Live DVD. Offline. No need for a network connection since all files to be verified would already be prepared. debcheckroot could be a Debian package that gets installed in the running system. And then starts preparing the sha256 files for later verification. It could also run the verification within the running system. That would just be an integrity check and no rootkit hunt. Since a system that is already running could be infected with a rootkit already. (Similar to debsums.) The same debcheckroot package then could also be used started from a Live USD or Live DVD and then "just" change the root (local of what debcheckroot should check) from the boot medium to the internal hard drive. debcheckroot could then verify that the existing sha256 files on the disk have valid signatures and if so, start the verification of all individual files. To a rootkit hunter which laymen can use it's a long way to go. Some rhetorical question questions. How to I create a Live DVD / USB to check my running system? Download such a Live DVD / USB image somewhere? How do I mount the internal hard drive? Or mount an internal full disk encrypted disk? Then run debcheckroot on it? Could this be fully automated so these tests can be run routinely, easy? Graphical user interface? Run debcheckroot fully automated at boot (from read-only boot medium such as Live DVD), verify all files, then continue booting from the internal disk (kexec)? That would be similar to the verified boot feature which is already a default feature in iPhone, Android, and ChromeOS. Can we get iPhone and Android Level Security for Linux Desktop Distributions? https://www.whonix.org/wiki/Kicksecure#iPhone_and_Android_Level_Security_for_Linux_Desktop_Distributions Cheers, Patrick Elmar Stellnberger: > Dear readers of debian-security > > I have just released debcheckroot-v2.0: > https://www.elstel.org/debcheckroot/ > > The new tool can be used to check a De
