Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

Unfortunate that there's no commentary on performance impact. It's symmetric encryption on a few kB, so probably fast, but I'd like to have numbers.

View on HN

If I understand correctly it's effectively a one-time constant cost when setting up an encrypted connection, so it should be negligible unless you have a use case for setting up many extremely short-lived connections.

SSH has multiplexing [1] specifically to speed up multiple connections... would be interesting to know whether it incurs the overheads once vs. on every connection.

[1] https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

Just keep in mind that multiplexing makes phishing risks significantly higher. ssh wont log multiplexed auth and phished connections are auth free, up to 9 more sessions by default.

> Unfortunate that there's no commentary on performance impact. It's symmetric encryption on a few kB, so probably fast, but I'd like to have numbers.

TFA comments on the performance impact. It's only about the handshake, i.e. irrelevant.

Saying it's about the handshake is not a comment on performance impact, and doesn't need a patronizing "TFA". Especially when the article just talks about 'signatures', in a way that doesn't make it obvious exactly when this key is being used.

This code is probably not adding more than a millisecond, but it's not at all true that handshake speed is irrelevant. If you rewrote the RSA code in a slow secure way, going from 100ms to 5s on a slow chip, that would have very real effects.

If you need high performance why are you using OpenSSH?

The point is that we'd like to know that its not heavily degrading to the existing purpose. No one said anything about high performance.

What part of the existing purpose is performance-critical?

I dont understand the purpose of this question. The existing purpose is that it works at all?

I’m really not convinced that this is a realistic concern.

And anyway, what you’re posing certainly isn’t a performance concern, but a “does the software work” concern.

"I’m really not convinced". Ok great thanks, neither is anyone else, which is why we'd like numbers.

Why do you think that this specific change would make ssh not "work at all" as opposed to the hundreds of other changes that happen? Do you even pay close attention to those changes? I for sure don't.

Why are you concerned about this in the first place? Obviously there's always a general concern about any changes, but what makes this specific change a big deal to you?

This particular change got a hacker news article. It seems to be inherently more noticeable than others.

Seems reasonable to ask about the performance (and memory) implications of the change. If they're minimal, than this solution can be easily added to other situations where encryption is being used. If it's heavy, then different solutions would need to be developed on a case by case basis.

edit: your annoyance is not worth anyones time

>reading way too far into it

Dunno, your earlier comments seem to imply otherwise:

>we'd like to know that its not heavily degrading to the existing purpose... which is why we'd like numbers

Tanking DDoS? Like, the more connections you can handle normally, the less filtering you need to do on incoming connections?

OpenSSHd does not “tank DDoS”, it’ll simply consume all resources available to it if attacked.

The only way to mitigate such an attack would be to drop it before it reaches the SSH daemon.

I certainly wouldn't want scp to suddenly slow down compared to what I'm used to. I use scp and sftp rather heavily to transfer very large files and do backups, that might not be performance-critical but it's definitely performance-sensitive.

I haven't had to mess with that in a while but there was a time where you'd get a significant boost with scp on underpowered hosts if you used the arcfour cipher for instance (I believe that it's now fully deprecated, and for good reasons).

If you were willing to sacrifice best practices for performance, one obvious option is to accept only hmac-md5, which is very fast and still somewhat secure.

If the systems involved lack "AES-NI" native CPU opcodes, then you might revert to chacha20-poly1305, which is supposedly faster on CPUs that lack acceleration. This also overrides the hmac-md5 above, as it is an AEAD.

If you needed to go faster still, then you could instead choose ARCFOUR (RC4) as you say, but this has been removed from the latest versions of OpenSSH because it is not safe.

The worst of the above configurations are still not as bad as classic FTP.

Using LFTP's mirror sub-system plus SFTP can be faster than all of the unencrypted protocols. It gives you the behavior of rsync, but can work with sftp+chroot logins and can spawn multiple threads per job or even per file. Working demo [1]

I find it very useful when I want to give people the ability to transfer files quickly, but I don't want to give them a shell.

[1] - https://tinyvpn.org/sftp/#lftp

Ssh isn't just for interactive terminal sessions. It's not that uncommon for people to use ssh tunnels in situations where proper VPNs etc. are blocked. Others use sftp or tunnels plus a SOCKS proxy in one specific application. In those applications, performance regressions are a legitimate concern precisely because it's not expected to be all that great to begin with.

If you’re concerned about performance then sftp or SSH tunnels simply aren’t the right tools for you.

If the "better" tools are unavailable, then it's the right tool. Your needs and priorities are not the only ones that exist anywhere in the universe.

I really don’t see a problem here. If you have some weird edge case that requires a less secure version of OpenSSHd then you should either stick with the old version or fork the new version.

Far more important than that what I want to know is whether I should even care, e.g. is there any evidence of Spectre being used in the wild or not.

A vulnerability that has been shown to work should not be patched in the software more widely used around the world to connect all kinds of linux/unix servers and even other systems? They should wait for it to start getting exploited "in the wild"? I'm just glad that the security of my systems does not depend on people with this kind of attitude.

Where did I say it shouldn't be patched? I just said this is information I think a user would care to know along with the patch.

You said you shouldn't care if it was not found in the wild, this is just wrong

You don't even know my requirements or how I use my computers. How do are you so confident it's "just wrong"?

If you want to know wheter it was found "in the wild" and think that this is a relevant factor in deciding if you should care, that is information enough about your usage to be confident it is wrong.

It's most definitely not, but I don't get the impression you're open to seeing things as nonbinary.

Ah yes, I too love the panicked rush of trying to force application vendors to patch once we we discover something is being exploited in the wild.

Remember defense is depth is a valid strategy.

What I was trying to say was I think library users care to know how urgent it is. If this is being used in the wild then application vendors might need to provide out-of-band patches somehow, and end users should rush to get those patches. If OTOH this is known to be extremely hard to pull off and not known to be used, then it'd be nice for users to know that just the same. Nowhere was I trying to suggest they should avoid providing the patch altogether or something.

That's not how security works. If it can potentially lead to a software like openssh leaking secrets, it is of the highest urgency, period. It doesn't matter if it is thought to be hard to exploit and it doesn't matter if it was already found "in the wild".

Okay, but if 1 of my 3 highest urgency vulnerabilities is known to have been exploited in the wild, and is easy to exploit, then I may want to focus on that one over the other 2.

Alright, I should have said it is "critical" instead

> That's not how security works. If it can potentially lead to a software like openssh leaking secrets, it is of the highest urgency, period. It doesn't matter if it thought to be hard to exploit and it doesn't matter if it was already found "in the wild".

Really? This isn't how security works? Yeah, I guess I forgot security is a 100% binary thing. That's why you never read actual security bulletins advising you when vulnerabilities are actively being exploited in the wild. It's insane to think that should matter or raise the urgency of a patch. [1] [2]

[1] https://www.us-cert.gov/ncas/current-activity/2019/06/18/Moz...

[2] https://www.mozilla.org/en-US/security/advisories/mfsa2019-1...

I agree with the idea that availability of information is good, and that information about the context for a security-related change should be made transparent. But how relevant is it? I would think relevant enough for FAQ or other reference information. I wouldn't include it in announcements, though.

The headline is "patch available, mitigating known exploit". "Not yet widely exploited" is barely a footnote. The release of a patch can bring enough attention to make the window between release and full deployment of the patch the single worst time to be vulnerable. If I tell you it wasn't being exploited yesterday, and you delay patching based on that information, and then the storm of exploits blows through ... I'd feel bad.

> I would think relevant enough for FAQ or other reference information. I wouldn't include it in announcements, though.

Maybe you wouldn't, but US-CERT, Mozilla, etc. do...

https://www.us-cert.gov/ncas/current-activity/2019/06/18/Moz...

https://www.mozilla.org/en-US/security/advisories/mfsa2019-1...

None. There hasn't even been a real world demo where given normal conditions: a running sshd and other programs where a running browser script exfiltrates a key with meltdown.

Spectre probably isn't possible either and that is the easy one. The load store buffer attack seems completely impossible. Even the POC had to essentially write a program specially to be exploited.

The attacks are very interesting and neat, but I think things like this and other techniques effectively remove any last chance.

Don't underestimate what hackers with enough motivation can achieve. Specially when the stakes are so high and the geopolitical power coming from a software vulnerability can be significant.

It's not mentioned because it's irrelevant. There is no security / performance trade off for a secure program. It's secure or its not.

> It's secure or its not.

Then there is no concept of "improves" security. Either it is now secure or it is not. Do they have proof that there are now no side channel attacks that can be made on their software?

EDIT: sigh This comment is not arguing that they need a proof for their change. It is arguing that you can improve security without making something completely secure, which undermines the idea that code is 'either secure or it is not'.

There are a lot of knee-jerking in this thread. I don't think anybody is arguing that this is a bad patch, but if it does have a notable performance impact (which it probably does not) it's still worth knowing. If only to be able to answer questions like "why do our backups suddenly take 10% more time to complete? Do we have a problem with our network infrastructure?"

It's not about tradeoffs, it's about understanding what's going on and anticipating potential problems.

By your logic we shouldn't have to discuss the performance regressions on CPUs who implement spectre/meltdown mitigations because "it's irrelevant". Obviously these patches are necessary but the performance impact is very relevant for many users.

By the parent's logic, there's no concept of improving security, because if there remains attacks, then it is still not secure. You can't take a position of "it's either secure or it isn't."

I don't think that makes sense. For starters, threat model is everything. To grab an obvious example here, speculative execution attacks are only a concern if an attacker can cause execution of code on your physical host. A secure program facing the network will be secure even if it fails to defend against CPU side channels. Further, reducing to a binary de facto means that literally everything is "insecure", the end. (I defy you to show me a piece of software that never has had any vulnerabilities and never will, since of course undiscovered bugs still make the system insecure)

> It's not mentioned because it's irrelevant. There is no security / performance trade off for a secure program. It's secure or its not.

Everything in the world is about trade-offs. Security is no exception. Humans figured this out a long time ago with physical security. Somehow it hasn't sunk in for cybersecurity. I would recommend mentioning this to a well-known security expert if you ever come across one and seeing their reaction.

Degree of security is routinely measured by expense to overcome it.

> It's secure or its not.

Well, it's not. Now that we've debunked performance and security, I guess we can just write everything in PHP.

I think folks are missing your point, which (I think) is something like:

I don't care if that car is faster if it is already on fire.

Reply on news.ycombinator.com