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
