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
|
This chapter is to give a brief description of the
way @acronym{GnuTLS} works. The focus is to give an idea
to potential developers and those who want to know what
happens inside the black box.
@section The TLS protocol
The main needs for the TLS protocol to be used are
shown in the image below.
@image{arch/client-server-use-case,9cm}
This is being accomplished by the following object diagram.
Note that since @acronym{GnuTLS} is being developed in C
object are just structures with attributes. The operations listed
are functions that require the first parameter to be that object.
@image{arch/objects,15cm}
@section TLS Handshake protocol
The @acronym{GnuTLS} handshake protocol is implemented as a state
machine that waits for input or returns immediately when the non-blocking
transport layer functions are used. The main idea is shown in the following
figure.
@image{arch/handshake-state,9cm}
Also the way the input is processed varies per ciphersuite. Several
implementations of the internal handlers are available and
@ref{gnutls_handshake} only multiplexes the input to the appropriate
handler. For example a @acronym{PSK} ciphersuite has a different
implementation of the @code{process_client_key_exchange} than a
certificate ciphersuite.
@image{arch/handshake-sequence,12cm}
@section TLS authentication methods
In @acronym{GnuTLS} authentication methods can be implemented quite easily.
Since the required changes to add a new authentication method affect only the
handshake protocol, a simple interface is used. An authentication method needs
only to implement the functions as seen in the figure below.
@image{arch/mod_auth_st,12cm}
The functions that need to be implemented are the ones responsible for interpreting
the handshake protocol messages. It is common for such functions to read data from
one or more @code{credentials_t} structures@footnote{such as the @code{gnutls_certificate_credentials_t} structures} and write data, such as certificates, usernames etc. to @code{auth_info_t} structures.
Simple examples of existing authentication methods can be seen in @code{auth_psk.c}
for PSK ciphersuites and @code{auth_srp.c} for SRP ciphersuites. After implementing these functions
the structure holding its pointers has to be registered in @code{gnutls_algorithms.c}
in the @code{_gnutls_kx_algorithms} structure.
@section TLS Extension handling
As with authentication methods, the TLS extensions handlers can be implemented
using the following interface.
@image{arch/extensions_st,12cm}
Here there are two functions, one for receiving the extension data
and one for sending. These functions have to check internally whether
they operate in client or server side.
A simple example of an extension handler can be seen in @code{ext_srp.c}
After implementing these functions, together with the extension number they
handle, they have to be registered in @code{gnutls_extensions.c} in the
@code{_gnutls_extensions} structure.
@section Certificate handling
What is provided by the certificate handling functions
is summarized in the following diagram.
@image{arch/certificate-user-use-case,12cm}
|
