Re: [TLS] Broken browser behaviour with SCADA TLS

[Peter Gutmann <[e-mail]>]

Martin Rex <[e-mail]> writes:

>Cough, what?  TLS_DHE_ was known to be a security disaster beyond fixing a
>good decade ago (14-May-2007):
>
>   https://www.ietf.org/mail-archive/web/tls/current/msg01647.html

That's not DHE that's the problem, it's the use of ridiculously short toy keys
that were known to be insecure 20-25 years ago when they were mandated for
export grade use.

>but it needed a LOGJAM demonstration to have folks look at the crappy
>implementations in the installed base.

Sure, LOGJAM pointed it out, and spurred fixes (finally), just like FREAK did
for RSA (and BEAST did, and POODLE did, and CRIME did, and BREACH did, and
FLUFFYBUNNY did, and Heartbleed did, it always takes some attack with a cool
name before people fix their code).  I'm still waiting for a paper to point
out that 512-bit DSA and secp160 are insecure, I assume the lack of public use
of these is what's prevented that.

The point is it has nothing to do with DHE, you've got exactly the same
vulnerability with RSA-512, DH-512, DSA-512, Elgamal-512, and Mr-Not-
Appearing-in-this-List-512.  

LOGJAM had two great contributions, firstly pointing out that there were a
scary number of servers that still allowed toy keys, and secondly providing a
baseline where, if you're worth less than several hundred million to several
billion dollars to an attacker, DH-1024 is still OK (as long as it's not
group2, that one's a bit too risky).

>Probably most usage scenarios that still offer TLS_DHE today, provide less
>security than with static-RSA 2048-bit.

Sure, if you choose your DH key to be 512 bits and your RSA key to be 2048,
you can make that claim.  I'm going to choose my RSA key to be 128 bits and my
DH key to be 16384 bits, in which case DH wins again.  And by quite a margin,
I must say.

>How often does your SCADA devices (=servers) regenerate its DHE params?

That's a question I can't answer in general because I've only seen the source
code for a small number of vendor-specific embedded implementations (under
various NDAs), but both from the code and from knowing the coding style used
for these implementations, they'll do so on every connection because that's
how the textbooks describe it.  

These implementations do just enough to connect to a client or server (some
act as clients connecting to things like PLC control centres).  They are the
bare minimum needed to function.  Cert processing is done with memcpy() of a
pre-encoded blob.  TLS extensions are encoded with memcpy() and decoded with
memcmp().  You get the picture.  No-one would even think of the possibility of
cacheing DH parameters, let alone sit down and write the code for it.

>Static RSA-2048 will always be better than DHE-1024.  

Since this will be exposing a private-key op with every decryption oracle and
side channel known to research science directly to anything on the network
(see the comment above on how these implementations are written), I'm going to
disagree with you there.  With DH you've admittedly still got the RSA sig, but
that's buried behind/under so much other stuff I doubt it's exploitable.

>Simply regenerate and roll your RSA keys&server cert if it makes you feel
>good.

Since that could involve a firmware reflash (with the new cert coded into the
firmware), on a remote device that can never go offline, it's not likely to
happen.

In a previous message I mentioned an example of using DSA for TLS.  This is
because you can generate a DSA key in essentially zero memory with a single
modexp, which completes before the watchdog times out and restarts the system.
You can't do that with RSA in hard real-time.  

Also, there's no way to "roll the cert", it's baked in at the factory or when
the device is deployed.  Well, a reflash I guess, but then see above.

>btw. which kind of "problematic pure-RSA" are you talking of?

See above, exposing your private key via every kind of side channel and
decryption oracle to a network attacker.

>because of the illusion of PFS, which they create but do not offer.

Maybe I shouldn't have mentioned PFS, I used that as an example because it was
quicker than writing several paragraphs on why pure RSA is dangerous.  PFS is
actually more or less irrelevant for SCADA, it's something cryptographers care
about but SCADA folks don't because pretty much all the traffic being carried
is tactical, no-one's worried about an attacker being able to go back later
and see that you sent a pilot-operated relief valve activation command two
weeks ago in your non-PFS encrypted traffic.

Peter.