doc/cha-tls-app.texi

   1 @node How to use TLS in application protocols
   2 @chapter 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 @emph{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 @section 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 @section 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 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.
  51
  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
  54 it.
  55
  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:
  61
  62 @quotation
  63 (client connects to the server)
  64
  65 CLIENT: HELLO I'M MR. XXX
  66
  67 SERVER: NICE TO MEET YOU XXX
  68
  69 CLIENT: PLEASE START TLS
  70
  71 SERVER: OK
  72
  73 *** TLS STARTS
  74
  75 CLIENT: HERE ARE SOME CONFIDENTIAL DATA
  76 @end quotation
  77
  78 And see an example of a conversation where someone is acting
  79 in between:
  80
  81 @quotation
  82 (client connects to the server)
  83
  84 CLIENT: HELLO I'M MR. XXX
  85
  86 SERVER: NICE TO MEET YOU XXX
  87
  88 CLIENT: PLEASE START TLS
  89
  90 (here someone inserts this message)
  91
  92 SERVER: SORRY I DON'T HAVE THIS CAPABILITY
  93
  94 CLIENT: HERE ARE SOME CONFIDENTIAL DATA
  95 @end quotation
  96
  97 As you can see above the client was fooled, and was dummy enough to
  98 send the confidential data in the clear.
  99
 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:
 105
 106 @quotation
 107 (client connects to the server)
 108
 109 CLIENT: HELLO I'M MR. XXX
 110
 111 SERVER: NICE TO MEET YOU XXX
 112
 113 CLIENT: PLEASE START TLS
 114
 115 (here someone inserts this message)
 116
 117 SERVER: SORRY I DON'T HAVE THIS CAPABILITY
 118
 119 CLIENT: BYE
 120
 121 (the client notifies the user that the secure connection was not possible)
 122 @end quotation
 123
 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
 130 else!