Attachment 33465 Details for Bug 58891 – improve SSL/TLS documentation

[patch] improve SSL/TLS documentation

tomcat-ssl-documentation.patch (text/plain), 6.77 KB, created by Alexander Kjäll on 2016-01-19 18:12:37 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Alexander Kjäll

Created: 2016-01-19 18:12:37 UTC

Size: 6.77 KB

patch

obsolete

>diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml
>index edb546d..58301d6 100644
>--- a/webapps/docs/ssl-howto.xml
>+++ b/webapps/docs/ssl-howto.xml
>@@ -112,67 +112,47 @@ The theory behind this design is that a server should provide some kind of
> reasonable assurance that its owner is who you think it is, particularly
> before receiving any sensitive information. While a broader explanation of
> Certificates is beyond the scope of this document, think of a Certificate
>-as a "digital driver's license" for an Internet address. It states what
>-company the site is associated with, along with some basic contact
>-information about the site owner or administrator.
>-
>-This "driver's license" is cryptographically signed by its owner, and is
>-therefore extremely difficult for anyone else to forge. For sites involved
>-in e-commerce, or any other business transaction in which authentication of
>-identity is important, a Certificate is typically purchased from a well-known
>-Certificate Authority (CA) such as VeriSign or Thawte. Such
>-certificates can be electronically verified -- in effect, the Certificate
>-Authority will vouch for the authenticity of the certificates that it grants,
>-so you can believe that the Certificate is valid if you trust the Certificate
>-Authority that granted it.
>-
>-In many cases, however, authentication is not really a concern. An
>-administrator may simply want to ensure that the data being transmitted and
>-received by the server is private and cannot be snooped by anyone who may be
>-eavesdropping on the connection. Fortunately, Java provides a relatively
>-simple command-line tool, called <code>keytool</code>, which can easily create
>-a "self-signed" Certificate. Self-signed Certificates are simply user
>-generated Certificates which have not been officially registered with any
>-well-known CA, and are therefore not really guaranteed to be authentic at all.
>-Again, this may or may not even be important, depending on your needs.
>+as a security guarantee for an Internet domain. It lets the visitors
>+of your website verify that the content actually originated from your
>+servers, and didn't get modified by an attacker on the way.
>+
>+This certificate is cryptographically signed by its owner, and is
>+therefore extremely difficult for anyone else to forge. In order to for the
>+certificate to work in the visitors browsers without warnings it needs
>+to signed by a trusted third party, those are called Certificate Authorities (CA).
>+In order to obtain a signed certificate, you need to follow the instructions
>+of your CA. One good suggestion is to use Lets Encrypt as your CA, as they
>+don't charge money and lets you automate the retrieval of certificates.
>+
>+Java provides a relatively simple command-line tool, called
>+<code>keytool</code>, which can easily create a "self-signed" Certificate.
>+Self-signed Certificates are simply user generated Certificates which have not
>+been officially registered with any well-known CA, and are therefore not really
>+guaranteed to be authentic at all. In normal operations, this kind of certificate
>+shouldn't be used.
> 
> </section>
> 
>-<section name="General Tips on Running SSL">
>-
>-The first time a user attempts to access a secured page on your site,
>-he or she is typically presented with a dialog containing the details of
>-the certificate (such as the company and contact name), and asked if he or she
>-wishes to accept the Certificate as valid and continue with the transaction.
>-Some browsers will provide an option for permanently accepting a given
>-Certificate as valid, in which case the user will not be bothered with a
>-prompt each time they visit your site. Other browsers do not provide this
>-option. Once approved by the user, a Certificate will be considered valid
>-for at least the entire browser session.
>-
>-Also, while the SSL protocol was designed to be as efficient as securely
>-possible, encryption/decryption is a computationally expensive process from
>-a performance standpoint. It is not strictly necessary to run an entire
>-web application over SSL, and indeed a developer can pick and choose which
>-pages require a secure connection and which do not. For a reasonably busy
>-site, it is customary to only run certain pages under SSL, namely those
>-pages where sensitive information could possibly be exchanged. This would
>-include things like login pages, personal information pages, and shopping
>-cart checkouts, where credit card information could possibly be transmitted.
>-Any page within an application can be requested over a secure socket by
>-simply prefixing the address with <code>https:</code> instead of
>-<code>http:</code>. Any pages which absolutely require
>-a secure connection should check the protocol type associated with the
>-page request and take the appropriate action if <code>https</code> is not
>-specified.
>+<section name="General Tips on Running SSL/TLS">
>+
>+When securing a website with SSL it's important to make sure that
>+all assets that the site uses are distributed over SSL, so that an attacker
>+can't bypass the security by injecting malicious content in a javascript file
>+or similar. In order to further enhance the security of your website
>+you should evaluate to use the HSTS header, it allows you to communicate
>+to the browser that your site should always be accessed over https.
> 
> Finally, using name-based virtual hosts on a secured connection can be
>-problematic. This is a design limitation of the SSL protocol itself. The SSL
>-handshake, where the client browser accepts the server certificate, must occur
>-before the HTTP request is accessed. As a result, the request information
>-containing the virtual host name cannot be determined prior to authentication,
>-and it is therefore not possible to assign multiple certificates to a single
>-IP address. If all virtual hosts on a single IP address need to authenticate
>+problematic as java didn't support Server Name Indication (SNI) until java 8.
>+With only legacy SSL support, the SSL handshake, where the client browser
>+accepts the server certificate, must occur before the HTTP request is accessed.
>+As a result, the request information containing the virtual host name cannot
>+be determined prior to authentication, and it is therefore not possible to
>+assign multiple certificates to a single IP address. With SNI the hostname is
>+transmitted before the handshake is completed, and it's therefore possible
>+to have virtual hosts. SNI is implemented in tomcat 9, but not in tomcat 8.
>+
>+If all virtual hosts on a single IP address need to authenticate
> against the same certificate, the addition of multiple virtual hosts should not
> interfere with normal SSL operations on the server. Be aware, however, that
> most client browsers will compare the server's domain name against the domain

Actions: View | Diff

Attachments on bug 58891: 33465