Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Thursday May 01 2014, @12:14PM   Printer-friendly
from the its-progress dept.

What has been planned for a long time now, prior to the infamous heartbleed fiasco of OpenSSL (which does not affect SSH at all), is now officially a reality - with the help of some recently adopted crypto from DJ Bernstein. OpenSSH now finally has a compile-time option to no longer depend on OpenSSL, the option `make OPENSSL=no` has now been introduced for a reduced-configuration OpenSSH to be built without OpenSSL.

The result would leave you with no legacy SSH-1 baggage at all, and on the SSH-2 front with only AES-CTR and chacha20+poly1305 ciphers, ECDH/curve25519 key exchange and Ed25519 public keys.

[Editor's Note: This appears to be very much a Work-in-Progress, so might not be available for your distro or via standard repositories.]

Related Stories

Using OpenBSD Routing Tables to Segment the Home Network for Privacy 13 comments

OpenBSD user Lari Huttunen has a blog post in which he dives into using OpenBSD's rdomain(4) feature to sort work VPNs into separate kernel-level routing tables. This segregates the network traffic in such a way as to prevent traffic in separate routing tables from interacting. With many working from home, insecure work networks have begun to intrude into the home LANs via work-related VPNs. By adding the home network to a work VPN, the LAN becomes merged with work's internal network, usually quite insecure at that. His goal is to keep his personal home devices, especially the IoT items, separate from the now mandatory work-related VPNs on his small-office / home-office network. That way, the work networks can no longer access his appliances.

Problem Statement

Over the years, companies and corporations have become ever more hungry for everything related to their users' geolocation, telemetry, demography, relationsip with one another, interests, convictions, social preferences - you name it. At the same time, users wanting to consume digital services meet a lot of ridiculous restrictions depending on where they live and how they access the Internet. Ecojails, in one form or another are created by multi-national corporations in order to capitalize everything about their users' behavior. In 2020, this has all been exacerbated by everyone suddenly working from home if possible.

Motivation

This is why I wanted to research how identity-based routing could enhance users' privacy in a totally transparent way. I've never been a big fan of VPNs as a security solution, but have come to realize that they have a role to play in privacy. Since soon everything needs to be online to function from a vacuum cleaner to dish washer to toaster, it is increasingly difficult to keep the Internet of Targets at bay. Moreover, our personal telemetry devices feed out a constant stream of information to the ecojail masters, be they Apple, Google, Microsoft, Amazon, Alibaba or Netflix. Taking back control will not be easy and one will evidently need to compromise along the way, but realization is the first step to recovery.

Lari's solution works from tools provided by OpenBSD's base system.

Previously:
(2020) WireGuard Imported Into OpenBSD
(2019) How SSH Key Shielding Works
(2019) Dutch Govt Explains the Risks Behind DNS-Over-HTTPS Move
(2014) OpenSSH No Longer has to Depend on OpenSSL


Original Submission

Timeline to Remove DSA Support from OpenSSH 3 comments

OpenSSH developer, Damien Miller, has announced plans to remove support for DSA keys from OpenSSH in the near future. His announcement describes the rationale, process, and proposed timeline.

The next release of OpenSSH (due around 2024/03) will make DSA optional at compile time, but still enable it by default. Users and downstream distributors of OpenSSH may use this option to explore the impact of DSA removal in their environments, or to hard-deprecate it early if they desire.

Around 2024/06, a release of OpenSSH will change this compile-time default to disable DSA. It may still be enabled by users/distributors if needed.

Finally, in the first OpenSSH release after 2025/01/01 the DSA code will be removed entirely.

In summary:

2024/01 - this announcement
2024/03 (estimated) - DSA compile-time optional, enabled by default
2024/06 (estimated) - DSA compile-time optional, *disabled* by default
2025/01 (estimated) - DSA is removed from OpenSSH

Very few will notice this change. However, for those few to whom this matters the effects are major.

Previously:
(2021) scp Will Be Replaced With sftp Soon
(2020) SHA-1 to be Disabled in OpenSSH and libssh
(2019) How SSH Key Shielding Works
(2016) Upgrade Your SSH Keys
(2014) OpenSSH No Longer has to Depend on OpenSSL


Original Submission

OpenSSH 6.8 Will Feature Key Discovery and Rotation for Easier Switching to DJB's Ed25519 6 comments

OpenSSH developer Damien Miller wrote from Down Under about a new feature he implemented and committed for the next upcoming 6.8 release of OpenSSH — hostkeys@openssh.com — an OpenSSH extension to the SSH protocol for sshd to automatically send all of its public keys to the client, and for the client to automatically replace all keys of such server within ~/.ssh/known_hosts with the fresh copies as supplied (provided the server is trusted in the first place, of course).

The protocol extension is simple enough, and is aimed to make it easier to switch over from DSA to the OpenSSL-free Ed25519 public keys. It is also designed in such a way as to support the concept of spare host keys being stored offline, which could then seamlessly replace main active keys should they ever become compromised.

scp Will Be Replaced With sftp Soon 32 comments

OpenSSH 8.8 has been released and with it comes a heads up that there will be major changes to how the scp utility operates, starting in one of the next releases. Specifically, scp has been retooled to use the SFTP protocol under the hood. This will leave most behavior unchanged and most times there will be no perceived difference. However, some scripts which make use of globbing might need minor adjustment to work properly in the future:

A near-future release of OpenSSH will switch scp(1) from using the legacy scp/rcp protocol to using SFTP by default.

Legacy scp/rcp performs wildcard expansion of remote filenames (e.g. "scp host:* .") through the remote shell. This has the side effect of requiring double quoting of shell meta-characters in file names included on scp(1) command-lines, otherwise they could be interpreted as shell commands on the remote side.

This creates one area of potential incompatibility: scp(1) when using the SFTP protocol no longer requires this finicky and brittle quoting, and attempts to use it may cause transfers to fail. We consider the removal of the need for double-quoting shell characters in file names to be a benefit and do not intend to introduce bug- compatibility for legacy scp/rcp in scp(1) when using the SFTP protocol.

Another area of potential incompatibility relates to the use of remote paths relative to other user's home directories, for example - "scp host:~user/file /tmp". The SFTP protocol has no native way to expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later support a protocol extension "expand-path@openssh.com" to support this.

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Interesting) by Anonymous Coward on Thursday May 01 2014, @12:39PM

    by Anonymous Coward on Thursday May 01 2014, @12:39PM (#38461)

    I didn't even realize OpenSSH depended on libssl until heartbleed. I have been avoiding SSL where possible(eg using SFTP instead of FTPS) for years and it is scary to think that this whole time I have been exposed to that pile of shit. At least from now on it is going to be LibreSSL.

    • (Score: 1) by RandomSchmoe on Thursday May 01 2014, @01:26PM

      by RandomSchmoe (4058) on Thursday May 01 2014, @01:26PM (#38472) Homepage

      All LibreSSL has done so far is remove a bunch of cruft. While that's an improvement we don't yet know how much better they'll make the library long term.

      • (Score: 3, Informative) by jdccdevel on Thursday May 01 2014, @03:06PM

        by jdccdevel (1329) on Thursday May 01 2014, @03:06PM (#38520) Journal

        Have you been following The openssl valhalla rampage [opensslrampage.org] blog?

        To say that all they've done is "remove a bunch of cruft" is a absolute disservice to the incredible number of bugs they're fixing.

        You would be astonished at the bugs they've fixed. Buffer overruns, Integer over/underflow, double free issues and many more. Each of which is a potential security issue waiting to happen.

        They're also prepping for a real code audit.

        You are right that it's early days yet. That said, you should see the mess they're cleaning up! After taking a look, I can understand their outrage at the abysmally poor code quality, and their motivation to get it fixed.

        I know enough C to follow what they're doing, and you don't have to follow the blog for very long to tell these are real, security conscious professionals. We also know from their track record (i.e. OpenBSD) these are people who deliver on what they promise. How long that will take remains to be seen, but they're making good progress.

        Some people are comparing this fork to the openoffice/libreoffice split. I don't think that's the best analogy. This is more like the XOrg fork from XFree86. When was the last time you saw a XFree86 install?

        Two years (my estimate) from now, once this effort is mature, I don't think any distro worth it's name will ship openssl by default. It'll all be libressl. The day can't come soon enough.

        • (Score: 2) by frojack on Friday May 02 2014, @12:18AM

          by frojack (1554) on Friday May 02 2014, @12:18AM (#38695) Journal

          I agree, it will be good to have the grown-ups in charge, and I'm betting every distribution switches to the new stack.

          Crap code can come from a lot of different places, but it almost always hangs around due to being maintained too long by the people who wrote it originally.

          Stuff that couldn't fail, gets maintained to death, and all of a sudden moving data from one 2k buffer to another 2k buffer ends up being rewritten as a string operation where one or both arguments are not size checked. Shit like that happens all the time, and unless someone else looks at it, the patch goes in and sits there like a time bomb.

          --
          No, you are mistaken. I've always had this sig.
    • (Score: 1) by Anthony J. Bentley on Thursday May 01 2014, @05:35PM

      by Anthony J. Bentley (2757) on Thursday May 01 2014, @05:35PM (#38566)

      OpenSSL is composed of two libraries, libssl (which implements various versions of SSL and TLS) and libcrypto (which implements various crypto primitives). Libcrypto is generally considered to be somewhat more sane than libssl; it is certainly smaller and less complex. Heartbleed only affected programs using libssl. OpenSSH uses libcrypto, but that is now optional (but likely to remain the default) due to its new elliptic curve support.

    • (Score: 2) by frojack on Thursday May 01 2014, @08:43PM

      by frojack (1554) on Thursday May 01 2014, @08:43PM (#38641) Journal

      I have been avoiding SSL where possible(eg using SFTP instead of FTPS) for years and it is scary to think that this whole time I have been exposed to that pile of shit.

      The TFA is somewhat misleading and hypish. (Intentionally, I suspect).

      OpenSSL via libssl were virtually NEVER actually used in mainstream SSH, and you were NOT at risk this whole time.

      The feature to use libssl was for third party authentication mechanisms typically found in managing remote/virtual machines via a web browser interface [fedoraproject.org].

      It never was mainstream use, and I will bet you a dollar you never ever used it.

      --
      No, you are mistaken. I've always had this sig.
  • (Score: 2) by Foobar Bazbot on Thursday May 01 2014, @12:41PM

    by Foobar Bazbot (37) on Thursday May 01 2014, @12:41PM (#38463) Journal

    I wonder how this will compare to dropbear for mobile/embedded use. Probably bigger binary than dropbear, but with more features (e.g. SOCKS forwarding), and still lighter than the "normal" openssl+openssh option; sounds like a nice compromise.

  • (Score: -1, Offtopic) by Anonymous Coward on Thursday May 01 2014, @01:34PM

    by Anonymous Coward on Thursday May 01 2014, @01:34PM (#38474)

    Well we're movin on up,
    To the east side.
    To a deluxe apartment in the sky.
    Movin on up,
    To the east side.
    We finally got a piece of the pie.

    Fish don't fry in the kitchen;
    Beans don't burn on the grill.
    Took a whole lotta tryin',
    Just to get up that hill.
    Now we're up in the big leagues,
    Gettin' our turn at bat.
    As long as we live, it's you and me baby,
    There ain't nothin wrong with that.

    Well we're movin on up,
    To the east side.
    To a deluxe apartment in the sky.
    Movin on up,
    To the east side.
    We finally got a piece of the pie.

  • (Score: 2) by mmcmonster on Thursday May 01 2014, @01:37PM

    by mmcmonster (401) on Thursday May 01 2014, @01:37PM (#38475)

    I'm not sure I like this. Why should OpenSSH roll their own version of these crypto routines. Crypto is both hard and important, and the idea of having it be taken care of by a common library is so that the library can be audited and any bugs squashed to everyone's benefit.

    Admitted the practice left something to be desired, but with the advent of Heartbleed and the Snowden issues, crypto security is at least on the radars of the major distributions.

    • (Score: 2, Interesting) by Anonymous Coward on Thursday May 01 2014, @02:02PM

      by Anonymous Coward on Thursday May 01 2014, @02:02PM (#38484)

      The era of "crypto is hard, don't write crypto, always use a library" needs to stop. Crypto math is hard, crypto-systems (identifying the right primitives to use to establish a secure protocol) are hard, and protection against side-channel attacks is hard. Let the experts develop those and come up with best practices, fine.

      But crypto primitives are easy: there are known test vectors, if your code produces the right output for the inputs then it is correct. There is nothing magic about it, the code for most functions (hash, encrypt, decrypt, sign, PRNG) is a few hundred lines each. We should not be scared to write that code, because only by a bunch of us trying do we evolve good practical APIs to swap out those libraries, both for primitives and full crypto-systems.

      For crypto-over-the-wire, we need to move to a model of multiple different crypto-system libraries running the same network bytes and requiring agreement before transmitting anything to the other side. For that we should have native-language crypto (not just bindings to (open|libre)ssl/libgcrypt/libcrypto++) for every language with socket support in its standard library (e.g. Java, C#, C (on POSIX/Win32), D, ...) and an inter-process API so that the SSL/TLS/etc stuff doesn't happen in the same address space as the actual user data. Basically apply the mentality of SIL-rated systems to network crypto.

    • (Score: 1) by cnst on Thursday May 01 2014, @02:04PM

      by cnst (4275) on Thursday May 01 2014, @02:04PM (#38485)

      But OpenSSH is not inventing their own crypto routines -- they're using those invented by DJB a couple of years back (and which have now been part of OpenSSH for a couple of months and two releases so far), instead of having to rely on the spaghetti that is OpenSSL.

      • (Score: 0) by Anonymous Coward on Friday September 12 2014, @04:22PM

        by Anonymous Coward on Friday September 12 2014, @04:22PM (#92464)

        95qcry cdzwvjvtxjbv [cdzwvjvtxjbv.com], [url=http://icrmeffnochz.com/]icrmeffnochz[/url], [link=http://fgmkpvgabhqj.com/]fgmkpvgabhqj[/link], http://piclrlcxvkpx.com/ [piclrlcxvkpx.com]

  • (Score: 2, Informative) by cnst on Thursday May 01 2014, @02:00PM

    by cnst (4275) on Thursday May 01 2014, @02:00PM (#38482)

    > [Editor's Note: This appears to be very much a Work-in-Progress, so might not be available for your distro or via standard repositories.]

    Yes, it hasn't been tagged and shipped yet. Expect it to be part of OpenSSH 6.7 (e.g. the next release); these algorithms are already part of OpenSSH 6.5 and 6.6, so you can already start using them today.

    • (Score: 1) by jasassin on Thursday May 01 2014, @11:09PM

      by jasassin (3566) <jasassin@gmail.com> on Thursday May 01 2014, @11:09PM (#38680) Homepage Journal

      [Editor's Note: This appears to be very much a Work-in-Progress, so might not be available for your distro or via standard repositories.]

      Yes, it hasn't been tagged and shipped yet. Expect it to be part of OpenSSH 6.7 (e.g. the next release); these algorithms are already part of OpenSSH 6.5 and 6.6, so you can already start using them today.

      Don't worry. Theo de Raadt will remove a few million lines of code and sort it all out!

      --
      jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A