How does this SSL-related flaw work?

Question

I just saw a video at CNN in which it is claimed that, if the server isn't generating a random public key, the server can be hacked.

First how HTTPS works… to be sure I’m on the same page:

• Server has a public key and a private key. Client uses the public key to encrypt data before sending it to the server. Then the server uses its private key to decrypt that data… which is the only way to decrypt it.
• Client makes sure – using an SSL service provider – that the public key the server is offering is indeed genuine and belongs to that server. Otherwise, if someone “in-the-middle” would change the key, then that someone (via a fake server) would be able to read the data instead of the actual server.

Questions:

• Does a server that offers HTTPS have to update its public key for every request it gets? Or is it true that – usually – it doesn't and therefore the claimed flaw exists?
• How is the man in the video able to get the password? How is he able decrypt without using the private key?

If my understanding of SSL is bad, so it would be nice if you could explain this flaw to me.

Answer 1

Assuming this is "usual" HTTPS using SSL/TLS with RSA key exchange, the client generates a random secret, encrypts it with RSA (using the server's public key) and sends it to the server. The server then decrypts it (using its private key), and both generate from this (now shared) secret (and some public data depending on the messages) several keys which are used for encryption and MAC in both directions.
Then the actual HTTP message is sent encrypted using the exchanged key.

The video is not really clear in how the "hacker" breaks the encryption.

Here are two possibilities how bad random numbers might do this:

• The server generated its RSA key pair using bad randomness, and the hacker succeeded to guess these random numbers, and thus arrive at the same key pair. Of course, then a simple packet sniffer can decrypt the message with the RSA-encrypted secret, and from this calculate the session keys.

• The client generated its "secret" (which would be sent to the server) using bad randomness. The hacker guessed this secret (verified the guess by RSA-encrypting it using the public key), and then could derive the same session keys as client and server.

Note that using a Diffie-Hellman-based key exchange would prevent at least the first attack, assuming the ephemeral public DH-key has enough entropy to prevent brute-forcing it during the attack.

Using a different RSA public key for each session (or at least rotating every some time) might also help, but requires that there is a master key available to sign it (i.e. have a CA on the server or nearby), and also needs enough entropy to actually help. (And if the master key has not enough entropy, still a MitM can break this.)

I can imagine some other (non-crypto) ways how this video could be created:

• The "hacker" might be the owner of the server, and thus knows everything sent to it.
• The "hacker" is the owner of the notebook, and thus can see everything sent from it.
• The "hacker" configured the notebook to use some proxy, and to trust the certificate of the proxy. The proxy then can log everything.

These don't relate to any random number problem.