Adding upstream version 3.7.9.upstream/3.7.9upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 128 insertions, 0 deletions

diff --git a/doc/sec-tls-app.texi b/doc/sec-tls-app.texi
new file mode 100644
index 0000000..a67207d
--- /dev/null
+++ b/doc/sec-tls-app.texi
@@ -0,0 +1,128 @@
+@node How to use TLS in application protocols
+@section How to use @acronym{TLS} in application protocols
+
+This chapter is intended to provide some hints on how to use
+@acronym{TLS} over simple custom made application protocols.  The
+discussion below mainly refers to the @acronym{TCP/IP} transport layer
+but may be extended to other ones too.
+
+@menu
+* Separate ports::
+* Upward negotiation::
+@end menu
+
+@node Separate ports
+@subsection Separate ports
+
+Traditionally @acronym{SSL} was used in application protocols by
+assigning a new port number for the secure services. By doing this two
+separate ports were assigned, one for the non-secure sessions, and one
+for the secure sessions. This method ensures that if a user requests a
+secure session then the client will attempt to connect to the secure port
+and fail otherwise. The only possible attack with this method is to perform
+a denial of service attack. The most famous example of this method is
+``HTTP over TLS'' or @acronym{HTTPS} protocol @xcite{RFC2818}.
+
+Despite its wide use, this method has several issues. This
+approach starts the @acronym{TLS} Handshake procedure just after the
+client connects on the ---so called--- secure port.  That way the
+@acronym{TLS} protocol does not know anything about the client, and
+popular methods like the host advertising in HTTP do not
+work@footnote{See also the Server Name Indication extension on
+@ref{serverind}.}.  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.
+
+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 deprecated in favor of upward negotiation.
+
+@node Upward negotiation
+@subsection Upward negotiation
+
+Other application protocols@footnote{See LDAP, IMAP etc.}  use a
+different approach to enable the secure layer.  They use something
+often called as 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 approach
+does not require any extra port to be reserved.
+There is even an extension to HTTP protocol to support 
+this method @xcite{RFC2817}.
+
+The tricky part, in this method, 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:
+
+@quotation
+(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 quotation
+
+And an example of a conversation where someone is acting
+in between:
+
+@quotation
+(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 quotation
+
+As you can see above the client was fooled, and was na@"ive enough to
+send the confidential data in the clear, despite the server telling the
+client that it does not support ``STARTTLS''.
+
+How do we avoid the above attack? As you may have already noticed this
+situation is easy to avoid.  The client has to ask the user before it
+connects whether the user requests @acronym{TLS} or not.  If the user
+answered that he certainly wants the secure layer the last
+conversation should be:
+
+@quotation
+(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 quotation
+
+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 that the server may
+request additional data before the @acronym{TLS} Handshake protocol
+starts, in order to send the correct certificate, use the correct
+password file, or anything else!