Corrected a bug in certificate verification. Pointed out by

Yoann Vandoorselaere <yoann@prelude-ids.org>

6 files changed, 39 insertions, 25 deletions

diff --git a/NEWS b/NEWS
index 9dd15b219c..923814f977 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,9 @@
+Version 1.0.15
+- Fixed bug in RSA encryption, report and patch by Martijn Koster 
+  <mak@greenhills.co.uk>.
+- Corrected a bug in certificate verification. Pointed out by
+  Yoann Vandoorselaere <yoann@prelude-ids.org>
+
 Version 1.0.14 (12/06/2004)
 - Automatically disable certificate types that do not have corresponding
   certificates.
diff --git a/doc/tex/certificate.tex b/doc/tex/certificate.tex
index 4210a5dcdc..e93b032f59 100644
--- a/doc/tex/certificate.tex
+++ b/doc/tex/certificate.tex
@@ -105,8 +105,8 @@ CRL distribution points & 2.5.29.31 & This extension is set by the CA, in order
 \\
 \par
 In \gnutls{} the X.509 certificate structures are handled using the
-\emph{gnutls\_x509\_crt} type and the corresponding private keys with
-the \emph{gnutls\_x509\_privkey} type.
+\emph{gnutls\_x509\_crt\_t} type and the corresponding private keys with
+the \emph{gnutls\_x509\_privkey\_t} type.
 All the available functions for X.509 certificate handling have their 
 prototypes in \emph{gnutls/x509.h}. An example program to demonstrate the 
 X.509 parsing capabilities can be found at section \ref{ex:x509-info} on 
@@ -145,8 +145,8 @@ CERT\_SIGNER\_NOT\_FOUND & The certificate's issuer is not known.
 Although the verification of a certificate path indicates that the
 certificate is signed by trusted authority, does not reveal anything
 about the peer's identity. It is required to verify if the certificate's
-owner is the one you expect. See section \ref{ex:rfc2818} on page \pageref{ex:rfc2818},
-for an example.
+owner is the one you expect. See \cite{RFC2818} and section \ref{ex:verify-chain} 
+on page \pageref{ex:verify-chain} for an example.
 
 
 \subsection{PKCS \#10 certificate requests\index{Certificate requests}\index
@@ -159,7 +159,7 @@ defined in PKCS \#10 \cite{RFC2986}. Other certificate request's format such as
 PKIX's RFC2511 \cite{RFC2511} are not currently supported.
 
 In \gnutls{} the PKCS \#10 structures are handled using the
-\emph{gnutls\_x509\_crq} type. 
+\emph{gnutls\_x509\_crq\_t} type. 
 An example of a certificate request generation can be found at section \ref{ex:crq}
 on page \pageref{ex:crq}.
 
@@ -169,8 +169,8 @@ certificates. It is commonly used in browsers to export and import
 the user's identities.
 \par
 In \gnutls{} the PKCS \#12 structures are handled using the
-\emph{gnutls\_pkcs12} type. This is an abstract type that
-may hold several \emph{gnutls\_pkcs12\_bag} types. The Bag types are the
+\emph{gnutls\_pkcs12\_t} type. This is an abstract type that
+may hold several \emph{gnutls\_pkcs12\_bag\_t} types. The Bag types are the
 holders of the actual data, which may be certificates, private
 keys or encrypted data. An Bag of type encrypted should be decrypted
 in order for its data to be accessed. 
@@ -211,15 +211,17 @@ actual owner.
 
 \subsection*{OpenPGP keys}
 In \gnutls{} the OpenPGP key structures \cite{RFC2440} are handled using the
-\emph{gnutls\_openpgp\_key} type and the corresponding private keys with
-the \emph{gnutls\_openpgp\_privkey} type. All the prototypes for the key handling
+\emph{gnutls\_openpgp\_key\_t} type and the corresponding private keys with
+the \emph{gnutls\_openpgp\_privkey\_t} type. All the prototypes for the key handling
 functions can be found at \emph{gnutls/openpgp.h}.
 
 \subsection*{Verifying an OpenPGP key}
 The verification functions of OpenPGP keys, included in \gnutls{}, 
 are simple ones, and do not use the features of the ``web of trust''.
 For that reason, if the verification needs are complex, 
-the assistance of external tools like GnuPG is recommended.
+the assistance of external tools like GnuPG and GPGME\footnote{
+Available at \htmladdnormallink{http://www.gnupg.org/related\_software/gpgme/}}
+is recommended.
 \par
 There are two verification functions in \gnutls{},
 The \printfunc{gnutls_openpgp_key_verify_ring}{gnutls\_openpgp\_key\_verify\_ring}
diff --git a/doc/tex/gnutls.bib b/doc/tex/gnutls.bib
index 55c265fa0d..5c6df9692e 100644
--- a/doc/tex/gnutls.bib
+++ b/doc/tex/gnutls.bib
@@ -87,6 +87,12 @@
   year =         {1999},
 }
 
+@Misc{RESCOLA,
+  author =       "Eric Rescola",
+  title =        "SSL and TLS: Designing and Building Secure Systems",
+  year =         {2001},
+}
+
 @Misc{TLSEXT,
   author =       "Simon Blake-Wilson and Magnus Nystrom and David Hopwood and Jan Mikkelsen and Tim Wright",
   title =        "Transport Layer Security (TLS) Extensions",
diff --git a/doc/tex/tlsintro.tex b/doc/tex/tlsintro.tex
index 39f158e319..636a47eb24 100644
--- a/doc/tex/tlsintro.tex
+++ b/doc/tex/tlsintro.tex
@@ -3,17 +3,18 @@
 \label{sec:tlsintro}
 \tls{} stands for 'Transport Layer Security' and is the successor of \ssl{},
 the Secure Sockets Layer protocol\footnote{described in \cite{SSL3}} designed by Netscape. 
-\tlsI{}\footnote{described in {\it RFC 2246}\cite{RFC2246}} is an Internet protocol,
+\tlsI{} is an Internet protocol,
 defined by {IETF}\footnote{IETF or Internet Engineering Task Force 
 is a large open international community of network
 designers, operators, vendors, and researchers concerned with the evolution of 
 the Internet architecture and the smooth operation of the Internet. It is open 
-to any interested individual.}, 
-that provides confidentiality, and authentication layers over any reliable
-transport layer. The description, below, refers to \tlsI{} but also
-applies to \sslIII{} since the differences of these protocols are minor.
-Older protocols such as \sslII{} are not discussed nor implemented in \gnutls{} 
-since they are not considered secure today.
+to any interested individual.}, described in \cite{RFC2246} and
+also in \cite{RESCOLA}. The protocol provides confidentiality, and 
+authentication layers over any reliable transport layer. The description, 
+below, refers to \tlsI{} but also applies to \sslIII{} since the differences 
+of these protocols are minor. Older protocols such as \sslII{} are not 
+discussed nor implemented in \gnutls{} since they are not considered secure 
+today.
 
 \input{layers}
 
diff --git a/lib/x509/verify.c b/lib/x509/verify.c
index 9b3f658b00..44a152b7d3 100644
--- a/lib/x509/verify.c
+++ b/lib/x509/verify.c
@@ -96,15 +96,14 @@ int result;
 	}
 
 	if (cert_signed_data.size == issuer_signed_data.size) {
-		if (
-		    (memcmp(cert_signed_data.data, issuer_signed_data.data,
+		if ((memcmp(cert_signed_data.data, issuer_signed_data.data,
 		    	cert_signed_data.size) == 0) &&
 		    (cert_signature.size == issuer_signature.size) &&
 		    (memcmp(cert_signature.data, issuer_signature.data,
-		    	cert_signature.size) == 0))
-
+		    	cert_signature.size) == 0)) {
 			result = 1;
 			goto cleanup;
+		}
 	}
 
 	if (gnutls_x509_crt_get_ca_status(issuer, NULL) == 1) {
diff --git a/libextra/gnutls_srp.c b/libextra/gnutls_srp.c
index 3b4c605704..2ea75ecb8b 100644
--- a/libextra/gnutls_srp.c
+++ b/libextra/gnutls_srp.c
@@ -586,13 +586,13 @@ void gnutls_srp_server_set_select_function(gnutls_session session,
   * In case the callback returned a negative number then gnutls will
   * assume that the username does not exist.
   *
-  * In order to prevent allowing an attack to guess valid usernames,
-  * if username does not exist, the g, and n values should be filled in 
-  * using a random user's parameters. In that case the callback should
+  * In order to prevent attackers from guessing valid usernames,
+  * if a user does not exist, g and n values should be filled in 
+  * using a random user's parameters. In that case the callback must
   * return the special value (1).
   *
   * The callback function will only be called once per handshake.
-  * The callback function should return 0 on success.
+  * The callback function should return 0 on success, while
   * -1 indicates an error.
   *
   **/