\subsection{Authentication using SRP}
Authentication using the SRP\footnote{SRP stands for Secure Password Protocol and
-is described in RFC2945. The SRP key exchange is not a part of the \tlsI protocol}
+is described in RFC2945. The SRP key exchange is not a part of the \tlsI{} protocol}
is actually password authentication, since the two peers are identified by the knowledge of a password.
-This protocol also offers protection against off-line attacks (password file stealing etc).
+This protocol also offers protection against off-line attacks, such as password
+file stealing.
This is achieved since SRP does not use the plain password to perform authentication, but something called a
verifier. The verifier is $g^{x}mod(n)$ and $x$ is a value calculated
from the username and the password.
a hash function based on blowfish crypt is also supported. The blowfish
crypt function has the property of variable complexity, thus the
verifier may resist future attacks based on computational power, by just increasing
-the complexity of the function (sometimes called 'the cost').
+the complexity of the function ---also called ``the cost''.
\par The advantage of SRP authentication, over other proposed secure password
authentication schemas, is that SRP does not require the server to hold
the user's password. This kind of protection is similar to the one used traditionaly
-in the \emph{UNIX} 'passwd' file, where the contents of this file did not cause
+in the \emph{UNIX} ``passwd'' file, where the contents of this file did not cause
harm to the system security if they were revealed.
\par
Available key exchange methods are shown in \hyperref{figure}{figure }{}{fig:srp}.
\label{fig:srp}
\end{figure}
+
+\subsubsection{The included ``srpcrypt'' program}
+The ``gnutls-srpcrypt'' is a very simple program that emulates the programs in the libsrp
+found in \htmladdnormallink{http://srp.stanford.edu}{http://srp.stanford.edu}.
+It is intended for use in places where you don't expect srp
+authentication to be the performed to system users.
+
+Traditionaly libsrp used two files. One called 'tpasswd' which holds usernames
+and verifiers, and 'tpasswd.conf' which holds generators and primes.
+\par
+How to use srpcrypt:
+
+\begin{itemize}
+
+
+\item To create tpasswd.conf which holds the g and n values for
+SRP protocol (generator and a large prime), run:
+\begin{verbatim}
+$ gnutls-srpcrypt --create_conf /etc/tpasswd.conf
+\end{verbatim}
+
+
+\item This command will create /etc/tpasswd and will add user 'test' (you will also
+be prompted for a password). Verifiers are stored by default in the
+way libsrp expects (using a modified SHA()). However using this tool you
+may also specify blowfish srpcrypt instead of SHA (see --crypt parameter).
+\begin{verbatim}
+$ gnutls-srpcrypt --passwd /etc/tpasswd \
+ --passwd_conf /etc/tpasswd.conf -u test
+\end{verbatim}
+
+\item This command will check against a password. If the password matches
+the one in /etc/tpasswd you will get an ok.
+\begin{verbatim}
+$ gnutls-srpcrypt --passwd /etc/tpasswd \
+ --passwd_conf /etc/tpasswd.conf --verify -u test
+\end{verbatim}
+
+\end{itemize}
{\bf TLS\_DHE\_RSA\_WITH\_3DES\_CBC\_SHA}.
The usual cipher suites contain these parameters:
\begin{itemize}
-\item The key exchange algorithm (DHE\_RSA in the example)
-\item The Symmetric encryption algorithm and mode (3DES\_CBC in this
-example)
+\item The key exchange algorithm ---DHE\_RSA in the example.
+\item The Symmetric encryption algorithm and mode ---3DES\_CBC in this
+example.
\item The MAC\footnote{MAC stands for Message Authentication Code. It can
be described as a keyed hash algorithm. See RFC2104.} algorithm used for authentication.
MAC\_SHA is used in the above example.
The ciphersuite negotiated in the handshake protocol, will affect
the Record Protocol, by enabling encryption and data authentication.
-Note that \tlsI{} does not always
-negotiate the strongest available cipher suite. There are cases where
-a man in the middle attacker could make the two entities negotiate
-the least secure method they support. For that reason do not enable
+Note that you should not overrely on \tls{} to negotiate the strongest
+available cipher suite. Do not enable
ciphers and algorithms that you consider weak.
\addvspace{1.5cm}
Fatal errors terminate the connection immediately and
further sends ard receives will be disallowed. An example of
a fatal error code is GNUTLS\_E\_DECRYPTION\_FAILED. Non-fatal errors
-may warn about something (ie a warning alert was received), or
+may warn about something, ie a warning alert was received, or
indicate the some action has to be taken. This is the case with
the error code GNUTLS\_E\_REHANDSHAKE returned by
\hyperref{gnutls\_record\_recv()}{gnutls\_record\_recv() (see Section }{)}{gnutls_record_recv}.
-\subsection{Client with Resume capability example}
-\label{resume-example}
\begin{verbatim}
#include <stdio.h>
\subsection{Simple client example with X.509 certificate support}
Let's assume now that we want to create a client which communicates
-with servers using the X509 authentication schema. The following client
+with servers using the X.509 authentication schema. The following client
is a very simple \tls{} client, it does not support session resuming nor
any other fancy features.
\input{ex2}
\subsection{Getting peer's information}
\par The above example was the simplest form of a client, it didn't even check
-the result of the peer's certificate verification function (ie. if we have
-an authenticated connection). The following function does check the peer's X509
-Certificate, and prints some information about the current state.
+the result of the peer's certificate verification function. The lack of
+this check may result to an unauthenticated connection.
+The following function does check the peer's
+X.509 certificate, and prints some information about the current state.
\par
This function should be called after a successful
\hyperref{gnutls\_handshake()}{gnutls\_handshake() (see Section }{)}{gnutls_handshake}
\input{ex3}
+\subsection{Client with Resume capability example}
+\label{resume-example}
+This is the same client as above, but here we add support for session
+resumption.
\input{ex1}
\subsection{Simple client example with SRP authentication}
This section contains examples of \tls{} and \ssl{} servers, using \gnutls{}.
\subsection{Echo Server with X.509 and SRP authentication}
-The following example is a server which supports both {\bf SRP} and {\bf X509} authentication.
+The following example is a server which supports both {\bf SRP} and {\bf X.509} authentication.
This server also supports {\it session resuming}.
\input{serv1}
\documentclass{book}
\usepackage{html}
-\usepackage{fancyheadings}
+\usepackage{fancyhdr}
\usepackage{graphicx}
\input{macros}
\newpage
\pagenumbering{arabic}
\pagestyle{fancy}
+\fancyhead[RE]{\slshape \rightmark}
+\fancyhead[LO]{\slshape \leftmark}
+\fancyhead[RO,LE]{\empty}
+\fancyfoot[C]{\thepage}
\chapter{The Library}
\section{Introduction}
function, is expensive since a lot of calculations are performed. In order to support many fast connections to
the same server a client may use session resuming. {\bf Session resuming} is a
feature of the {\bf TLS} protocol which allows a client to connect to a server,
-after a successful handshake, without the expensive calculations (by using the previously
-established keys). \gnutls{} supports this feature, and the
-example \hyperref{resume client}{resume client (see Section }{)}{resume-example} illustrates a typical use of it (This is a modification of the simple client example).
+after a successful handshake, without the expensive calculations. This is
+achieved by using the previously
+established keys. \gnutls{} supports this feature, and the
+example \hyperref{resume client}{resume client (see Section }{)}{resume-example} illustrates a typical use of it.
\par
Servers only need to use the
\hyperref{gnutls\_db\_set\_name()}{gnutls\_db\_set\_name() (see Section }{)}{gnutls_db_set_name} function if they want to use the gdbm
backend to store sessions.
\par
-Keep in mind that sessions are expired after some time (for security reasons), thus
+Keep in mind that sessions are expired after some time, for security reasons, thus
it may be normal for a server not to resume a session even if you requested that.
-Also note that you must enable (using the priority functions), at least the
+Also note that you must enable, using the priority functions, at least the
algorithms used in the last session.
\subsection{Resuming internals}
-The resuming capability (mostly in the server side) is one of the problems of a thread-safe TLS
+The resuming capability, mostly in the server side, is one of the problems of a thread-safe TLS
implementations. The problem is that all threads must share information in
order to be able to resume sessions. The gnutls approach is, in case of a
-client, to leave all the burden of resuming to the client (ie. copy and keep the
-nesessary parameters). See the functions:
+client, to leave all the burden of resuming to the client. Ie. copy and keep the
+nesessary parameters. See the functions:
\begin{itemize}
\item \hyperref{gnutls\_session\_get\_data()}
{gnutls\_session\_get\_data() on section }{}{gnutls_session_get_data}
}
if (gnutls_certificate_set_x509_trust_file(x509_cred, CAFILE,
GNUTLS_X509_FMT_PEM) < 0) {
- fprintf(stderr, "X509 PARSE ERROR\nDid you have ca.pem?\n");
+ fprintf(stderr, "X509 PARSE ERROR\nDo you have ca.pem?\n");
exit(1);
}
if (gnutls_certificate_set_x509_key_file(x509_cred, CERTFILE, KEYFILE,
GNUTLS_X509_FMT_PEM) < 0) {
- fprintf(stderr, "X509 PARSE ERROR\nDid you have key.pem and cert.pem?\n");
+ fprintf(stderr, "X509 PARSE ERROR\nDo you have key.pem and cert.pem?\n");
exit(1);
}
- /* SRP_PASSWD a password file (created with the included crypt utility)
- * Read README.crypt prior to using SRP.
+ /* SRP_PASSWD a password file (created with the included srpcrypt utility)
*/
gnutls_srp_allocate_server_sc(&srp_cred);
gnutls_srp_set_server_cred_file(srp_cred, SRP_PASSWD, SRP_PASSWD_CONF);
#define _MAX(x,y) x>y?x:y
+/* This may need some rewrite. A lot of stuff which should be here
+ * are in the library, which is not good.
+ */
+
int crypt_int(char *username, char *passwd, int crypt, int salt,
char *tpasswd_conf, char *tpasswd, int uindex);
static int read_conf_values(MPI * g, MPI * n, char *str, int str_size);
/* this function parses tpasswd.conf file. Format is:
- * int(index):base64(n):int(g)
+ * int(index):base64(n):base64(g)
*/
static int read_conf_values(MPI * g, MPI * n, char *str, int str_size)
{
projects / thirdparty / gnutls.git / commitdiff
