• debcheckroot v2.0 released

    From Elmar Stellnberger@21:1/5 to All on Wed Nov 20 12:30:02 2019
    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 &regenerate 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 from https://www.elstel.org/debcheckroot/ (https://www.elstel.org/deblive/)
    but I guess hardly anyone or nobody at all did. With debcheckroot-v2.1
    using Tails should be well supported, at least the way I do so. When you
    know that repository signing keys can be stolen (there is an own key
    stealing programme) things like 'torsocks apt-get update' can make sense.

    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

    The serious user should have a Tails CD handy. At best buy that with a
    Linux magazine at your local newspaper kiosk. Downloading it insecurely directly via the internet may not be a good idea.

    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.

    automated so these tests can be run routinely, easy? Graphical user interface? Run debcheckroot fully automated at boot (from read-only boot

    You can not run that fully automatically as it needs a human being to
    analyse and interpret the results.

    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?
    I believe there is no security for Android and iPhone systems as you can
    not unmount and check the boot partition of these devices.
    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


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Odo Poppinger@21:1/5 to All on Thu Nov 21 14:10:02 2019
    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.

    <div dir="ltr"><div class="gmail-moz-cite-prefix">Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:<br>
    </div>
    <blockquote type="cite">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.
    <br>

    <br>
    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.
    <br>

    <br>
    </blockquote>
    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.</div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Thu Nov 21 14:30:01 2019
    This is a multi-part message in MIME format.
    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




    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Am 21.11.19 um 13:59 schrieb Odo
    Poppinger:<br>
    </div>
    <blockquote type="cite" cite="mid:CAAivX6j=-whEcAZ+8Zqt6sj2SZbi=RoWAW309LB=QECCFSyPSg@mail.gmail.com">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div dir="ltr">
    <div class="gmail-moz-cite-prefix">Am 20.11.19 um 12:29 schrieb
    Elmar Stellnberger:<br>
    </div>
    <blockquote type="cite">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. <br>
    <br>
    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. <br>
    <br>
    </blockquote>
    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.</div>
    </blockquote>
    <p>Yes, that is a very good idea!:</p>
    <p>* debcheckroot with sha256-lists is considerably faster because
    it does not need to download and unpack all packages</p>
    <p>* unknown/forgotten packages of elder versions could still be
    checked because the sha256sums are not forgotten</p>
    <p>* You can generate sha256sums incrementally with debcheckroot,
    i.e. extend an existing list only for the new packages<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lewis Yarema@21:1/5 to All on Fri Nov 22 12:10:01 2019
    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!!

    <div dir="ltr"><p><br>

    </p><blockquote type="cite">




    <p>Yes, that is a very good idea!:</p>


    <p>* debcheckroot with sha256-lists is considerably faster because
    it does not need to download and unpack all packages</p>


    <p>* unknown/forgotten packages of elder versions could still be
    checked because the sha256sums are not forgotten</p>


    <p>* You can generate sha256sums incrementally with debcheckroot,
    i.e. extend an existing list only for the new packages</p></blockquote><p>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!!<br></p><blockquote type="cite"><p></p>



    </blockquote>
    </div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Patrick Schleizer@21:1/5 to All on Mon Nov 25 12:40:02 2019
    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 &regenerate 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 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.


    Why couldn't it be fully automated without manual interpretation needed?


    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.


    Usability and popularity. Both hard. Software is only step 1.

    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.


    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.

    Can we get iPhone and Android Level Security for Linux Desktop
    Distributions?
    I believe there is no security for Android and iPhone systems as you can
    not unmount and check the boot partition of these devices.


    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.

    Kind regards,
    Patrick

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Mon Nov 25 18:00:01 2019
    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 mindset which isn't productive.

    I have already commented on this.

    Why couldn't it be fully automated without manual interpretation needed?

    That is not so easy to answer but an unsuspecting novice user simply
    will not be safe. There are just too many pitfalls. You do not need to
    know much but you need to understand some crucial facts to my believe.
    The thing why you can not automate this is that there is a hack for any automation how it can be bypassed. Whenever I have found something it
    was due to some unexpected action taken by me and not because the tools
    were so super. The NSA has a billion budget (correct me if someone knows
    the exact amount) and you won´t be smarter in programming than they are.

    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.

    My attack scenarios always include key loggers. They are a too valuable
    tool for intelligence to miss this possibility. On the other hand my
    equipment hasn´t been stolen yet. Nonetheless anyone needs to know his
    enemies and what kind of attacks to shield against.

    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.

    Well it is GPLv3. Anyone who would like to extend or develop it into
    some other direction is free to do so if he has enough energy and
    resources to do so.

    I hope I have sufficiently answered you questions and your points of discussion. If not simply re-ask.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Mon Nov 25 22:20:02 2019
    This is a multi-part message in MIME format.
    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


    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>Am 21.11.19 um 13:59 schrieb Odo Poppinger:<br>
    </p>
    <blockquote type="cite" cite="mid:CAAivX6j=-whEcAZ+8Zqt6sj2SZbi=RoWAW309LB=QECCFSyPSg@mail.gmail.com">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div dir="ltr">
    <div class="gmail-moz-cite-prefix">Am 20.11.19 um 12:29 schrieb
    Elmar Stellnberger:<br>
    </div>
    <blockquote type="cite">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. <br>
    <br>
    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. <br>
    <br>
    </blockquote>
    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.</div>
    </blockquote>
    <p>  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
    <a class="moz-txt-link-freetext" href="https://www.elstel.org/debcheckroot/">https://www.elstel.org/debcheckroot/</a>. 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.</p>
    <p>  Today in the evening I have released debcheckroot-v2.2. You may
    view all the updates at
    <a class="moz-txt-link-freetext" href="https://www.elstel.org/ViewRSS.php?ctgs=programs&amp;lang=en">https://www.elstel.org/ViewRSS.php?ctgs=programs&amp;lang=en</a> or
    via
    <a class="moz-txt-link-freetext" href="https://www.elstel.org/ViewRSS.php?srcs=debcheckroot&amp;lang=en">https://www.elstel.org/ViewRSS.php?srcs=debcheckroot&amp;lang=en</a><br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Wed Nov 27 12:10:01 2019
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Tue Dec 10 17:40:02 2019
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cindy Sue Causey@21:1/5 to Elmar Stellnberger on Fri Jan 17 14:40:02 2020
    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 :)
    --
    Cindy-Sue Causey
    Talking Rock, Pickens County, Georgia, USA

    * runs with birdseed *

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Fri Jan 17 17:00:02 2020
    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-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 :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Fri Jan 17 17:20:01 2020
    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



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Wed Mar 4 20:50:02 2020
    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 <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 :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Wed Mar 4 20:20:02 2020
    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-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 :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Wed Mar 4 21:00:03 2020
    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 :)


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Sat Mar 21 17:40:02 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Mon Mar 23 17:10:02 2020
    This is a multi-part message in MIME format.
    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 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 :)


    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUhUekNDQmplZ0F3SUJBZ0lTQThmenNr Z1l0Q0g3ZVRvNWZqamYwTGlrTUEwR0NTcUdTSWIzRFFFQkN3VUEKTUVveEN6QUpCZ05WQkFZ VEFsVlRNUll3RkFZRFZRUUtFdzFNWlhRbmN5QkZibU55ZVhCME1TTXdJUVlEVlFRRApFeHBN WlhRbmN5QkZibU55ZVhCMElFRjFkR2h2Y21sMGVTQllNekFlRncweU1EQXpNVEF5TWpFek16 ZGFGdzB5Ck1EQTJNRGd5TWpFek16ZGFNQmt4RnpBVkJnTlZCQU1URG1aMGNDNWhZMk11ZFcx MUxuTmxNSUlCSWpBTkJna3EKaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUF1SjVB MHd2WG5EdGFCVkpwWFNaZWR6MVZqQ29tOHQ1SQpmc3BncEZ5d3BUUWVIam1xR0FPelhCTXFK a2N3SDZDY3M0NEd2Smw4aUVOZk9sVjNPNFo2UllFRTIrRjFpRVNCCmZOZHNtUTJFU251TU9j bld3RXdGMkpiY1VJSmRkeERqcjl3SGhVUlRpcksvWGYzeTdubGhUbWVpaFNvMS84d1IKRmxY SHk0eWx4UzkxYmw4UnZYOWo4Y0VXb0RWbjdmTnhWZ0wxZk41d29sNlE1dmN3SnFSeWowaHYr SFAwdmFrcwpXaXRMUkNtTk5udXpUUEhwMzdRTXJpdXBzTi9maW5TRFhXbFFXS3FtZVRkSktZ ZHVaWlk0UUNkT1ZDb1NoL3lzCjBIZ1M2bWRTeXVlbDd1QjBTVC9UVTZOdmhHNGtacysyZlk2 SnkwclpoR0VNSjluNk9wVU5nUUlEQVFBQm80SUUKWGpDQ0JGb3dEZ1lEVlIwUEFRSC9CQVFE QWdXZ01CMEdBMVVkSlFRV01CUUdDQ3NHQVFVRkJ3TUJCZ2dyQmdFRgpCUWNEQWpBTUJnTlZI Uk1CQWY4RUFqQUFNQjBHQTFVZERnUVdCQlFtL3A0ZVNlOTYxbDFKc21wOFhMbEozU0NyCjRU QWZCZ05WSFNNRUdEQVdnQlNvU21wakJIM2R1dWJST2JlbVJXWHY4Nmpzb1RCdkJnZ3JCZ0VG QlFjQkFRUmoKTUdFd0xnWUlLd1lCQlFVSE1BR0dJbWgwZEhBNkx5OXZZM053TG1sdWRDMTRN eTVzWlhSelpXNWpjbmx3ZEM1dgpjbWN3THdZSUt3WUJCUVVITUFLR0kyaDBkSEE2THk5alpY SjBMbWx1ZEMxNE15NXNaWFJ6Wlc1amNubHdkQzV2CmNtY3ZNSUlDRXdZRFZSMFJCSUlDQ2pD Q0FnYUNEbUZqWXk1a2JDNXZjMlJ1TG1wd2doQmhjbU5vYVhabExuTjEKYm1WMExuTmxnaEZq WVdWellYSXVZV05qTG5WdGRTNXpaWUlWWTJGbGMyRnlMbVowY0M1aFkyTXVkVzExTG5ObApn aEpqWkdsdFlXZGxMbVJsWW1saGJpNXZjbWVDRUdOc2IzVmtMbVJsWW1saGJpNXZjbWVDRG1a MGNDNWhZMk11CmRXMTFMbk5sZ2cxbWRIQXVaMjV2YldVdWIzSm5nZ3htZEhBdWMzVnVaWFF1 YzJXQ0VXZGxiVzFsYVM1aFkyTXUKZFcxMUxuTmxnaFZuWlcxdFpXa3VablJ3TG1Gall5NTFi WFV1YzJXQ0VXZGxibk5vYnk1aFkyTXVkVzExTG5ObApnaFZuWlc1emFHOHVablJ3TG1Gall5 NTFiWFV1YzJXQ0RtZGxkQzVrWldKcFlXNHViM0puZ2hSb1lXMXRkWEpoCllta3VZV05qTG5W dGRTNXpaWUlZYUdGdGJYVnlZV0pwTG1aMGNDNWhZMk11ZFcxMUxuTmxnaEZzWVc5MGVuVXUK WVdOakxuVnRkUzV6WllJVmJHRnZkSHAxTG1aMGNDNWhZMk11ZFcxMUxuTmxnaHR0WldWMGFX NW5jeTFoY21ObwphWFpsTG1SbFltbGhiaTV1WlhTQ0UyNWhjRzlzWlc5dUxtRmpZeTUxYlhV dWMyV0NGMjVoY0c5c1pXOXVMbVowCmNDNWhZMk11ZFcxMUxuTmxnaEZ6WVdsdFpXa3VZV05q TG5WdGRTNXpaWUlWYzJGcGJXVnBMbVowY0M1aFkyTXUKZFcxMUxuTmxnaFowZFhSaGJtdG9Z VzF2Ymk1aFkyTXVkVzExTG5ObGdocDBkWFJoYm10b1lXMXZiaTVtZEhBdQpZV05qTG5WdGRT NXpaVEJNQmdOVkhTQUVSVEJETUFnR0JtZUJEQUVDQVRBM0Jnc3JCZ0VFQVlMZkV3RUJBVEFv Ck1DWUdDQ3NHQVFVRkJ3SUJGaHBvZEhSd09pOHZZM0J6TG14bGRITmxibU55ZVhCMExtOXla ekNDQVFNR0Npc0cKQVFRQjFua0NCQUlFZ2ZRRWdmRUE3d0IxQVBDVnBGbnlBTkdDUUJBdEw1 T0lqcTFML2gxSDQ1bmgwRFNtc0tpcQpqckp6QUFBQmNNYTVtU3dBQUFRREFFWXdSQUlnY3ZL OVhyMDRkOHZ2Q3N5Qkx1cXRSaG9rUXk2RmVhL0hrZ1RvCjh0WUtFMnNDSUFGa21vRC93TzNR bTVHdll0cHdvQ0RZcmlYaG54YTk3L29rOFZmZW1paCtBSFlBc2g0RnpJdWkKellvZ1RvZG0r U3U1aWlVZ1oydmErbkRuc2tsVExlK0xrRjRBQUFGd3hybVpPd0FBQkFNQVJ6QkZBaUFySE5l NQo1SHV0aGpJME8zbXdQejRpei9za2ZiN1VQYS9zZEJyRTROdjREd0loQUpjNklKZkhZVVYr K1F6cUZHaHBVYy90CktpQVdQQzJkVkZMeDRWQkJyRmtqTUEwR0NTcUdTSWIzRFFFQkN3VUFB NElCQVFCR0dRaFZENjVRNnVlM3FRbkYKQ3V0NUlIZ0hFUTQ2eE5iNWpGeXdOS1Q2NEh3MXky Z2l3Zm96RHBNTTFLUVBrRGUxaGFHTUh5eTZCQ0xTZE15cwpacnB5ZkN6NEgvUXE4V0RhWjJJ OHA1RW50Nk1nZ1NEZmRYSGkyRkxNRHJUdzZBMWZITGQ5YURQd3M1VDNnTVEvCjRETkwxRkR1 TS9TcmVnZ1dUVUFJUm5RS0lsL04xSjRiTE1CVzNNZldOMUtDcWxLNGM4bHV5ODlOTDdjQkg5 Yk0KQWlpV01oa1FWSEdyY2IxUjFyVlFqMHZDa2dpYmw4NDN4MTZKaGloK2JhaG9VdGd2Mm4x NUpvUjRyeE5NeDhpSwp2ai8rV0xna0lHdzNQanc5NWNpWnpTMGRJOUdkZXQ0bnl4N3RYZTZP MWpGZlc5N2pwVTNvZ1oxYUJhcFN1NCtECmd0WkkKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0t
    LQo=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to All on Tue Mar 24 04:40:01 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to All on Tue Mar 24 11:20:02 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Tue Mar 24 15:50:04 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Elmar Stellnberger on Wed Mar 25 03:00:01 2020
    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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl56uPgACgkQMRa6Xp/6 aaOLSA/+MV8EVdHQLp6hvDF9SuNu8Qv6wXu/eAlE3owBU/p6fuCkzB7Hrg65lYfP Qq3SzQ8klp/rUZsiFOPg8H7b9aW6K20B/+AFigo0fVVP3MTIkq1YQyrx5XUUWfzy wsZVXMcIyA4QBPK8y/fveugG+j92qZv1eGfUr+SEVkde31HwEl8tPbCb7Tt3NqRR 4a5lxd7OAHJsdmpv4PjMdLBuxGh1O2MZDsVOaswQc6TXjtfmiUSJaQ/wRFO+Yooh VuFhLBXlSOZS90+5vnzvfUEoRX+GlhC8b7w2CudfEFP9rigHi41wkwZcJAPGfZEk f6FIol19hQbUVrsH/IGIJEmGqe3bAR2LOU74UELl2n1/CD5652mLcVW6FMlsLO9x HIxwLAOtbrHdtwcIsBzMf5QDSWHgA7j05LVaJZQGb5QU+IFiADAxuOb2LefD5G5E W/JzDniQxUW7gB0uP7miwuzMqC9k6lqE0HuhHt2TKVsbnGA1DBXWGW212jLs/B0g OBhLi/r5mqRx+2JhOiHC5STRthULNx9EkIkjKQOAekoq8dNZHqq983bwOeKEXHeA XIQ/fFrpVFBz7T+dCw6Rf9iEe6nULMJUZoiQKNe/hULp46X/dVTPmME28777quDu kMiBJC5fkDBVTRMz8wpUar9LBaMF7GdgkJn7ula1kqKmaLHkscE=
    =STgl
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Wed Mar 25 11:30:01 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Thu Mar 26 11:10:02 2020
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From vince@vheuser.com@21:1/5 to Elmar Stellnberger on Wed Apr 1 20:10:01 2020
    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!



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to vince@vheuser.com on Thu Apr 2 02:00:01 2020
    On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:

    Did the discussion of continuing support for DANE end??

    In case I mislead anyone, a clarification:

    Debian itself isn't going to actively work on removing support for
    DANE from anything nor removing our DANE/DNSSEC records.

    Support for DANE is never going to happen for the web (given the
    opinions of the major browser makers) and it could disappear in other
    upstream projects as the popularity of DoH/DoT and other things in the
    DNS space eclipse DANE/DNSSEC. Should that happen to the software
    Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
    records.

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lewis Yarema@21:1/5 to All on Thu Apr 2 11:20:02 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Thu Apr 2 16:50:01 2020
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Thu Apr 2 17:00:01 2020
    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/.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Niall O'Reilly@21:1/5 to Paul Wise on Thu Apr 2 18:30:01 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lee@21:1/5 to Paul Wise on Thu Apr 2 21:00:01 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Thu Apr 2 21:40:01 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Fri Apr 3 13:40:01 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Fri Apr 3 13:50:02 2020
      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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lee@21:1/5 to Elmar Stellnberger on Sat Apr 4 00:50:01 2020
    On 4/3/20, Elmar Stellnberger <estellnb@elstel.org> wrote:
    There are a few reasons why I believe that DANE / TLSA DNS RR answers
    are quite trustworthy:

    Yes, DANE / TLSA DNS RR answers seem trustworthy. What I don't
    consider trustworthy is the clear-text traffic between the client and
    the DNSSEC enabled resolver.

    Let's say that I'm using 1.1.1.1 as my resolver. Cloudflare comes up
    with a trustworthy answer, but I don't trust the clear-text traffic
    from Cloudflare to my PC. With DOH, I can trust the answer that comes
    back from Cloudlfare to my PC.

    * DNS responses are much faster than establishing a TCP connection
    (1.5RTT), usually only about 40ms also because DNS servers tend to be
    near the user if not provided by the ISP while the server you wanna
    contact is usually in another country or another federal state. As we
    know from the Snowden Revelations spoofing connections only works if the
    spoofed response is faster than the original response. My idea about it
    is that the NSA and related intelligence simply do not have an
    infrastructure to spoof DNS responses.

    Maybe not.. but I keep going back to the basic idea (prejudice?) that clear-text traffic is inherently untrustworthy. What any particular
    group can/can't do is not an interesting question to me.

    * There is a public/private key signing infrastructure for DANE as well
    but I consider that more secure than a gpg private key used on a system
    with emailing or web browsing. I believe it is much more hard to get
    into a server than is to get into a client.

    Finally DANE has been invented for the reason to restore trust in the
    internet - as it was there initially when there was no operation Quantum
    insert or similar operations. I´d believe the DANE system has been
    designed secure as to serve its purpose. Finally my own practical
    experience with DANE is very positive. It appeared to be the only way to
    prevent site spoofing:
    https://lists.debian.org/debian-security/2020/01/threads.html
    https://lists.debian.org/debian-security/2020/02/threads.html
    https://lists.debian.org/debian-security/2020/03/threads.html

    The reason why browser developers have not adopted DANE yet is that
    they side with intelligence (secret services) as the following bug
    report shows me:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1606802

    If I'm understanding your bug report correctly, I'm not at all
    surprised they didn't change anything. It seems like what you want is
    the modern equivalent of the Cert Patrol addon; it's a shame that
    functionality isn't in firefox any more :(

    Finally I have forgotten about the most important reason why DANE is
    much more secure than other methods:

    * There is a regular, secure and automatic key rotation for DANE. With
    GnuPG keys can be happily stolen as they remain valid for a year or more
    and as there is no secure way to redistribute a new key.

    Yes, GPG Key distribution/revocation seems to be a weak point.

    Concerning DoH/DoT I would rather believe these technologies to be detrimental as encryption adds an additional error prone overhead but
    does not contribute anything to the authenticity of the reply.

    I don't trust clear-text communications; it seems like DoH/DoT solves
    that problem.. at least for dnssec enabled domains. While encryption
    adds an additional error prone overhead, I'll still take that risk
    over the risk of using a clear-text communications channel.

    Encryption can be a source of arbitrary code execution exploits if not implemented properly. Encrypting DNS would have other application
    purposes and makes sense as long as you use a proxy. If you connect
    directly hiding the domain name is ineffective because someone who spys
    at the connection also knows the IPs you connect to and via SNI the
    cleartext of the domain you surf at.

    Yes, but "trusting the answer" and "keeping my communications private"
    are not quite the same thing. If we're talking about "trusting the
    answer" I'll take DoT or running my own dnssec enabled resolver. When
    I'm more concerned about "keeping my communications private" I'll take
    TOR & accept the trade-off of slower speed.

    Regards,
    Lee

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Sat Apr 4 09:40:02 2020
    Am 04.04.20 um 00:46 schrieb Lee:
    On 4/3/20, Elmar Stellnberger <estellnb@elstel.org> wrote:
    Encryption can be a source of arbitrary code execution exploits if not
    implemented properly. Encrypting DNS would have other application
    purposes and makes sense as long as you use a proxy. If you connect
    directly hiding the domain name is ineffective because someone who spys
    at the connection also knows the IPs you connect to and via SNI the
    cleartext of the domain you surf at.

    Yes, but "trusting the answer" and "keeping my communications private"
    are not quite the same thing. If we're talking about "trusting the
    answer" I'll take DoT or running my own dnssec enabled resolver. When
    I'm more concerned about "keeping my communications private" I'll take
    TOR & accept the trade-off of slower speed.


    I think we have to separate two issues here: authenticity asserting
    that the answer is correct and confidentiality asserting that no one
    else knows about a message. Signing asserts authenticity while
    encryption can guarantee confidentiality. With GnuPG encrypted messages
    are also signed by default so that both features are provided. That does
    not tell however that both issues are clearly separated. Encryption by
    itself does not contribute anything to the authenticity of a reply, i.e.
    you do not know from whom it came. With signing the correctness of an
    answer can be asserted but the answer itself can be read in cleartext by everyone unless it is additionally encrypted.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Sat Apr 4 09:50:01 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From l0f4r0@tuta.io@21:1/5 to All on Sun Apr 5 12:30:01 2020
    Hi,

    5 avr. 2020 à 12:00 de william.gagnebe@gmail.com:

    could you please > remove > me from the debian-security mailing list? 
    It's been year (true story) that I'm asking for that, and I don't even know how it is possible coming from an IT group .. :D

    Please do this ecological contribution ..

    Obviously you don't know that such action must be done by yourself: https://www.debian.org/MailingLists/unsubscribe

    Best regards,
    l0f4r0

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?William_Gagneb=C3=A9?=@21:1/5 to All on Sun Apr 5 12:20:02 2020
    Hello,

    could you please *remove *me from the debian-security mailing list?
    It's been year (true story) that I'm asking for that, and I don't even know
    how it is possible coming from an IT group .. :D

    Please do this ecological contribution ..

    Regards


    Le sam. 4 avr. 2020 à 09:47, Elmar Stellnberger <estellnb@elstel.org> a
    écrit :

    Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:
    Am 02.04.20 um 01:57 schrieb Paul Wise:
    On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:

    Did the discussion of continuing support for DANE end??

    In case I mislead anyone, a clarification:

    Debian itself isn't going to actively work on removing support for
    DANE from anything nor removing our DANE/DNSSEC records.

    Support for DANE is never going to happen for the web (given the
    opinions of the major browser makers) and it could disappear in other
    upstream projects as the popularity of DoH/DoT and other things in the
    DNS space eclipse DANE/DNSSEC. Should that happen to the software
    Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
    records.


    What software is currently used for DNSSEC/DANE by Debian?
    What do you mean by DoH/DoT?


    Dear Paul,

    Can you answer us that question: What software does Debian use that supports DANE? I do not know of any except dig and drill.

    Yours,
    Elmar Stellnberger



    <div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hello, </div><div><br></div><div>
    could you please <b>remove </b>me from the debian-security mailing list? </div><div>It&#39;s been year (true story) that I&#39;m asking for that, and I don&#39;t even know how it is possible coming from an IT group .. :D</div><div><br></div><div>Please
    do this ecological contribution ..</div><div><br></div><div>Regards</div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 4 avr. 2020 à 09:47, Elmar
    Stellnberger &lt;<a href="mailto:estellnb@elstel.org">estellnb@elstel.org</a>&gt; a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 02.04.20 um 16:49 schrieb
    Elmar Stellnberger:<br>
    &gt; Am 02.04.20 um 01:57 schrieb Paul Wise:<br>
    &gt;&gt; On Wed, Apr 1, 2020 at 6:01 PM <a href="mailto:vince@vheuser.com" target="_blank">vince@vheuser.com</a> wrote:<br>
    &gt;&gt;<br>
    &gt;&gt;&gt; Did the discussion of continuing support for DANE end??<br> &gt;&gt;<br>
    &gt;&gt; In case I mislead anyone, a clarification:<br>
    &gt;&gt;<br>
    &gt;&gt; Debian itself isn&#39;t going to actively work on removing support for<br>
    &gt;&gt; DANE from anything nor removing our DANE/DNSSEC records.<br> &gt;&gt;<br>
    &gt;&gt; Support for DANE is never going to happen for the web (given the<br> &gt;&gt; opinions of the major browser makers) and it could disappear in other<br>
    &gt;&gt; upstream projects as the popularity of DoH/DoT and other things in the<br>
    &gt;&gt; DNS space eclipse DANE/DNSSEC. Should that happen to the software<br> &gt;&gt; Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC<br> &gt;&gt; records.<br>
    &gt;&gt;<br>
    &gt; <br>
    &gt; What software is currently used for DNSSEC/DANE by Debian?<br>
    &gt; What do you mean by DoH/DoT?<br>
    &gt; <br>

    Dear Paul,<br>

       Can you answer us that question: What software does Debian use that <br> supports DANE? I do not know of any except dig and drill.<br>

    Yours,<br>
    Elmar Stellnberger<br>

    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Tue Apr 7 17:50:02 2020
    Am 04.04.20 um 09:47 schrieb Elmar Stellnberger:
    Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:
    Am 02.04.20 um 01:57 schrieb Paul Wise:
    On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:

    Did the discussion of continuing support for DANE end??

    In case I mislead anyone, a clarification:

    Debian itself isn't going to actively work on removing support for
    DANE from anything nor removing our DANE/DNSSEC records.

    Support for DANE is never going to happen for the web (given the
    opinions of the major browser makers) and it could disappear in other
    upstream projects as the popularity of DoH/DoT and other things in the
    DNS space eclipse DANE/DNSSEC. Should that happen to the software
    Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
    records.


    What software is currently used for DNSSEC/DANE by Debian?
    What do you mean by DoH/DoT?


    Dear Paul,

      Can you answer us that question: What software does Debian use that supports DANE? I do not know of any except dig and drill.

    Yours,
    Elmar Stellnberger

    ping

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Odo Poppinger@21:1/5 to All on Sun Apr 12 18:10:02 2020
    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 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 dir="ltr"><div class="gmail-moz-cite-prefix">Hi Paul,</div><div class="gmail-moz-cite-prefix"><br></div><div class="gmail-moz-cite-prefix">  I would like to make use of DANE. What software can I use?</div><div class="gmail-moz-cite-prefix"><br></
    <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">&gt; Am 02.04.20 um 16:49 schrieb Elmar Stellnberger:<br>&gt;&gt; Am 02.04.20 um 01:57 schrieb Paul Wise:<br>&gt;&gt;&gt; On Wed, Apr 1, 2020 at 6:01 PM <a href="mailto:vince@vheuser.com">vince@
    vheuser.com</a> wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Did the discussion of continuing support for DANE end??<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; In case I mislead anyone, a clarification:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Debian itself isn&#39;t going to
    actively work on removing support for<br>&gt;&gt;&gt; DANE from anything nor removing our DANE/DNSSEC records.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Support for DANE is never going to happen for the web (given the<br>&gt;&gt;&gt; opinions of the major browser
    makers) and it could disappear in other<br>&gt;&gt;&gt; upstream projects as the popularity of DoH/DoT and other things in the<br>&gt;&gt;&gt; DNS space eclipse DANE/DNSSEC. Should that happen to the software<br>&gt;&gt;&gt; Debian uses for DNS/DANE, we
    may be forced to drop our DANE/DNSSEC<br>&gt;&gt;&gt; records.<br>&gt;&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; What software is currently used for DNSSEC/DANE by Debian?<br>&gt;&gt; What do you mean by DoH/DoT?<br>&gt;&gt;<br>&gt; <br>&gt; Dear Paul,<br>&gt; <br>
    &gt;   Can you answer us that question: What software does Debian use that <br>&gt; supports DANE? I do not know of any except dig and drill.<br>&gt; <br>&gt; Yours,<br>&gt; Elmar Stellnberger<br>&gt; <br></span></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to Paul Wise on Tue Apr 14 09:30:02 2020
    Paul Wise <pabs@debian.org> writes:
    On Wed, Apr 1, 2020 at 6:01 PM vince@vheuser.com wrote:

    Did the discussion of continuing support for DANE end??

    In case I mislead anyone, a clarification:

    Debian itself isn't going to actively work on removing support for
    DANE from anything nor removing our DANE/DNSSEC records.

    Support for DANE is never going to happen for the web (given the
    opinions of the major browser makers)

    Well, there is one major vendor desperately looking for an "edge" (pun intended) over the others:

    https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494

    They haven't announced browser support. Yet. But I don't think you
    should rule out DANE just yet.

    and it could disappear in other
    upstream projects as the popularity of DoH/DoT and other things in the
    DNS space eclipse DANE/DNSSEC. Should that happen to the software
    Debian uses for DNS/DANE, we may be forced to drop our DANE/DNSSEC
    records.


    I really don't see how you come to that conclusion. The TLSA records
    won't break anything unless the vendors implmenet broken DANE support.
    So why would you *have* to remove the records?

    And DNSSEC is a different game. It's implemented by every caching
    resolver implmentatio worth mentioning. It's a critical part of the
    DNS. It is not going away. It is more likely to become mandatory.

    The DoT/DoH games might end up with even more centralized resolver
    services than today, but that will just increase the importance of
    DNSSEC to end users. You obviously cannot trust unsigned DNS data from a distant resolver. This has nothing to do with transport security. The
    problem with DoH is that you cannot trust a source with unknown
    management and jurisdiction.


    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)