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 |