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
|
\section{Resuming Sessions}
\par
The
\hyperref{gnutls\_handshake()}{gnutls\_handshake() (see Section }{)}{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).
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 \hyperref{gnutls\_session\_get\_data()}
{gnutls\_session\_get\_data() on section }{}{gnutls_session_get_data},
\hyperref{gnutls\_session\_get\_id()}
{gnutls\_session\_get\_id() on section }{}{gnutls_session_get_id} and
\hyperref{gnutls\_session\_set\_data()}
{gnutls\_session\_set\_data() on section }{}{gnutls_session_set_data}.
\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
\gnutls{} also provides callback functions such as:
\hyperref{gnutls\_db\_set\_remove\_function()}{gnutls\_db\_set\_remove\_function() (see Section }{)}
{gnutls_db_set_remove_function},
\hyperref{gnutls\_db\_set\_store\_function()}{gnutls\_db\_set\_store\_function() (see Section }{)}
{gnutls_db_set_store_function},
\hyperref{gnutls\_db\_set\_retrieve\_function()}{gnutls\_db\_set\_retrieve\_function() (see Section }{)
}{gnutls_db_set_retrieve_function} and
\hyperref{gnutls\_db\_set\_ptr()}{gnutls\_db\_set\_ptr() (see Section }{)}
{gnutls_db_set_ptr}.
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.
|
