blob: 9c6805fc90e7f12df2150046c9d6741dec2e6cd4 (
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
|
\subsection{TLS cipher suites}
\par
The Handshake Protocol of \tlsI{} negotiates cipher suites
of the form \\
{\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 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.
\end{itemize}
The cipher suite negotiated in the handshake protocol will affect
the Record Protocol, by enabling encryption and data authentication.
Note that you should not over rely on \tls{} to negotiate the strongest
available cipher suite. Do not enable ciphers and algorithms that you consider weak.
\par
The priority functions, dicussed above, allow the application layer to enable
and set priorities on the individual ciphers. It may imply that all combinations of ciphersuites
are allowed, but this is not true. For several reasons, not discussed here, some combinations
were not defined in the \tls{} protocol.
\gnutls{} may even decide to remove some of the valid ones. This behaviour depends on the
key parameters. For example keys marked as sign-only, will not be able to
access the plain RSA ciphersuites, but only the DHE\_RSA ones.
\addvspace{1.5cm}
|
