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
Reply to: