@subsection Two peers with an out-of-band channel
-Let's consider two peers need to communicate over an untrusted channel
+Let's consider two peers who need to communicate over an untrusted channel
(the Internet), but have an out-of-band channel available. The latter
channel is considered safe from eavesdropping and message modification and thus
can be used for an initial bootstrapping of the protocol. The options
channel and use it to negotiate further sessions over the untrusted channel.
@item Passwords (see @ref{SRP authentication}). The client communicates
-to the server his username and password of choice and uses it to
+to the server its username and password of choice and uses it to
negotiate further sessions over the untrusted channel.
@item Public keys (see @ref{Certificate authentication}). The client
available options are:
@itemize
@item Passwords (see @ref{SRP authentication}). The client communicates
-to the server his username and password of choice on the initial
+to the server its username and password of choice on the initial
server-authenticated connection and uses it to negotiate further sessions.
This is possible because the SRP protocol allows for the server to be
authenticated using a certificate and the client using the
identified @xcite{RIVESTCRL}.
The Online Certificate Status Protocol, or @acronym{OCSP} @xcite{RFC2560},
-is a widely implemented protocol to perform certificate revocation status
+is a widely implemented protocol which performs certificate revocation status
checking. An application that wish to verify the
identity of a peer will verify the certificate against a set of
trusted certificates and then check whether the certificate is listed
in a CRL and/or perform an OCSP check for the certificate.
Note that in the context of a TLS session the server may provide an
-OCSP response that will used during the TLS certificate verification
+OCSP response that will be used during the TLS certificate verification
(see @funcref{gnutls_certificate_verify_peers2}).
You may obtain this response using @funcref{gnutls_ocsp_status_request_get}.
There are several functions in GnuTLS for creating and manipulating
OCSP requests and responses. The general idea is that a client
-application create an OCSP request object, store some information
-about the certificate to check in the request, and then export the
+application creates an OCSP request object, stores some information
+about the certificate to check in the request, and then exports the
request in DER format. The request will then need to be sent to the
OCSP responder, which needs to be done by the application (GnuTLS does
not send and receive OCSP packets). Normally an OCSP response is
@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.
@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
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
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
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
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:
projects / thirdparty / gnutls.git / commitdiff
