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 the
   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. 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}.
  25
  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.
  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 obsoleted.
  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 that 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 see 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 dummy enough to
  96 send the confidential data in the clear.
  97
  98 How to avoid the above attack? As you may have already noticed this
  99 one is easy to avoid. The client has to ask the user before it
 100 connects whether the user requests @acronym{TLS} or not. If the user
 101 answered that he certainly wants the secure layer the last
 102 conversation should be:
 103
 104 @quotation
 105 (client connects to the server)
 106
 107 CLIENT: HELLO I'M MR. XXX
 108
 109 SERVER: NICE TO MEET YOU XXX
 110
 111 CLIENT: PLEASE START TLS
 112
 113 (here someone inserts this message)
 114
 115 SERVER: SORRY I DON'T HAVE THIS CAPABILITY
 116
 117 CLIENT: BYE
 118
 119 (the client notifies the user that the secure connection was not possible)
 120 @end quotation
 121
 122 This method, if implemented properly, is far better than the
 123 traditional method, and the security properties remain the same, since
 124 only denial of service is possible. The benefit is that the server may
 125 request additional data before the @acronym{TLS} Handshake protocol
 126 starts, in order to send the correct certificate, use the correct
 127 password file, or anything else!