View | Details | Raw Unified | Return to bug 58891
Collapse All | Expand All

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

Return to bug 58891