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
97
98
99
100
101
102
103
104
|
\section{The TLS handshake protocol}
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_cert_type_set_priority}{gnutls\_cert\_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_cred_set}{gnutls\_cred\_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{Resuming Sessions}
\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 (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).
\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
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
nesessary parameters). See the functions:
\begin{itemize}
\item \hyperref{gnutls\_session\_get\_data()}
{gnutls\_session\_get\_data() on section }{}{gnutls_session_get_data}
\item \hyperref{gnutls\_session\_get\_id()}
{gnutls\_session\_get\_id() on section }{}{gnutls_session_get_id}
\item \hyperref{gnutls\_session\_set\_data()}
{gnutls\_session\_set\_data() on section }{}{gnutls_session_set_data}
\end{itemize}
\par
The server side is different.
Here the server only specifies a DB file, using
\hyperref{gnutls\_db\_set\_name()}{gnutls\_db\_set\_name() (see Section }{)}{gnutls_db_set_name}.
This DB file is used to store the sessions' required parameters for
resuming. This means that this file contains very sensitive information,
such as encryption keys. In a multi-threaded application every thread can
read from the DB file and access all previously established sessions, but
only one thread can write at a time. The current behaviour of gnutls is
not to block to wait for the DB to be ready for writing, but continue the
process normally (and do not save the parameters).
\par
The default behaviour is not efficient in servers where many connections
per second arrive. Thus
\gnutls{} provides the following callback functions:
\begin{itemize}
\item \hyperref{gnutls\_db\_set\_remove\_function()}{gnutls\_db\_set\_remove\_function() (see Section }{)}
{gnutls_db_set_remove_function}
\item \hyperref{gnutls\_db\_set\_store\_function()}{gnutls\_db\_set\_store\_function() (see Section }{)}
{gnutls_db_set_store_function}
\item \hyperref{gnutls\_db\_set\_retrieve\_function()}{gnutls\_db\_set\_retrieve\_function() (see Section }{)
}{gnutls_db_set_retrieve_function}
\item \hyperref{gnutls\_db\_set\_ptr()}{gnutls\_db\_set\_ptr() (see Section }{)}
{gnutls_db_set_ptr}
\end{itemize}
These callback functions are required in order to use a session
storage method, other than the default gdbm backend.
\par
If an alternative backend is in use, it might be usefull to be able to check
for expired sessions in order to remove them, and save space. This is what
\hyperref{gnutls\_db\_clean()}{gnutls\_db\_clean() (see Section }{)}
{gnutls_db_clean} does for the gdbm backend.
\gnutls{} provides the function
\hyperref{gnutls\_db\_check\_entry()}{gnutls\_db\_check\_entry() (see Section }{)
}{gnutls_db_check_entry}, which takes as input session data, and
returns a negative value if the data are to be removed.
|
