Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH gets protection against side-channel attacks

undeadly.org

Post reply on HN
Print view View original

51–60 of 166 posts

Re: SSH gets protection against side-channel attacks

#51

Post by [deleted] »

FDSGSG wrote: post #43
castis wrote: post #37

Earlier quoted context omitted.

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

[deleted]

Re: SSH gets protection against side-channel attacks

#52

Post by mehrdadn »

bigato wrote: post #42
mehrdadn wrote: post #38

Earlier quoted context omitted.

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…

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

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

Re: SSH gets protection against side-channel attacks

#53

Post by archgoon »

dangerface wrote: post #39
yjftsjthsd-h wrote: post #5

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.

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

Re: SSH gets protection against side-channel attacks

#54

Post by java-man »

Koffiepoeder wrote: post #10

RAM encryption for sensitive data is overlooked in so many applications, even "highly secure" applications like veracrypt [0] only recently started adding it. In my opinion server-applications of all sorts should encrypt their private keys by default; this makes cold-boot attacks and other memory-escape attacks so much harder, since now two totally unrelated memory chunks have to be combined in order to retrieve the…

RAM encryption is a feature in my password manager (java):

https://github.com/andy-goryachev/PasswordSafe/blob/master/s...

Curiously, RAM encryption, and its relative - clearing secrets from memory when not in use - cannot be added to the Bouncycastle library because they use java BigInteger (unless reflection is used of course).

Re: SSH gets protection against side-channel attacks

#55

Post by simias »

tremon wrote: post #26
castis wrote: post #24

Earlier quoted context omitted.

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

Re: SSH gets protection against side-channel attacks

#56

Post by thijsvandien »

reza_n wrote: post #15
Koffiepoeder wrote: post #10

RAM encryption for sensitive data is overlooked in so many applications, even "highly secure" applications like veracrypt [0] only recently started adding it. In my opinion server-applications of all sorts should encrypt their private keys by default; this makes cold-boot attacks and other memory-escape attacks so much harder, since now two totally unrelated memory chunks have to be combined in order to retrieve the…

Yup, we added this feature to Varnish Cache a few years ago, random key encryption. It generates a random key at startup and encrypts all memory with it. Since this kind of memory is only resident for the lifetime of the process, it works. We stored the random key in the Linux kernel using the crypto API [0] just because its not safe storing any kind of keys in a memory space used for caching (Cloudbleed [1]). We the…

Could this be implemented at the OS level, i.e. whenever a proces launches, the OS generates a key that it will keep to itself and use to transparently encrypt all memory allocated by that process?

Re: SSH gets protection against side-channel attacks

#57

Post by mtgx »

baq wrote: post #2

> Hopefully we can remove this in a few years time when computer architecture has become less unsafe. I think the author misspelled 'decades' here :)

I believe all consumer AMD Ryzen CPUs support Secure Encrypted Memory (SEM), but for some reason it's not enabled by default on most Ryzen devices/motherboards. It's a shame.

I'd also love to see AMD bring an updated and patched version of Secure Encrypted Virtualization (there have been some attacks against it, although still fewer than against Intel's SGX) to consumer Ryzen in the near future. With so many cores available in consumer AMD CPUs (up to 16 now), people will start to use VMs more. Even Windows 10 has the easy-to-use Windows Sandbox now, as well as the App Guard sandbox for Edge.

Not to mention they could use this as yet another "killer app" of their many-core CPUs, because otherwise people will eventually start to wonder why even get CPUs with so many cores over CPUs with fewer cores but higher singlethread performance. No different than say Verizon promoting high-quality 4k streaming on its new 5G network.

I would've already preferred to see this in Zen 2, but at least Zen 3, which will otherwise bring few performance improvements and remain on the 7nm node, should come with these as some sort of "security-focused generation of Zen".

Re: SSH gets protection against side-channel attacks

#58

Post by mehrdadn »

bigato wrote: post #44
mehrdadn wrote: post #41

Earlier quoted context omitted.

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.

Re: SSH gets protection against side-channel attacks

#59

Post by notacoward »

ryanlol wrote: post #11
yjftsjthsd-h wrote: post #5

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.

If you need high performance why are you using OpenSSH?

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.

Re: SSH gets protection against side-channel attacks

#60

Post by archgoon »

FDSGSG wrote: post #43
castis wrote: post #37

Earlier quoted context omitted.

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

Post reply on HN