Be specific about SSLv2 security problems.

diff --git a/doc/gnutls.texi b/doc/gnutls.texi
index 2562648d94df0a90cc81512aeeea566b25610d6e..57447a9760b35efff37bec6a15643867b811b7b6 100644 (file)
--- a/doc/gnutls.texi
+++ b/doc/gnutls.texi
@@ -795,7 +795,31 @@ One question that may arise is why we didn't implement @acronym{SSL}
 2.0 in the library.  There are several reasons, most important being
 that it has serious security flaws, unacceptable for a modern security
 library.  Other than that, this protocol is barely used by anyone
-these days since it has been deprecated since 1996.
+these days since it has been deprecated since 1996.  The security
+problems in @acronym{SSL} 2.0 include:
+
+@itemize
+
+@item Message integrity compromised
+The @acronym{SSLv2} message authentication uses the MD5 function, and
+is insecure.
+
+@item Man-in-the-middle attack
+There is no protection of the handshake in @acronym{SSLv2}, which
+permits a man-in-the-middle attack.
+
+@item Truncation attack
+@acronym{SSLv2} relies on TCP FIN to close the session, so the
+attacker can forge a TCP FIN, and the peer cannot tell if it was a
+legitimate end of data or not.
+
+@item Weak message integrity for export ciphers
+The cryptographic keys in @acronym{SSLv2} are used for both message
+authentication and encryption, so if weak encryption schemes are
+negotiated (say 40-bit keys) the message authentication code use the
+same weak key, which isn't necessary.
+
+@end itemize
 
 @cindex PCT
 Other protocols such as Microsoft's @acronym{PCT} 1 and @acronym{PCT}