1
@node How to use TLS in application protocols
2
@chapter How To Use @acronym{TLS} in Application Protocols
4
This chapter is intended to provide some hints on how to use the
5
@acronym{TLS} over simple custom made application protocols. The
6
discussion below mainly refers to the @emph{TCP/IP} transport layer
7
but may be extended to other ones too.
11
* Upward negotiation::
15
@section Separate Ports
17
Traditionally @acronym{SSL} was used in application protocols by
18
assigning a new port number for the secure services. That way two
19
separate ports were assigned, one for the non secure sessions, and one
20
for the secured ones. This has the benefit that if a user requests a
21
secure session then the client will try to connect to the secure port
22
and fail otherwise. The only possible attack with this method is a
23
denial of service one. The most famous example of this method is the
24
famous ``HTTP over TLS'' or @acronym{HTTPS} protocol @xcite{RFC2818}.
26
Despite its wide use, this method is not as good as it seems. This
27
approach starts the @acronym{TLS} Handshake procedure just after the
28
client connects on the ---so called--- secure port. That way the
29
@acronym{TLS} protocol does not know anything about the client, and
30
popular methods like the host advertising in HTTP do not
31
work@footnote{See also the Server Name Indication extension on
32
@ref{serverind}.}. There is no way for the client to say ``I
33
connected to YYY server'' before the Handshake starts, so the server
34
cannot possibly know which certificate to use.
36
Other than that it requires two separate ports to run a single
37
service, which is unnecessary complication. Due to the fact that there
38
is a limitation on the available privileged ports, this approach was
41
@node Upward negotiation
42
@section Upward Negotiation
44
Other application protocols@footnote{See LDAP, IMAP etc.} use a
45
different approach to enable the secure layer. They use something
46
called the ``TLS upgrade'' method. This method is quite tricky but it
47
is more flexible. The idea is to extend the application protocol to
48
have a ``STARTTLS'' request, whose purpose it to start the TLS
49
protocols just after the client requests it. This is a really neat
50
idea and does not require an extra port.
52
This method is used by almost all modern protocols and there is even
53
the @xcite{RFC2817} paper which proposes extensions to HTTP to support
56
The tricky part, in this method, is that the ``STARTTLS'' request is
57
sent in the clear, thus is vulnerable to modifications. A typical
58
attack is to modify the messages in a way that the client is fooled
59
and thinks that the server does not have the ``STARTTLS'' capability.
60
See a typical conversation of a hypothetical protocol:
63
(client connects to the server)
65
CLIENT: HELLO I'M MR. XXX
67
SERVER: NICE TO MEET YOU XXX
69
CLIENT: PLEASE START TLS
75
CLIENT: HERE ARE SOME CONFIDENTIAL DATA
78
And see an example of a conversation where someone is acting
82
(client connects to the server)
84
CLIENT: HELLO I'M MR. XXX
86
SERVER: NICE TO MEET YOU XXX
88
CLIENT: PLEASE START TLS
90
(here someone inserts this message)
92
SERVER: SORRY I DON'T HAVE THIS CAPABILITY
94
CLIENT: HERE ARE SOME CONFIDENTIAL DATA
97
As you can see above the client was fooled, and was dummy enough to
98
send the confidential data in the clear.
100
How to avoid the above attack? As you may have already thought this
101
one is easy to avoid. The client has to ask the user before it
102
connects whether the user requests @acronym{TLS} or not. If the user
103
answered that he certainly wants the secure layer the last
104
conversation should be:
107
(client connects to the server)
109
CLIENT: HELLO I'M MR. XXX
111
SERVER: NICE TO MEET YOU XXX
113
CLIENT: PLEASE START TLS
115
(here someone inserts this message)
117
SERVER: SORRY I DON'T HAVE THIS CAPABILITY
121
(the client notifies the user that the secure connection was not possible)
124
This method, if implemented properly, is far better than the
125
traditional method, and the security properties remain the same, since
126
only denial of service is possible. The benefit is that the server may
127
request additional data before the @acronym{TLS} Handshake protocol
128
starts, in order to send the correct certificate, use the correct
129
password file@footnote{in @acronym{SRP} authentication}, or anything
added
removed
doc/cha-tls-app.texi
