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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
\chapter{How to use \tls{} in application protocols}
\label{apps}
\section{Introduction}
This chapter is intended to provide some hints on how to use the \tls{}
over simple custom made application protocols.
The discussion below mainly refers to the \emph{TCP/IP} transport layer
but may be extended to other ones too.
\section{The traditional way}
Traditionally \ssl{} was used in application protocols by assigning
a new port number for the secure services. That way two ports were assigned, one for the
non secure sessions, and one for the secured ones. This has the benefit
that if a user requests a secure session then the client will try to
connect to the secure port and fail otherwise. The only possible attack
with this method is a denial of service one. The most famous
example of this method is the famous ``HTTP over TLS'' or HTTPS\footnote{RFC2818}
protocol.
\par
Despite its wide use, this method is not as good as it seems.
This approach starts the \tls{} Handshake procedure just after the
client connects on the --so called-- secure port.
That way the \tls{} protocol does not know anything
about the client, and popular methods like the host advertising in
HTTP do not work. There is no way for the client to say ``I connected
to YYY server'' before the Handshake starts, so the server cannot
possibly know which certificate to use\footnote{There is some effort to solve
this problem within \tls{}}.
\par
Other than that it requires two separate ports to run a single service, which is
unnecessary complication. Due to the fact that there is a limitation on
the available privileged ports, this approach was soon obsoleted.
\section{A different approach}
Other application protocols\footnote{See LDAP, IMAP etc.}
use a different approach to enable the secure layer.
They use something called the ``TLS upgrade'' method. This method
is quite tricky but it is more flexible. The idea is to extend
the application protocol to have a ``STARTTLS'' request, whose purpose
it to start the TLS protocols just after the client requests it.
This is a really neat idea and does not require an extra port.
\par
The tricky part is that the ``STARTTLS'' request is sent in the clear,
thus is vulnerable to modifications. A typical attack is to modify the
messages in a way that the client is fooled and thinks that the server
does not have the ``STARTTLS'' capability. See a typical conversation
of a hypothetical protocol:
\begin{verbatim}
(client connects to the server)
CLIENT: HELLO I'M MR. XXX
SERVER: NICE TO MEET YOU XXX
CLIENT: PLEASE START TLS
SERVER: OK
*** TLS STARTS
CLIENT: HERE ARE SOME CONFIDENTIAL DATA
\end{verbatim}
And see an example of a conversation where someone is acting
in between:
\begin{verbatim}
(client connects to the server)
CLIENT: HELLO I'M MR. XXX
SERVER: NICE TO MEET YOU XXX
CLIENT: PLEASE START TLS
(here someone inserts this message)
SERVER: SORRY I DON'T HAVE THIS CAPABILITY
CLIENT: HERE ARE SOME CONFIDENTIAL DATA
\end{verbatim}
As you can see above the client was fooled, and was dummy enough
to send the confidential data in the clear.
\par
How to avoid the above attack? As you may have already thought
this one is easy to avoid. The client has to ask the user before it connects
whether the user requests \tls{} or not. If the user answered that he
certainly wants the secure layer the last conversation should be:
\begin{verbatim}
(client connects to the server)
CLIENT: HELLO I'M MR. XXX
SERVER: NICE TO MEET YOU XXX
CLIENT: PLEASE START TLS
(here someone inserts this message)
SERVER: SORRY I DON'T HAVE THIS CAPABILITY
CLIENT: BYE
(the client notifies the user that the secure connection was not possible)
\end{verbatim}
\par
This method, if implemented properly, is far better than the
traditional method, and the security properties remain the same, since only
denial of service is possible. The benefit is the server may request
additional data before the \tls{} Handshake protocol
starts, in order to send the correct certificate, use the correct
password file\footnote{in SRP authentication}, or anything else!
|
