doc/sec-tls-app.texi

   1 @node How to use TLS in application protocols
   2 @section How to use @acronym{TLS} in application protocols
   3
   4 This chapter is intended to provide some hints on how to use
   5 @acronym{TLS} over simple custom made application protocols.  The
   6 discussion below mainly refers to the @acronym{TCP/IP} transport layer
   7 but may be extended to other ones too.
   8
   9 @menu
  10 * Separate ports::
  11 * Upward negotiation::
  12 @end menu
  13
  14 @node Separate ports
  15 @subsection Separate ports
  16
  17 Traditionally @acronym{SSL} was used in application protocols by
  18 assigning a new port number for the secure services. By doing this two
  19 separate ports were assigned, one for the non-secure sessions, and one
  20 for the secure sessions. This method ensures that if a user requests a
  21 secure session then the client will attempt to connect to the secure port
  22 and fail otherwise. The only possible attack with this method is to perform
  23 a denial of service attack. The most famous example of this method is
  24 ``HTTP over TLS'' or @acronym{HTTPS} protocol @xcite{RFC2818}.
  25
  26 Despite its wide use, this method has several issues. 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.
  35
  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
  39 soon deprecated in favor of upward negotiation.
  40
  41 @node Upward negotiation
  42 @subsection Upward negotiation
  43
  44 Other application protocols@footnote{See LDAP, IMAP etc.}  use a
  45 different approach to enable the secure layer.  They use something
  46 often called as 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 approach
  50 does not require any extra port to be reserved.
  51 There is even an extension to HTTP protocol to support
  52 this method @xcite{RFC2817}.
  53
  54 The tricky part, in this method, is that the ``STARTTLS'' request is
  55 sent in the clear, thus is vulnerable to modifications.  A typical
  56 attack is to modify the messages in a way that the client is fooled
  57 and thinks that the server does not have the ``STARTTLS'' capability.
  58 See a typical conversation of a hypothetical protocol:
  59
  60 @quotation
  61 (client connects to the server)
  62
  63 CLIENT: HELLO I'M MR. XXX
  64
  65 SERVER: NICE TO MEET YOU XXX
  66
  67 CLIENT: PLEASE START TLS
  68
  69 SERVER: OK
  70
  71 *** TLS STARTS
  72
  73 CLIENT: HERE ARE SOME CONFIDENTIAL DATA
  74 @end quotation
  75
  76 And an example of a conversation where someone is acting
  77 in between:
  78
  79 @quotation
  80 (client connects to the server)
  81
  82 CLIENT: HELLO I'M MR. XXX
  83
  84 SERVER: NICE TO MEET YOU XXX
  85
  86 CLIENT: PLEASE START TLS
  87
  88 (here someone inserts this message)
  89
  90 SERVER: SORRY I DON'T HAVE THIS CAPABILITY
  91
  92 CLIENT: HERE ARE SOME CONFIDENTIAL DATA
  93 @end quotation
  94
  95 As you can see above the client was fooled, and was na@"ive enough to
  96 send the confidential data in the clear, despite the server telling the
  97 client that it does not support ``STARTTLS''.
  98
  99 How do we avoid the above attack? As you may have already noticed this
 100 situation is easy to avoid.  The client has to ask the user before it
 101 connects whether the user requests @acronym{TLS} or not.  If the user
 102 answered that he certainly wants the secure layer the last
 103 conversation should be:
 104
 105 @quotation
 106 (client connects to the server)
 107
 108 CLIENT: HELLO I'M MR. XXX
 109
 110 SERVER: NICE TO MEET YOU XXX
 111
 112 CLIENT: PLEASE START TLS
 113
 114 (here someone inserts this message)
 115
 116 SERVER: SORRY I DON'T HAVE THIS CAPABILITY
 117
 118 CLIENT: BYE
 119
 120 (the client notifies the user that the secure connection was not possible)
 121 @end quotation
 122
 123 This method, if implemented properly, is far better than the
 124 traditional method, and the security properties remain the same, since
 125 only denial of service is possible. The benefit is that the server may
 126 request additional data before the @acronym{TLS} Handshake protocol
 127 starts, in order to send the correct certificate, use the correct
 128 password file, or anything else!