Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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').

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.

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.

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.

Because he's DOCTOR Daniel J. Bernstein, PhD. The PhD means he's the only person with a clue, that he knows much better than everyone else who has ever lived. Therefore, qmail stores its config files in/var.

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

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.

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.

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

I only posted because it is an elegant solution that provides some amazing features... uh... elegantly. But it is new, and the main feature is mitigated somewhat in ssh by screen. More often than not, I do get annoyed by ssh latency, for which mosh has an... uh.. elegant... solution. (sorry, its late...uh... early)

However, even still, the license is absolutely unacceptable for some uses.

I never thought that the GPL would cause a particular use to be counter to the licensing unless it was being used as a component in another application by a developer that necessarily needed to

And you control the software versions on all the clients/servers you will be interoperating with.

AIUI (from a compbination of the summary and my memory) if you enable this option you will end up with a ssh client/server that will have serious interoperability problems due to only supporting crypto options that are very new.

It's a matter of timing. This has been in the pipeline for a while; it got pushed through with immediacy as a political move. Reread the whole statement: this has been a long time coming, but it only happens at a critical political moment. Like Congress sitting on an important bill to provide mental healthcare and treatment for pedophiles for 8 years until there's a high-profile child murder-rape by an individual who obviously caved under the stress of his urge, and then passing it in a powerful show o

is not political when project which has focused on securing communication and servers and have proven track record are ponying up and actually *doing the work*. you're the one making political nonsense.

It's political when you're "going to do it" for years and then, the moment you can lord it over someone you don't like and show off how great you are, you finally pull the trigger and shout out to everyone how great you are.

Politics, like Go, is not about the precise action; it's about the timing of that action.

please provide link to past years when openbsd said "they're going to do it".please provide link to where they said after heartbleed how great they are.

instead, they dived in and did WORK. they have action to back up their words. ou are the one being political, what contribution to communication security have you ever made? you just shoot off metaphorical forum mouth about others actually accomplishing something, while contributing nothing yourself. textbook political-only behavior

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.

There are no replacement libraries. The ED25519, ECDH, ChaCha20 and AES-CTR code is all part of OpenSSH itself. And the code is very, very tight and compact and very easy to audit. Entirely the opposite of OpenSSL!!!

I have a feeling the openbsd team do not particularly care for FIPS certification at this point in time. O:-)http://opensslrampage.org/post/83555615721/the-future-or-lack-thereof-of-libressls-fips-object

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.

While your points are certainly valid, they do little to mitigate the need for FIPS when dealing with things like FBI CJIS data. Either you're in compliance or they disconnect you. It's sort of like arguing with a TSA agent; it'll make you feel a little better but it won't actually change anything.

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

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

Although in the DTLS can be trivially implemented within the app rather than transport layer

The point is to provide useful UDP compatible semantics so **existing** UDP protocols are able to leverage DTLS. In the UDP world concept of an underlying session needing to be maintained prior to transporting bytes is non-existent.

For example syslog over DTLS is one-sided. Without ability to detect aliveness of encrypted session messages would be forever black holed if session died or NAT state expired.

Obviously if built from ground up you can implement anything. Use of keep-alive for MTU probe and enc

In the end this "useful" feature was kicked because it was flawed from the ground up at least for a security focused use and iirc only OpenSSL provided an implementation of that specific protocol so it couldn't have been that useful.

Sentiment seems to reflect a failure to understand the difference between TLS and DTLS. On a relative basis nobody uses DTLS either not sure where this leaves the "useful" argument.

The biggest mistake in my view was deploying this feature at all for TLS as there was nothing to be gained by doing so. DTLS is a completely different matter and even there they could have used a more conservative default without inconveniencing anyone.

Not to forget that this feature could be freely accessed by just about anyone as it lacked authentication

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

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.

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

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

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

Been serving us well for 40+ years, don't see why we should throw that away when - for instance - there still isn't a "break" in modern such encryption to leverage.

EC will be trusted when it's been around for 30+ years AND certified for military usage. PKE took at least 20 to get established in mainstream usage even without any real competition. By comparison, EC looks like a pimply teenager.

Right - 25519 [cr.yp.to] in particular is well-regarded. It may be that everybody in the field[sic] is wrong, but at this point it's considered stronger than RSA, and possibly resistant to quantum attacks which RSA is not.

Looking at risks today, it's more likely that OpenSSL's RSA code has vulnerabilities than curve 25519 has breaks. We are not just looking at algorithms here, but implementations.

If I were on OpenBSD I might feel comfortable using LibreSSL with guard pages, but for my linux-to-linux machines in a gl

25519 is nice and all, but in the minds of people who have to make products, that's mostly because it deftly works around the very FUDy patent issues.The minutiae of the other benefits are not gating for 25519 or any other useful curve.

There is RSA the algorithm and RSA the company. They are related in the sense that the people who came up with the algorithm founded the company but the founders sold off the company over a decade ago.

Whether to trust the RSA algorithm and whether to trust RSA security are not really related issues.

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.

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.

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 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 ofa.) you transer your passwords file over opensshb.) 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.

In AES-CTR you use the same key in each block with a different, incrementing IV. Then XOR the output with the data.

This is algorithmically secure, because you would need more blocks than there are atoms in the universe to break the algorithm.However each time you invoke AES with the same key, the key schedule software or circuit goes through the same sequence, leaving it open to statistical sidechannel analysis or fault injection analysis.

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.