summaryrefslogtreecommitdiff
path: root/doc/tex/handshake.tex
blob: e34889aa0762215e0f801d3c3f73dd544fc876f8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
\section{The TLS handshake protocol\index{TLS protocols!Handshake}}
\label{handshake}

The Handshake protocol is fully controlled by application layer (your 
program). Within this protocol the parameters for cipher suites, supported
authentication methods etc. are negotiated. Thus the application layer
has to set up the required parameters for the connection.
See the following functions:
\begin{itemize}
\item \printfunc{gnutls_cipher_set_priority}{gnutls\_cipher\_set\_priority}:
to set the priority of bulk cipher algorithms.
\item \printfunc{gnutls_mac_set_priority}{gnutls\_mac\_set\_priority}:
to set the priority of MAC algorithms.
\item \printfunc{gnutls_kx_set_priority}{gnutls\_kx\_set\_priority}:
to set the priority of key exchange algorithms.
\item \printfunc{gnutls_compression_set_priority}{gnutls\_compression\_set\_priority}:
to set the priority of compression methods.
\item \printfunc{gnutls_certificate_type_set_priority}{gnutls\_certificate\_type\_set\_priority}:
to set the priority of certificate types (ie. OpenPGP, X.509).
\item \printfunc{gnutls_protocol_set_priority}{gnutls\_protocol\_set\_priority}:
to set the priority of protocol versions (ie. \sslIII{}, \tlsI).
\item \printfunc{gnutls_set_default_priority}{gnutls\_set\_default\_priority}:
to set some defaults in the current session. That way you don't have to call each
priority function, independently, but you have to live with the defaults.

\item \printfunc{gnutls_credentials_set}{gnutls\_credentials\_set}: to set the
appropriate credentials structures.
\item \printfunc{gnutls_certificate_server_set_request}
{gnutls\_certificate\_server\_set\_request}: to set
whether client certificate is required or not.
\item \printfunc{gnutls_handshake}{gnutls\_handshake}: to initiate the
handshake.
\end{itemize}

\input{ciphersuites}

\subsection{Client authentication}
In the case of ciphersuites that use certificate authentication, the
authentication\index{Certificate authentication!Client} of the client is
optional in \tls{}. A server may request a certificate from the client -- using the
\printfunc{gnutls_certificate_server_set_request}{gnutls\_certificate\_server\_set\_request}
function. If a certificate is to be requested by the client, at the handshake
procedure, the server will send an extra packet,
than contains a list of acceptable certificate signers, and indicates the
request of a certificate. The client may then send a certificate, signed
by one of the server's acceptable signers. In \gnutls{} the server's acceptable
signers list is constructed using the trusted CA certificates in the
credentials structure.

\subsection{Resuming Sessions\index{Resuming sessions}}
\label{resume}
\par
The 
\printfunc{gnutls_handshake}{gnutls\_handshake}
 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. 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
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
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
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
necessary parameters. See the functions:
\begin{itemize}
\item \printfunc{gnutls_session_get_data}{gnutls\_session\_get\_data}
\item \printfunc{gnutls_session_get_id}{gnutls\_session\_get\_id}
\item \printfunc{gnutls_session_set_data}{gnutls\_session\_set\_data}
\end{itemize}

\par
The server side is different. A server has to specify some callback functions
which store, retrieve and delete session data. These can be registered with:
\begin{itemize}
\item \printfunc{gnutls_db_set_remove_function}{gnutls\_db\_set\_remove\_function}
\item \printfunc{gnutls_db_set_store_function}{gnutls\_db\_set\_store\_function}
\item \printfunc{gnutls_db_set_retrieve_function}{gnutls\_db\_set\_retrieve\_function}
\item \printfunc{gnutls_db_set_ptr}{gnutls\_db\_set\_ptr}
\end{itemize}

\par
It might also be useful to be able to check for expired sessions in order to remove 
them, and save space. The function
\printfunc{gnutls_db_check_entry}{gnutls\_db\_check\_entry} is provided for that
reason.