[SCM] GNU gnutls branch, master, updated. gnutls_2_9_10-17-g468b1d0

[Simon Josefsson]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU gnutls".

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=468b1d0d428cb36042ee4014bcac4a4513d1e74a

The branch, master has been updated
       via  468b1d0d428cb36042ee4014bcac4a4513d1e74a (commit)
      from  cfbed93c9dab1aca7b01a4bb42bcf86a15c8d832 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 468b1d0d428cb36042ee4014bcac4a4513d1e74a
Author: Simon Josefsson <address@hidden>
Date:   Fri Apr 30 16:50:14 2010 +0200

    Improve text, based on suggestions from Tomas Hoger <address@hidden>.

-----------------------------------------------------------------------

Summary of changes:
 doc/gnutls.texi |   27 ++++++++++++++++-----------
 1 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/doc/gnutls.texi b/doc/gnutls.texi
index 1e09e41..1748306 100644
--- a/doc/gnutls.texi
+++ b/doc/gnutls.texi
@@ -1238,18 +1238,23 @@ Some application protocols and implementations uses the 
TLS
 renegotiation feature in a manner that enables attackers to insert
 content of his choice in the beginning of a TLS session.
 
-The simplest example is HTTP.  For HTTP one attack works by having the
-attacker simulate a client and connect to a server, with server-only
-authentication, and send some data intended to cause harm.  When the
-proper client attempts to contact the server, the attacker hijacks
-that connection and uses the TLS renegotiation feature with the server
-and splices in the client connection to the already established
-connection between the client and server.  The attacker will not be
-able to read the data exchanged between the client and the server.
-However, some server implementations will (incorrectly) assume that
-the data sent by the attacker was sent by the now authenticated
+One easy to understand vulnerability is HTTPS when servers request
+client certificates optionally for certain parts of a web site.  The
+attack works by having the attacker simulate a client and connect to a
+server, with server-only authentication, and send some data intended
+to cause harm.  When the proper client attempts to contact the server,
+the attacker hijacks that connection and uses the TLS renegotiation
+feature with the server and splices in the client connection to the
+already established connection between the attacker and server.  The
+attacker will not be able to read the data exchanged between the
+client and the server.  However, the server will (incorrectly) assume
+that the data sent by the attacker was sent by the now authenticated
 client.  The result is a prefix plain-text injection attack.
 
+The above is just one example.  Other vulnerabilities exists that do
+not rely on the TLS renegotiation to change the client's authenticated
+status (either TLS or application layer).
+
 While fixing these application protocols and implementations would be
 one natural reaction, an extension to TLS has been designed that
 cryptographically binds together any renegotiated handshakes with the
@@ -1266,7 +1271,7 @@ extension has not been negotiated, as this would break 
backwards
 compatibility and cause too much operational problems.  We will likely
 reconsider these defaults in the future.
 
-To modify the default behaviour, we have introduced three new priority
+To modify the default behaviour, we have introduced four new priority
 strings.  The priority strings can be used by applications
 (@pxref{gnutls_priority_set}) and end users (e.g., @code{--priority}
 parameter to @code{gnutls-cli} and @code{gnutls-serv}).


hooks/post-receive
-- 
GNU gnutls