5

I'm looking for a list of scenarios and protocols that are vulnerable (or not vulnerable to) half-PFS protection.

Half PFS, as I understand it, is where the communication between a client and server can be decrypted if one side is hacked. This IETF mailing list describes OPTLS as only providing half protection for the session.

Question

  • What is "half protection", and how does it relate to TLS 1.0 and newer protocols?

  • Are there other implementations (DTLS, ???) that are capable of PFS but have a similar vulnerability?

makerofthings7
  • 50,090
  • 54
  • 250
  • 536

1 Answers1

1

I'm not completely sure I understand the concept. But I think that the point is that with short term ("ephemeral") asymmetric keys (DH, ECDH nowadays. But "ephemeral RSA" used to be a thing as well.) there are several opinions about exactly how short term these keys are supposed to be.

At the high paranoia end "short term" might mean "once for each connection". And at the low paranoia end "short term" might mean "until you reinstall the software because key shares are only ever generated on install". -- And everything in between. For example with F5 I think the default is to regenerate DH keys once per hour. But you can optionally set the "single DH use parameter" to actually regenerate for each connection. And OpenSSL has an option called "SSL_OP_SINGLE_DH_USE" that, I think, does the same thing. And otherwise DH keys are only regenerated upon server restart. And with Citrix NetScaler you can define a max count of connections after which the DH keys are regenerated.

(See a related answer of mine.)

I don't think the TLS specs ever specify how often you're supposed to regenerate ephemeral keys. I think they leave this up to implementor completely and never make an explicit or even implicit comment.

Now what does this mean security wise? Let's assume that you have a TLS connection. With the best case -- single DH use -- on one end. And a not so good case -- regeneration of DH keys upon server restart -- on the other end. And let's a assume that we have a man in the middle attacker who is employing a "take-all" attack. And just logs encrypted traffic for a few weeks.

Now if that attacker somehow gets a non-full compromise of one of the connection ends -- like e.g. a snapshot with RAM of one of that ends -- what does that give him?

If he is lucky enough to get the snapshot of the not-so-good end than this would allow that attacker to retroactively decrypt any logged past DHE secured connection from the past. Since server restart. And also INTO THE FUTURE until the next restart.

And it doesn't matter if all the other ends are constantly changing their part the ephemeral key dance.

Hope this somehow answers your question.

Side note: there was actually some DEMAND for TLS clients/servers that DO NOT actually have much ephemerality (is that a word?) to their ephemeral keys during the TLS 1.3 design process: https://datatracker.ietf.org/doc/html/draft-rhrd-tls-tls13-visibility

Community
  • 1
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86