diff options
Diffstat (limited to 'doc/sec-tls-app.texi')
| -rw-r--r-- | doc/sec-tls-app.texi | 37 |
1 files changed, 19 insertions, 18 deletions
diff --git a/doc/sec-tls-app.texi b/doc/sec-tls-app.texi index 89a10e7039..a67207dde3 100644 --- a/doc/sec-tls-app.texi +++ b/doc/sec-tls-app.texi @@ -1,7 +1,7 @@ @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 the +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. @@ -15,15 +15,15 @@ but may be extended to other ones too. @subsection Separate ports Traditionally @acronym{SSL} was used in application protocols by -assigning a new port number for the secure services. That way two -separate ports were assigned, one for the non secure sessions, and one -for the secured ones. This has the benefit that if a user requests a -secure session then the client will try to connect to the secure port -and fail otherwise. The only possible attack with this method is a -denial of service one. The most famous example of this method is the -famous ``HTTP over TLS'' or @acronym{HTTPS} protocol @xcite{RFC2818}. - -Despite its wide use, this method is not as good as it seems. This +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 @@ -36,7 +36,7 @@ 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 obsoleted. +soon deprecated in favor of upward negotiation. @node Upward negotiation @subsection Upward negotiation @@ -49,7 +49,7 @@ 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 -that method @xcite{RFC2817}. +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 @@ -73,7 +73,7 @@ SERVER: OK CLIENT: HERE ARE SOME CONFIDENTIAL DATA @end quotation -And see an example of a conversation where someone is acting +And an example of a conversation where someone is acting in between: @quotation @@ -92,12 +92,13 @@ 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 dummy enough to -send the confidential data in the clear. +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 to avoid the above attack? As you may have already noticed this -one 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 +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: |