3 ms·

Note: this is specifically an issue with the Pre Shared Key (PSK) mode - which is not the standard "I set up a public site with LetsEncrypt or a cert from GoDad

Note: this is specifically an issue with the Pre Shared Key (PSK) mode - which is not the standard "I set up a public site with LetsEncrypt or a cert from GoDaddy" configuration, but something more often used internally within an organization so you don't have to rely on dealing with a certificate authority.

rwmj 8y ago
Unfortunately we're using PSKs with NBD[1] as it's considerably easier to set up than certificates. The idea is the keys are shared securely over an existing TLS connection (secured using certificates), eg. over an existing REST API, granting one time or short period access to an NBD resource. I believe we're not vulnerable to this specific one because we're not acting as both a client and server. Hopefully they'll find a way to fix this without deprecating or reducing the security/ease-of-use of PSK. [1] https://rwmj.wordpress.com/2018/06/26/nbd-with-tls-psk/ https://rwmj.wordpress.com/2018/06/26/nbd-with-tls-psk/
- tialaramex 8y ago
  The likely repair will simply be, as the paper says, to explicitly call out that you should not use a PSK to protect more than one client:server relationship, even if they're symmetrical. So if you have two machines Alice and Bob which each provide an NBD to the other, you need two separate PSKs, one for "Alice mounting Bob's disk" and the other for "Bob mounting Alice's disk" whereas it might naively have seemed reasonable previously to choose one PSK since they both need it anyway. The other thing you could reasonably do (and maybe this is relevant for NDB) that is mentioned in the paper is to check SNI. TLS 1.3 clients are supposed to say "Hi, I want to talk to www.example.com", unless they were told to connect to something that doesn't have a name, like an IP address. If Alice's NBD server checks incoming requests and rejects any that don't say "I want to talk to Alice's disk" then we can't confuse Alice into connecting to her own disk thinking its Bob's even if they have the same PSK, when her client says "I want to talk to Bob's disk" it will get told this is the wrong place go away.

rwmj 8y ago

Unfortunately we're using PSKs with NBD[1] as it's considerably easier to set up than certificates. The idea is the keys are shared securely over an existing TLS connection (secured using certificates), eg. over an existing REST API, granting one time or short period access to an NBD resource. I believe we're not vulnerable to this specific one because we're not acting as both a client and server. Hopefully they'll find a way to fix this without deprecating or reducing the security/ease-of-use of PSK. [1] https://rwmj.wordpress.com/2018/06/26/nbd-with-tls-psk/ https://rwmj.wordpress.com/2018/06/26/nbd-with-tls-psk/

tialaramex 8y ago
The likely repair will simply be, as the paper says, to explicitly call out that you should not use a PSK to protect more than one client:server relationship, even if they're symmetrical. So if you have two machines Alice and Bob which each provide an NBD to the other, you need two separate PSKs, one for "Alice mounting Bob's disk" and the other for "Bob mounting Alice's disk" whereas it might naively have seemed reasonable previously to choose one PSK since they both need it anyway. The other thing you could reasonably do (and maybe this is relevant for NDB) that is mentioned in the paper is to check SNI. TLS 1.3 clients are supposed to say "Hi, I want to talk to www.example.com", unless they were told to connect to something that doesn't have a name, like an IP address. If Alice's NBD server checks incoming requests and rejects any that don't say "I want to talk to Alice's disk" then we can't confuse Alice into connecting to her own disk thinking its Bob's even if they have the same PSK, when her client says "I want to talk to Bob's disk" it will get told this is the wrong place go away.