POODLE

lectures/lec27.tex

@@ -18,12 +18,55 @@ \subsection{How it Happened}
 
 As we have covered many times, passwords are terrible for authentication. Signatures, as used with standards like FIDO2/WebAuthn, provide much stronger security and should be used whenever possible.
 
-\section{Transport Security: Mining your Ps \& Qs}
-TLS is used all over the web, and many hardware devices from routers to doorbells run TLS servers to provide management interfaces. To run TLS, these devices need a public key, and thus must generate that public key. In RSA, which used to be the most popular signature algorithm, a key was generated by multiplying to large primes $p$ and $q$ such that $N = pq$. The key idea is that no one except the signer knows the factorization of $N$.
-
-When these devices boot for the first time, they need to generate this public key. And for the factorization to be secret, $p$ and $q$ must be random. However, many devices like routers and doorbells do not have the input devices, hard drives, and other sources of randomness that are typically used to generate secure keys. 
-
-It turned out that many of these devices were not able to generate enough randomness before they generated their keys. As a result, researchers that scanned the web found that many keys generated by these devices were duplicated. They also found that many pairs of keys shared one of their two prime factors. In either case, it was easy to factorize these keys and thus find the corresponding private key.
+\section{Transport Security: POODLE}
+
+TLS is used all over the web.  Many servers, from data centers to embedded
+hardware devices, like doorbells, implement TLS.  Some of these servers
+take a long time to upgrade, so even if a client supports the latest
+version of TLS (e.g., TLS 1.3), it might be unable to use TLS 1.3 to
+communicate with some servers.  To handle this situation, TLS implements
+version negotiation; the client and server should agree to use the most
+recent version of TLS supported by both sides.  However, the way this
+negotiation was implemented was subtly insecure.
+
+When an old server receives a message from a new client speaking a
+new version of TLS that the server does not support, the server might
+reply back with garbage data.  This could be due to a bug in the server
+implementation, which was never found because the developers didn't
+think in advance to test against various ways that future clients sending
+messages from a future version of TLS.  Despite the fact that this is a
+server bug, users want to still be able to communicate with this device;
+after all, communicating with the device worked fine before the client
+upgraded to support a new version of TLS.  As a result, clients that
+receive garbage data in response to their TLS connection attempt will
+try to downgrade the version of TLS that they use to connect in their
+next attempt.  However, the ``garbage'' that the client is reacting to
+was not authenticated.  Therefore, an adversary could inject garbage to
+force a client to downgrade to an older TLS/SSL version.
+
+Old versions of TLS/SSL have well-known weaknesses in their cryptographic
+protocol.  In particular, SSL 3.0 computed the MAC of the message
+(for authentication) before encrypting the message (MAC-then-encrypt),
+rather than the encrypt-then-MAC approach that we discussed in the
+authenticated encryption lecture.  This allowed the attacker to send
+corrupted ciphertexts and see how the client or server respond to them.
+In combination with MAC-then-encrypt, SSL 3.0 also used a particular
+encryption construction, called cipher-block-chaining (CBC) mode, whereby
+changing bits in one part of the ciphertext caused corresponding changes
+to another part of the plaintext.  Finally, the plaintext payload included
+padding, constructed with a well-known scheme, which was checked after
+decryption to make sure it was not corrupted; if the padding was corrupted,
+the connection was terminated.  However, this gives a signal to the adversary
+as to whether their corrupted ciphertext happens to match the expected padding
+or not.  We saw the CBC padding oracle attack earlier in the lecture on
+authenticated encryption.
+
+The POODLE attack was a combination of these two weaknesses (downgrade
+attack and CBC padding oracle), together with running adversary-supplied
+code in Javascript in the victim user's web browser, as a way of sending
+partially-adversary-chosen requests over the TLS/SSL connection.
+The result is that the adversary can recover other data sent to the
+server over the same connection, such as the victim's cookie.
 
 \section{Platform Security: Sony PS3 Hack}