SSH gets protection against side-channel attacks • Hacker News Board

Re: SSH gets protection against side-channel attacks

#21

Post by reza_n » Fri, Jun 21, 2019, 12:37 PM UTC

Koffiepoeder wrote: post #19

reza_n wrote: post #15

Earlier quoted context omitted.

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 you point me to the relevant source code? Am highly interested to take a look at it during the weekend.

Closed source, write up would be here:

https://info.varnish-software.com/blog/introducing-varnish-t...

Re: SSH gets protection against side-channel attacks

#22

Post by swinglock » Fri, Jun 21, 2019, 12:40 PM UTC

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

..or forgot to add "/sarcasm".

Re: SSH gets protection against side-channel attacks

#23

Post by jnordwick » Fri, Jun 21, 2019, 12:40 PM UTC

Couldn't they also move the keys around in memory to every second or keep the bytes of the key separated (this seems like it would be similar to encrypting)?

These side channel attacks even under ideal conditions take a very long time and part of the problem is they basically need to guess at memory addresses. Even when data is in a known location, it is sketchy. Anything that slows down locating data would help immensely.

Re: SSH gets protection against side-channel attacks

#24

Post by castis » Fri, Jun 21, 2019, 12:41 PM UTC

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?

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.

Re: SSH gets protection against side-channel attacks

#25

Post by bigato » Fri, Jun 21, 2019, 12:46 PM UTC

jnordwick wrote: post #18

mehrdadn wrote: post #9

Earlier quoted context omitted.

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.

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…

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.

Re: SSH gets protection against side-channel attacks

#26

Post by tremon » Fri, Jun 21, 2019, 12:51 PM UTC

castis wrote: post #24

ryanlol wrote: post #11

Earlier quoted context omitted.

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?

Re: SSH gets protection against side-channel attacks

#27

Post by knorker » Fri, Jun 21, 2019, 12:51 PM UTC

Does this only protect the SSH host key?

What about the session keys for the sysadmins who have logged in, and maybe keep their session up 24/7?

Re: SSH gets protection against side-channel attacks

#28

Post by hvidgaard » Fri, Jun 21, 2019, 12:56 PM UTC

bigato wrote: post #17

hvidgaard wrote: post #8

Earlier quoted context omitted.

But why? For security critical software, like this, they should assume as little as possible. In essence you want to make the algorithms immune to side channel attacks when possible.

Because the more complexity you have in software, the harder it is to keep it secure. Even security mitigations can potentially introduce another vulnerabilities. This is one of the reasons that as a general rule we should strive for software to be kept simple.

Given the nature of this software, it's natural to have mitigations against side channel attacks. They happen multiple times, and will happen in the future, no matter how secure we believe the hardware is.

With that in mind, it's probably the better strategy to use slower and more complicated algorithms to protect the user. This would mean that when a side channel attack becomes known, if the algorithm already protects against it, nothing have to be done. Unlike if a fix needs to be made, you not face the problem you've outlined. I believe it's better to have a better baseline security at the cost of complexity, because it means less hotfixes needs to be released.

Re: SSH gets protection against side-channel attacks

#29

Post by castis » Fri, Jun 21, 2019, 12:58 PM UTC

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 dont understand the purpose of this question. The existing purpose is that it works at all?

Re: SSH gets protection against side-channel attacks

#30

Post by bigato » Fri, Jun 21, 2019, 1:00 PM UTC

hvidgaard wrote: post #28

bigato wrote: post #17

Earlier quoted context omitted.

Because the more complexity you have in software, the harder it is to keep it secure. Even security mitigations can potentially introduce another vulnerabilities. This is one of the reasons that as a general rule we should strive for software to be kept simple.

Given the nature of this software, it's natural to have mitigations against side channel attacks. They happen multiple times, and will happen in the future, no matter how secure we believe the hardware is. With that in mind, it's probably the better strategy to use slower and more complicated algorithms to protect the user. This would mean that when a side channel attack becomes known, if the algorithm already protec…

Side channel attacks are only possible because the hardware is currently vulnerable. They are not a law of nature. Once you solve the vulnerability at its root and it becomes physically inexistent, and there's no more running hardware in the market that has such vulnerability, it would make no sense to keep such software mitigation.