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 andthe 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
[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.
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 fromI believe there is no security for Android and iPhone systems as you can
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?
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 Debian installation also against
previously unknown rootkits. It has many improvements towards
debcheckroot-v1.0:
# usage of direct comparison or creation and usage of sha-256 lists
instead of the unsafe md5sums provided in the package header
# allow usage of multiple changeable media: i.e. DVD & BD-SL
verification rather than just BD-DL verification
# testing of symbolic links, of user, group and file-mode
# scanning the home directory for odd filenames that contain control
characters, on request: listing all hidden binary files in the home
directory
# download only mode + shuffling of download order for package download
via Tails/Tor and subsequent offline verification
# use of Python3 instead of Perl with built in support for tar, xzip,
gzip and bzip2; no more external helper programs required, works from
any live cd!
Finally debcheckroot-v1.0 did no more work with current versions of
Debian as Debian now uses xzip instead of gzip. The new program supports
any of xzip, gzip and bz2 for compression of the data.tar.xz and the
controls .tar.xz inside the .deb ar-archive. Files are merely unpacked
in memory so debcheckroot keeps being quite efficient.
I would be happy to discuss the new release here or to assist anyone who
wants to test the new tool!
Regards,
Elmar
Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
debcheckroot is targeted at technically experienced users. No way toWhy not simply use sha256 - lists as can already be used and generated
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.
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.
Things debcheckroot does not check at the moment are the initrd andthe 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.
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
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.
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.
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 from https://www.elstel.org/debcheckroot/ (https://www.elstel.org/deblive/)
but I guess hardly anyone or nobody at all did.
do I mount the internal hard drive? Or mount an internal full disk
encrypted disk? Then run debcheckroot on it? Could this be fully
I disadvise full disk encryption because you may easily loose your data. Better carry an M2 stick with you. Disk encryption can be cracked easily
by installing a keylogger which will log the keyboard key strokes to get
the encryption key.
Can we get iPhone and Android Level Security for Linux DesktopI believe there is no security for Android and iPhone systems as you can
Distributions?
not unmount and check the boot partition of these devices.
How often did you see initrd being infected?
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.
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. Somedebcheckroot 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.
Why couldn't it be fully automated without manual interpretation needed?
Usability and popularity. Both hard. Software is only step 1.
Full disk encryption is proven effective. If one travels and a bag gets stolen by a criminal, no data can be accessed.
Keyloggers are really bad but unrelated from that.
Yes, Android has security features which are working fine, reliable,
would be replicable on Linux desktops in principle, but aren't yet.
That's the point of that writeup.
https://www.whonix.org/wiki/Kicksecure#iPhone_and_Android_Level_Security_for_Linux_Desktop_Distributions
debcheckroot could help getting something like verified boot for Debian.
Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
debcheckroot is targeted at technically experienced users. No way toWhy not simply use sha256 - lists as can already be used and generated
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.
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, forget about NSA and alike. Let's not assume quasi-omnipotent
attackers. That leads to defeatist mindset which isn't productive.
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.
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.
On 11/27/19, Elmar Stellnberger <estellnb@gmail.com> wrote:
Am 25.11.19 um 12:35 schrieb Patrick Schleizer:
Yes, forget about NSA and alike. Let's not assume quasi-omnipotentI would not let myself be defeated easily. Who has thought about
attackers. That leads to defeatist mindset which isn't productive.
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 :)
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
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 <estellnb@gmail.com> wrote:
Am 25.11.19 um 12:35 schrieb Patrick Schleizer:
Yes, forget about NSA and alike. Let's not assume quasi-omnipotentI 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
attackers. That leads to defeatist mindset which isn't productive.
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 :)
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 <estellnb@gmail.com> wrote:
Am 25.11.19 um 12:35 schrieb Patrick Schleizer:
Yes, forget about NSA and alike. Let's not assume quasi-omnipotentI would not let myself be defeated easily. Who has thought about
attackers. That leads to defeatist mindset which isn't productive.
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 :)
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/ 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 <estellnb@gmail.com> 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 :)
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
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/ 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 <estellnb@gmail.com> 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 :)
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.
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.
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
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.
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!
Did the discussion of continuing support for DANE end??
On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.
Support for DANE is never going to happen for the web (given the
opinions of the major browser makers) and it could disappear in other upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.
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.
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.
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)
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
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/.
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.
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
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.
On 4/3/20, Elmar Stellnberger <estellnb@elstel.org> wrote:
Encryption can be a source of arbitrary code execution exploits if not
implemented properly. Encrypting DNS would have other application
purposes and makes sense as long as you use a proxy. If you connect
directly hiding the domain name is ineffective because someone who spys
at the connection also knows the IPs you connect to and via SNI the
cleartext of the domain you surf at.
Yes, but "trusting the answer" and "keeping my communications private"
are not quite the same thing. If we're talking about "trusting the
answer" I'll take DoT or running my own dnssec enabled resolver. When
I'm more concerned about "keeping my communications private" I'll take
TOR & accept the trade-off of slower speed.
Am 02.04.20 um 01:57 schrieb Paul Wise:
On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.
Support for DANE is never going to happen for the web (given the
opinions of the major browser makers) and it could disappear in other
upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.
What software is currently used for DNSSEC/DANE by Debian?
What do you mean by DoH/DoT?
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 ..
Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:
Am 02.04.20 um 01:57 schrieb Paul Wise:
On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.
Support for DANE is never going to happen for the web (given the
opinions of the major browser makers) and it could disappear in other
upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.
What software is currently used for DNSSEC/DANE by Debian?
What do you mean by DoH/DoT?
Dear Paul,
Can you answer us that question: What software does Debian use that supports DANE? I do not know of any except dig and drill.
Yours,
Elmar Stellnberger
Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:
Am 02.04.20 um 01:57 schrieb Paul Wise:
On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.
Support for DANE is never going to happen for the web (given the
opinions of the major browser makers) and it could disappear in other
upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.
What software is currently used for DNSSEC/DANE by Debian?
What do you mean by DoH/DoT?
Dear Paul,
Can you answer us that question: What software does Debian use that supports DANE? I do not know of any except dig and drill.
Yours,
Elmar Stellnberger
Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:
Am 02.04.20 um 01:57 schrieb Paul Wise:
On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.
Support for DANE is never going to happen for the web (given the
opinions of the major browser makers) and it could disappear in other
upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.
What software is currently used for DNSSEC/DANE by Debian?
What do you mean by DoH/DoT?
Dear Paul,
Can you answer us that question: What software does Debian use that supports DANE? I do not know of any except dig and drill.
Yours,
Elmar Stellnberger
<div class="gmail-moz-cite-prefix">Odo<br></div><div class="gmail-moz-cite-prefix"><br></div><div class="gmail-moz-cite-prefix">Am 04.04.20 um 09:47 schrieb Elmar Stellnberger:<br></div><span style="white-space:pre-wrap;display:block;width:98vw">> Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:<br>>> Am 02.04.20 um 01:57 schrieb Paul Wise:<br>>>> On Wed, Apr 1, 2020 at 6:01 PM <a href="mailto:vince@vheuser.com">vince@
On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:
Did the discussion of continuing support for DANE end??
In case I mislead anyone, a clarification:
Debian itself isn't going to actively work on removing support for
DANE from anything nor removing our DANE/DNSSEC records.
Support for DANE is never going to happen for the web (given the
opinions of the major browser makers)
and it could disappear in other
upstream projects as the popularity of DoH/DoT and other things in the
DNS space eclipse DANE/DNSSEC. Should that happen to the software
Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
records.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 85:07:13 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,097 |
Messages: | 5,276,965 |