Selfie: reflections on TLS 1.3 with PSK | Hacker News Reader

Selfie: reflections on TLS 1.3 with PSK

eprint.iacr.org

57 pointsokket5 comments

The attack can only happen in an unusual setting (nodes using external PSKs that can act as both client and server simultaneously), meaning that this vulnerability will not have too much impact on the open internet.

The more interesting issue here is that this sort of vulnerability should/could have been found through the numerous proofs of security that were created for TLS1.3.

IMO the most interesting insights that can be found in this paper come from section 6, where they consider how the proofs missed. It turns out that the proofs did not consider the possibility that a client and a server would simultaneously possess the same PSK, but IRL the sub-entities of a single node will do so.

That’s a pretty interesting attack.

The short version is that you have a client and server as the same endpoint, and TLS 1.3 allows you to use the same PreSharedKey as a client and as a server. If you can be tricked by a man in the middle to be a client and a server at the same time - you would be talking to yourself using the same PSK on both ends.

This means the attacker ‘could’ cause trouble if the messages you meant to send to someone else are valid messages you could also act on like “please delete this file”.

I didn’t see where the PSK was lost anywhere. Only the situation that the message you send could be performed by you as if you had received it.

Interesting, but seemed limited in scope. I’m also not seeing where the attacker ever understands the message they echo. They would just have to hope it caused problems.

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.

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/

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.

Reply on news.ycombinator.com