Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Encryption Security

OpenSSH No Longer Has To Depend On OpenSSL 144

ConstantineM writes: "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. `make OPENSSL=no` has now been introduced for a reduced configuration OpenSSH to be built without OpenSSL, which 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."
This discussion has been archived. No new comments can be posted.

OpenSSH No Longer Has To Depend On OpenSSL

Comments Filter:
  • Nooooooooo (Score:5, Funny)

    by sholdowa ( 242332 ) on Wednesday April 30, 2014 @02:29PM (#46882925) Homepage

    Sorry, I'll take OpenSSL over any DJBness any time!

    • Re:Nooooooooo (Score:5, Insightful)

      by lgw ( 121541 ) on Wednesday April 30, 2014 @03:11PM (#46883409) Journal

      DJB is the worst kind of asshole too: he's almost always right. So you shouldn't just ignore him. Meh, justified arrogance still annoys.

      Now, what we really need is a cage match between DJB and Theo de Raanter. I'd buy that on PPV!

      • Now, what we really need is a cage match between DJB and Theo de Raanter. I'd buy that on PPV!

        Might be kinda boring, actually - they're both usually harsh on people who are wrong. So, in this case...

        You'd have to get DJB talking about large systems integrations (awesome, qmail is a secure system that doesn't meet real world needs without patches of unknown quality) and Theo talking about people's motivations (especially 'linux people').

      • by raymorris ( 2726007 ) on Wednesday April 30, 2014 @04:46PM (#46884379) Journal

        Sometimes, DJB is right, I'll give him that. More frequently, I think, he simply doesn't like following any standards, customs, or conventions. In the US, he'd come up with an argument of why driving on the left side of the road is better. If the same discussion occurred in the UK, he'd come up with an equally good argument why people should drive on the right side of the road - whatever position is contrarian, he'll take it. That's fine, it helps avoid groupthink and the like. The problem is, he doesn't just argue it - he then goes right on ahead and actually drives on the wrong side of the road. Left or right probably doesn't matter, but going head-on against all of the traffic is obviously a very bad idea, and that's what he does.

        A well known example is of course the filesystem. The Linux Standards Base discussions covered a few options that each had minor benefits and drawbacks. It didn't really matter what LSB decided - the config files can be in /etc/ , in /config/, or in /why/cares/ - it doesn't matter as long as you know where they are so you can back them up, adjust them for a new instance of an image, etc. What matters most isn't where they are, but that they are in some standard location. DJB screws all that up. I suspect that half the time, the perverse pleasure of screwing up standards is actually his primary motivation for his decisions.

        • by Anonymous Coward

          he'd come up with an argument of why driving on the left side of the road is better.

          That's because it is :oD

          • that depends entirely on your geography. If, for instance, you try that in, say, Los Angeles... you're going to die horribly. Try it in a rural country road in England, and you'll be just fine.

            • by neurovish ( 315867 ) on Thursday May 01, 2014 @09:39AM (#46888855)

              Driving around "country roads" in Scotland, I was left with the impression that they don't really have "sides". You just go along down the middle until you come across an oncoming car, then rock/paper/scissors to decide who is going to back-up to a spot wide enough for two cars to pass or just pull into the sheep field. These "country roads" also seemed to be the most direct route from one place to another.

        • by hangareighteen ( 31788 ) on Wednesday April 30, 2014 @08:03PM (#46885839) Homepage
          His goal seems to be to make rock solid software with well-considered security of design and operation, and that's about his only goal. Compliance with the LSB is nice and all, but it's not something that keeps me up at night. Hell, it's not even in the top ten; and while DJB's software can be a little rough around the edges, I'm more than happy to use it because I have a high level of confidence in the design and implementation of his ideas.
      • by mcrbids ( 148650 )

        I would argue, it's not that he's *right*, it's that he's right in a way that still doesn't help.

        Wife: "Honey, do you know where my keys are?"

        Husband: "Pretty sure they're right where you left them!".

        Technically correct, completely unhelpful.

        And that's how QMail is. (or was, I stopped using it years ago) Qmail is a nightmare I'd rather forget. Sure, it is/was very secure, modularly written with strong privilege separation, built-in clustering support, etc. But because of the horribly restrictive license it

      • _almost_

        His approach to mail was downright abusive.

        Opening dozens of parallel connections to a target if there are multiple recipients instead of using multiple RCPT TO:, and SMTP streaming for multiple messages amounted to a Denial of service attack on larger mailservers.

        In postal terms the postman is carrying a 165mm breaching cannon and is intoning "the mail MUST get through" as he blasts new holes in your structure to take the shortest possible path.

    • Queue the 'q'mail haters but djb stuff worked.
      • by gmack ( 197796 )

        It "worked" only as long as you don't care about the problems DJB had no interest in solving. It is true that you can't use Qmail to break into the host system, but unfortunately you can use it as a reflector and annoy the crap out of pretty much everyone else.

        I was a Qmail fan and installed it everywhere I worked right up until the day several of my servers got blacklisted.

        • Really, I've run it for at least the last 15 years and have not once been blacklisted. I follow the words of a great American, Ronald RayGun: Trust but verify.

        • by Anonymous Coward

          If you set it up as an open relay, then you did it wrong. If you didn't disable the bounce mail, then you did it wrong. The problem here wasn't qmail, it was the guy that set it up. PEBCAK.

          • by gmack ( 197796 )

            Your suggested fix to disable bounce messages with the side affect that the sender then has no way to know that the mail never arrived? Not going to happen. If I ever did something that stupid, my clients would drop me.

            In the meantime I've switched to Postfix which manages to do things correctly by refusing the message in the initial connection if the user doesn't exist so the sending mail server gets to generate the bounce message instead. And yes I know there are now patches and Qmail forks that cause

    • I won't miss OpenSSL and that tiny ragtag team of developers, the OpenSSL Eight, as impressive as their work is for such a tiny crew. And I'm only responding because I don't see anyone complaing about ssh, and it is dear to my heart, too, but maybe its time for a change [wikipedia.org] ... becuase now there is mosh [mit.edu]..
  • by mlts ( 1038732 ) on Wednesday April 30, 2014 @02:32PM (#46882963)

    Now, here is the secondary question: How well vetted/audited will the replacement libraries end up? Disconnecting OpenSSH from OpenSSL does help isolate things, but it also means that there is twice the cryptographic code to sift through in order to ensure security.

    I trust the OpenBSD developers and Theo, so IMHO, this is a net security gain.

    Maybe for the lost ciphers, it might be good to implement LibreSSL?

  • by sinij ( 911942 ) on Wednesday April 30, 2014 @02:32PM (#46882965)

    Get this version of OpenSSH FIPS certified and it will be default industry standard for the next decade.

    • by Anonymous Coward

      I have a feeling the openbsd team do not particularly care for FIPS certification at this point in time. O:-)

    • What's the industry standard of this decade?

      • by mwvdlee ( 775178 )

        We still have six more years to go, so I think either the next standard or the third one after that.

        • by Noryungi ( 70322 )

          Or, as the fortune used to read: The good thing with standards is that there are so many of them to choose from...

    • no, FIPS does not meet the approval of those who deal in securing communications, it has dubious/poor security protocols included. that's why the OpenBSD team threw it out of LibreSSL. Past time to get rid of symbolism over substance in the realm of security.

    • by Anonymous Coward

      You can't certify source code. You can only certify binaries. That makes FIPS certification a challenge for most users and implementers.

    • 25519, chacha20 and poly1305 are not FIPSable algorithms.

      • by Noryungi ( 70322 )

        Hmm. Interesting. Could you please back this assertion with references?

        I am not trolling in any way - just trying to figure out why these algorithms are not certifiable.

        • by TechyImmigrant ( 175943 ) on Wednesday April 30, 2014 @04:25PM (#46884211) Homepage Journal

          FIPS 140-2 [nist.gov] is a spec about boundaries. You draw a boundary and the spec talk about how data passed through the boundary and about the stuff that allowed inside the boundary.

          One the primary things is asks is that the crypto algorithms are NIST approved. E.G. AES or SP800-90 or SHA1/2/3.

          So to build a FIPS140-2 compliant thing, you first determine the box (the boundary) and the function. Then implement that function using crypto algorithms from the list of NIST approved algorithms.

          Curve 25519, chacha20 and poly1305 do not appear in any NIST published specification.

          • by Noryungi ( 70322 )

            OK, thank you for that information.

  • by Anonymous Coward

    So, OpenSSH has now a compiler option to disable OpenSSL. OpenSSL had a compiler option to disable heartbleed. Did it help?

    • Yes it did. You were not vulnerable if you have built OpenSSL with the feature disabled.

      • Re:Compiler option (Score:5, Interesting)

        by adisakp ( 705706 ) on Wednesday April 30, 2014 @03:13PM (#46883425) Journal

        Yes it did. You were not vulnerable if you have built OpenSSL with the feature disabled.

        Except that OpenSSL actually didn't run with the "feature disabled" (internal freelist-based memory allocator) due to uninitialized memory bugs in OpenSSL that required newly allocated blocks of certain types to have memory set in them from previously freed blocks. See details here [tedunangst.com].

        • I'm not sure I understand. Surely the feature must have been disabled if it was not built as part of the binary?

        • You're referring to the exploit-mitigation-mitigation in OpenSSL, which indeed couldn't be disabled, as per tedu@openbsd, but OPENSSL_NO_HEARTBEATS was a separate option that noone has volunteered to claim of not working.

          OPENSSL_NO_HEARTBEATS has since been made the default and only option in LibreSSL, and the heartbeats were removed.

          • In reality, the heartbeats had no place in OpenSSL; if you want a heartbeat, you can implement it on the next layer up the stack, and this should be enough to hold the connection open. In the few instances where a heartbeat has helped me, there was a better way to handle the situation (as it was usually required due to bad router configuration in the first place). Implementing transport connection quality monitoring code inside a transport encryption library just leads to stuff like heartbleed. LibreSSL

          • OPENSSL_NO_HEARTBEATS has since been made the default and only option in LibreSSL, and the heartbeats were removed.

            Too bad, heartbeats are quite useful in DTLS context. Yanking useful features just because someone screwed up in implementation space is not a rational response.

          • by adisakp ( 705706 )

            You're referring to the exploit-mitigation-mitigation in OpenSSL, which indeed couldn't be disabled, as per tedu@openbsd, but OPENSSL_NO_HEARTBEATS was a separate option that noone has volunteered to claim of not working.

            OPENSSL_NO_HEARTBEATS has since been made the default and only option in LibreSSL, and the heartbeats were removed.

            But even with OPENSSL_NO_HEARTBEATS, if you are using a faulty allocator that lets you read data that has already been freed, you will still may be able to come up with other exploits (which are highly likely to exist in complicated software) that will let you read that data that you thought was "gone".

  • by TechyImmigrant ( 175943 ) on Wednesday April 30, 2014 @02:34PM (#46882983) Homepage Journal

    Can we have it with Normal RSA for key agreement/key exchange?

    Elliptic Curves are a minefield you need a degree in math to navigate. I prefer my crypto to be tractable.

    • by brynet ( 3462983 )
      Support for RSA and (non-EC)DSA key types might be added eventually; even sooner if you sent patches.
      • I'd sooner fix the symmetric crypto. That's more my area of expertise. But the point is well taken.

        However one good algorithm is better than 3 choices in security critical applications like this.
        All that ciphersuite negotiation, build configuration and other stuff is just attack surface.
        So I don't know it would help to add RSA. It would help to pick RSA as the only asymmetric algorithm.

    • by Anonymous Coward

      Elliptic Curves are a minefield you need a degree in math to navigate. I prefer my crypto to be tractable.

      Elliptic curve cryptography (ECC) is great. It uses small keys (32 bits) and is computationally inexpensive to implement. What's not to like? It's not a minefield, it's a field of integers [wikipedia.org].

      p=2^255-19 is a prime number: 57,896,044,618,658,097,711,785,492,504,343,953,926,634,992,332,820,282,019,728,792,003,956,564,819,949. A nice big one, and that's why the crypto is secure. If I take all the integers 1,2,,p, it's a finite set. I can define a mathematical operation that, for any pair of these integers, give

      • The NSA has been heavily promoting ECC. [ietf.org]

        >So start using ECC and give the NSA the finger

        I don't want to give the NSA the finger, or rather that's not my primary job. I do want to develop secure products regardless of the NSA, that make it into that hands of many people, who then enjoy secure computing without having to get involved in the fight. The NSA is a great help in some ways and an undermining force in other ways. As professionals we have to deal with that reality. Delivering secure solutions in mas

      • The NSA actually recommends ECC exclusively for public key encryption as part of its suite B, and not RSA. Make of that what you will.
      • by blueg3 ( 192743 )

        So start using ECC and give the NSA the finger.

        If you want to be superstitious about ECC, suit yourself. I have no doubt that the NSA would like to discourage the use of ECC and curve 25519 in particular.

        Actually, they promote elliptic-curve cryptography. All of the Suite B asymmetric ciphers have moved from factoring problems to elliptic-curve ones.

        Now, that leaves people in a sticky situation. See, they have some reason to distrust ciphers promoted by NSA. But NSA used to promote using DH/RSA.

        Mathematicians in the public space have been making interesting progress in solving the factoring problem. Quantum computers, which can probably solve factoring problems efficiently, have started to appear in very li

  • by cheesybagel ( 670288 ) on Wednesday April 30, 2014 @02:42PM (#46883073)

    Just create a crypto library and make OpenSSH and LibreSSL depend on that instead of duplicating hard to debug code everywhere.

    • by mlts ( 1038732 )

      There is always RSAREF 2.0, which has not had anyone find any major holes in it since 1994. However, it only supports RSA, and not newer algorithms like AES.

    • If you pick only one variant of one algorithm for each of the algorithms types, the code is very small and simple and doesn't need to be in a library, that typically needs to support many configurations for many consumers.

      If you have a crypto application, write your algorithm one way, once with no configuration or runtime variation. It will serve you well.

  • Small is better!
  • The parts of libopenssl that OpenSSH depends on are the least likely to be problematic anyway. All it really uses are the cipher implementations. Actually, the fact that the dependency surface is so small is exactly which it could be easily replaced.
    • Grr.. s/exactly which/exactly why/

      If only there were some way to, you know, see your post before you post it. Like a "preview" button or something.

  • AES-CTR (Score:5, Interesting)

    by TechyImmigrant ( 175943 ) on Wednesday April 30, 2014 @03:22PM (#46883507) Homepage Journal

    I don't like AES-CTR as a privacy mode for online communications and I don't like this [bxr.su]

    aesctr_keysetup(aesctr_ctx *x,const u8 *k,u32 kbits,u32 ivbits)
            x->rounds = rijndaelKeySetupEnc(x->ek, k, kbits);

    The AES key schedule can be computed inline with the round function, both for encrypt and decrypt.
    Computing the key schedule inline means that the state isn't left laying around in memory.
    Also, the majority of side channel attacks against key schedule rely on repeated behaviors. A simple principle that is a good mitigation is to never use the same key twice.
    Pre-computing the key schedule is only an optimization when you are using the same key repeatedly.
    So AES-CTR encourages both sins. Using the same key multiple times and then optimizing by keeping the key schedule state laying around.

    The CTR mode is just a non-ideal PRF to generate bits that are XORed with the data. On each block the key is the same but the IV changes.
    The PRF is non ideal because no block will match (since AES or any other block cipher, with a fixed key is a bijective mapping) whereas in true random data, blocks may match with the usual statistical probability.

    So if we picked a better block cipher based PRF, like say the SP800-90 AES-CTR-DRBG, both key and IV change on each step, so the output looks more like a real PRF and the key isn't used twice and so there's no incentive to optimize with a pre computed key schedule.

    The inline computation is nice and simple [deadhat.com] and constant time. This is a particularly inefficient implementation, you can do better:
    void next_key(unsigned char *key, int round)
            unsigned char rcon;
            unsigned char sbox_key[4];
            unsigned char rcon_table[12] =
                    0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80,
                    0x1b, 0x36, 0x36, 0x36

            sbox_key[0] = sbox(key[13]);
            sbox_key[1] = sbox(key[14]);
            sbox_key[2] = sbox(key[15]);
            sbox_key[3] = sbox(key[12]);

            rcon = rcon_table[round];

            xor_32(&key[0], sbox_key, &key[0]);
            key[0] = key[0] ^ rcon;

            xor_32(&key[4], &key[0], &key[4]);
            xor_32(&key[8], &key[4], &key[8]);
            xor_32(&key[12], &key[8], &key[12]);

    • Hi,

      thank you, that's a similar bad feeling I carried arround with me everytime hearing AES-CTR.

      The further interesting analysis on AES-CTR encrypted traffic would be if when the data is not appearing to be "random" enough,
      if you could recognize patterns inside the data and then resolve back to the encrypted data.

      Like the famous ECB encrypted pengiun could still be recognized attacks. [1]

      It would even introduce a lower level of
      a.) you transer your passwords file over openssh
      b.) I recognize the pattern of tha

    • Why go through all that trouble when a PRP is indistinguishable from a PRF except with negligible probability... If you find two inputs that map to the same block with a PRF that is equivalent to just guessing the encryption key.
      • Because when you invoke AES with the same key many times, you leave yourself more vulnerable to side channel and fault injection attacks.

    • by dmiller ( 581 )
      AES-CTR being based on a permutation rather than a true PRF might matter if SSH used all the counter values, but SSH rekeys every 2^32 blocks at most - a tiny fraction of the 2^128 possible counters.
      • Yes. It's not the algorithm that's a problem. It's its vulnerability to sidechannel analysis, putting the key schedule through the same sequence each time.

  • Where is the arcfour cypher? You can't not include the fastest cypher there is for bulk data transfer.

    for i in aes128-cbc 3des-cbc blowfish-cbc cast128-cbc arcfour128 arcfour256 arcfour aes192-cbc aes256-cbc aes128-ctr; do echo $i; dd if=/dev/zero count=1000000 2> /dev/null | ssh -Cc $i "dd of=/dev/null"; done

  • Patrons? (Score:5, Informative)

    by jones_supa ( 887896 ) on Thursday May 01, 2014 @02:20AM (#46887213)

    The front page of openssh.org is a grimy reading:

    This list specifically includes companies like NetApp, NETFLIX, EMC, Juniper, Cisco, Apple, Red Hat, and Novell; but probably includes almost all router, switch or unix-like operating system vendors. In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).

    So there we go again. Even a critical piece of software like this, cannot get proper funding from the giants, who are happy to take the software for free.

    It just sucks, man.

  • Does anyone knows if this vulnerability impacts OpenSSL implementation in OpenSSH ? http://pastebin.com/gjkivAf3 [pastebin.com]

As far as we know, our computer has never had an undetected error. -- Weisert