Mercurial > hg > nginx-site

comparison xml/it/docs/http/configuring_https_servers.xml @ 1018:19129672444e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Added italian translation. Grazie a Angelo Papadia <angelo.papadia@gmail.com>!
author Vladimir Homutov <vl@nginx.com>
date Wed, 20 Nov 2013 14:36:40 +0400
parents
children 6303d4e343a8
comparison
equal deleted inserted replaced
1017:9f9a427a73eb 1018:19129672444e
1 <!--
2 Copyright (C) Igor Sysoev
3 Copyright (C) Nginx, Inc.
4 -->
5
6 <!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
7
8 <article name="Configurazione di server HTTPS"
9 link="/it/docs/http/configuring_https_servers.html"
10 lang="it"
11 translator="Angelo Papadia"
12 rev="6"
13 author="Igor Sysoev"
14 editor="Brian Mercer">
15
16 <section>
17
18 <para>
19 Per configurare un server HTTPS, bisogna configurare il parametro
20 <literal>ssl</literal> nel
21 <link doc="ngx_http_core_module.xml" id="listen">socket in ascolto</link>
22 del blocco <link doc="ngx_http_core_module.xml" id="server"/>,
23 e specificare dove sono i file del certificato del server e della relativa
24 chiave private:
25
26 <programlisting>
27 server {
28 listen 443 <b>ssl</b>;
29 server_name www.example.com;
30 ssl_certificate <b>www.example.com.crt</b>;
31 ssl_certificate_key <b>www.example.com.key</b>;
32 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
33 ssl_ciphers HIGH:!aNULL:!MD5;
34 ...
35 }
36 </programlisting>
37
38 Il certificato del server e' pubblico: e' inviato a tutti i client che
39 si connettono al server; la chiave privata al contrario non e' pubblica,
40 e dovrebbe essere salvata in un file con restrizioni d'accesso, e
41 comunque non leggibile dal processo master di nginx.
42 In alternativa, la chiave privata puo' essere salvata nel medesimo file
43 del certificato:
44
45 <programlisting>
46 ssl_certificate www.example.com.cert;
47 ssl_certificate_key www.example.com.cert;
48 </programlisting>
49
50 pure in questo caso i diritti d'accesso al file dovrebbero essere ristretti.
51 Anche quando certificato e chiave privata sono salvati entrambi
52 in un unico file, solo il certificato e' inviato al client.
53 </para>
54
55 <para>
56 Le direttive <link doc="ngx_http_ssl_module.xml" id="ssl_protocols"/> e
57 <link doc="ngx_http_ssl_module.xml" id="ssl_ciphers"/> possono essere usate
58 per limitare l'uso alle sole versioni e cifrature forti di SSL/TLS nelle
59 connessioni.
60 nginx usa per default “<literal>ssl_protocols SSLv3 TLSv1</literal>” e
61 “<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>” sin dalla versione 1.0.5,
62 per cui una configurazione esplicita ha senso solo per le versioni di ngnix
63 piu' vecchie. Dalle versioni 1.1.13 e 1.0.12 nginx usa per default
64 “<literal>ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2</literal>”.
65 </para>
66
67 <para>
68 La modalita' di cifratura CBC e' potenzialmente vulnerabile ad una serie
69 di attacchi, in particolare ad un attacco BEST (vedi
70 <link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>).
71 La configurazione della cifratura puo' essere modificata in maniera da
72 utilizzare RC4-SHA:
73
74 <programlisting>
75 ssl_ciphers RC4:HIGH:!aNULL:!MD5;
76 ssl_prefer_server_ciphers on;
77 </programlisting>
78 </para>
79
80 </section>
81
82
83 <section id="optimization" name="Ottimizzazione di server HTTPS">
84
85 <para>
86 Le operazioni SSL utilizzano pesantemente la CPU. Su sistemi
87 multiprocessore e' bene avviare processi worker in numero almeno pari a
88 quello dei core.
89 L'operazione piu' gravosa per la CPU e' l'handshake SSL.
90 Ci sono due modi per minimizzare il numero di tali operazioni per client:
91 il primo consiste nell'abilitare connessioni keepalive per inviare diverse
92 richieste tramite un'unica connessione; il secondo prevede di riutilizzare
93 i parametri della sessione SSL in maniera tale da evitare l'handshake SSL
94 per connessioni parallele e susseguenti.
95 Le sessioni sono salvate in una cache di sessione SSL, condivisa fra i
96 worker e configurata dalla direttiva
97 <link doc="ngx_http_ssl_module.xml" id="ssl_session_cache"/>.
98
99 Un megabyte di cache contiene circa 4000 sessioni. Il timeout di default della
100 cache e' di 5 minuti; puo' essere aumentato intervenendo sulla direttiva
101 <link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/>.
102 Segue una configurazione di esempio ottimizzata per un sistema multicore con
103 10 megabyte di cache di sessione condivisa:
104
105 <programlisting>
106 <b>worker_processes auto</b>;
107
108 http {
109 <b>ssl_session_cache shared:SSL:10m</b>;
110 <b>ssl_session_timeout 10m</b>;
111
112 server {
113 listen 443 ssl;
114 server_name www.example.com;
115 <b>keepalive_timeout 70</b>;
116
117 ssl_certificate www.example.com.crt;
118 ssl_certificate_key www.example.com.key;
119 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
120 ssl_ciphers HIGH:!aNULL:!MD5;
121 ...
122 </programlisting>
123 </para>
124
125 </section>
126
127
128 <section id="chains" name="Catene di certificati SSL">
129
130 <para>
131 Capita talvolta che alcuni certificati server firmati da autorita' di
132 certificazione ben note siano tranquillamente accettati da alcuni browser,
133 ma mostrino invece problemi con altri. Cio' succede quando' l'autorita'
134 emittente ha firmato il certificato usandone uno intermedio che non e'
135 presente nell'elenco delle autorita' di certificazione distribuito con
136 uno specifico browser.
137 In tal caso l'autorita' fornisce un gruppo di certificati che dovrebbero
138 essere concatenati al certificato server firmato.
139 Il certificato server deve comparire prima dei certificati concatenati
140 nel file risultante:
141
142 <programlisting>
143 $ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
144 </programlisting>
145
146 Il file che ne deriva va usato con la direttiva
147 <link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/>:
148
149 <programlisting>
150 server {
151 listen 443 ssl;
152 server_name www.example.com;
153 ssl_certificate www.example.com.chained.crt;
154 ssl_certificate_key www.example.com.key;
155 ...
156 }
157 </programlisting>
158
159 Se il certificato server ed il gruppo di certificati sono stati concatenati
160 nell'ordine sbagliato, nginx non riuscira' a partire e mostrera' il
161 seguente messaggio di errore:
162
163 <programlisting>
164 SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
165 (SSL: error:0B080074:x509 certificate routines:
166 X509_check_private_key:key values mismatch)
167 </programlisting>
168
169 dato che nginx ha tentato di usare la chiave privata non con il certificato
170 server ma con il primo certificato del gruppo.
171 </para>
172
173 <para>
174 Di solito i browser salvano i certificati intermedi che ricevono se sono
175 firmati da autorita' di certificazione riconosciute, per cui browser molto
176 usati potrebbero gia' avere i certificati intermedi richiesti, e quindi
177 non avere problemi anche quando ricevono un certificato privo della
178 relativa concatenazione di certificati.
179 Comunque, per assicurare che il server invii la concatenazione di certificati
180 completa, e' possibile usare da linea di comando il programma
181 <command>openssl</command>, ad esempio:
182
183 <programlisting>
184 $ openssl s_client -connect www.godaddy.com:443
185 ...
186 Certificate chain
187 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
188 /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
189 /OU=MIS Department/<b>CN=www.GoDaddy.com</b>
190 /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
191 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
192 /OU=http://certificates.godaddy.com/repository
193 /CN=Go Daddy Secure Certification Authority
194 /serialNumber=07969287
195 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
196 /OU=http://certificates.godaddy.com/repository
197 /CN=Go Daddy Secure Certification Authority
198 /serialNumber=07969287
199 i:/C=US/O=The Go Daddy Group, Inc.
200 /OU=Go Daddy Class 2 Certification Authority
201 2 s:/C=US/O=The Go Daddy Group, Inc.
202 /OU=Go Daddy Class 2 Certification Authority
203 i:/L=ValiCert Validation Network/O=<b>ValiCert, Inc.</b>
204 /OU=ValiCert Class 2 Policy Validation Authority
205 /CN=http://www.valicert.com//emailAddress=info@valicert.com
206 ...
207 </programlisting>
208
209 In questo esempio, il soggetto (“<i>s</i>”, vale a dire "<i>subject</i>")
210 del certificato server #0 <literal>www.GoDaddy.com</literal> e' firmato da
211 un emittente (“<i>i</i>”, vale a dire "<i>issuer</i>") che a sua volta e'
212 il soggetto del certificato #1, il quale e' firmato da un emittente che e'
213 il soggetto del certificato #2, che e' finalmente firmato dalla autorita'
214 di certificazione ben nota <i>ValiCert, Inc.</i>, il cui certificato e'
215 presente nella base dati precaricata del browser
216 ("che al mercato mio padre compro'").
217 </para>
218
219 <para>
220 Se il gruppo di certificati non fosse stato aggiunto, sarebbe stato
221 visualizzato il solo certificato #0.
222 </para>
223
224 </section>
225
226
227 <section id="single_http_https_server" name="Un server unico per HTTP e HTTPS">
228
229 <para>
230 E' possibile configurare un singolo server che tratti sia richieste HTTP,
231 sia richieste HTTPS:
232
233 <programlisting>
234 server {
235 listen 80;
236 listen 443 ssl;
237 server_name www.example.com;
238 ssl_certificate www.example.com.crt;
239 ssl_certificate_key www.example.com.key;
240 ...
241 }
242 </programlisting>
243
244 <note>
245 Prima della versione 0.7.14, SSL non poteva essere abilitato
246 selettivamente per singoli socket in ascolto, come nell'esempio
247 precedente: SSL poteva solo essere abilitato per l'intero server,
248 usando la direttiva <link doc="ngx_http_ssl_module.xml" id="ssl"/>,
249 e rendendo quindi impossibile la configurazione di un server
250 unico per HTTP e HTTPS.
251 Il parametro <literal>ssl</literal> della direttiva
252 <link doc="ngx_http_core_module.xml" id="listen"/> e' stato aggiunto
253 per risolvere questo problema. L'uso della direttiva
254 <link doc="ngx_http_ssl_module.xml" id="ssl"/>
255 e' pertanto sconsigliato nelle versioni recenti.
256 </note>
257 </para>
258
259 </section>
260
261
262 <section id="name_based_https_servers" name="Server HTTPS name-based">
263
264 <para>
265 Quando si configurano due o piu' server HTTPS in ascolto su un singolo
266 indirizzo IP, sorge spesso un problema:
267
268 <programlisting>
269 server {
270 listen 443 ssl;
271 server_name www.example.com;
272 ssl_certificate www.example.com.crt;
273 ...
274 }
275
276 server {
277 listen 443 ssl;
278 server_name www.example.org;
279 ssl_certificate www.example.org.crt;
280 ...
281 }
282 </programlisting>
283
284 Con questa configurazione un browser riceve il certificato del server di default,
285 vale a dire <literal>www.example.com</literal>, indipendentemente da quale sia
286 il nome del server richiesto. Cio' e' causato dal comportamento del protocollo
287 SSL: la connessione SSL si stabilisce prima che il browser invii una richiesta
288 HTTP, percio' quando nginx ancora non sa quale sara' il nome del server richiesto;
289 per tale ragione, non puo' fare altro che offrire il certificato del server di default.
290 </para>
291
292 <para>
293 Il metodo classico per risolvere questo problema consiste nell'assegnare
294 un indirizzo IP distinto a ciascun server HTTPS:
295
296 <programlisting>
297 server {
298 listen 192.168.1.1:443 ssl;
299 server_name www.example.com;
300 ssl_certificate www.example.com.crt;
301 ...
302 }
303
304 server {
305 listen 192.168.1.2:443 ssl;
306 server_name www.example.org;
307 ssl_certificate www.example.org.crt;
308 ...
309 }
310 </programlisting>
311 </para>
312
313
314 <section id="certificate_with_several_names"
315 name="Un certificato SSL con molti nomi">
316
317 <para>
318 Ci sono altre maniere tramite cui condividere un singolo indirizzo IP
319 fra molti server HTTPS, tutte comunque non prive di problemi.
320 Ad esempio, e' possibile usare un certificato con diversi nomi di server
321 nel campo SubjectAltName, per esempio
322 <literal>www.example.com</literal> and <literal>www.example.org</literal>,
323 tuttavia la lunghezza del campo SubjectAltName e' limitata.
324 </para>
325
326 <para>
327 Un'altra tecnica prevede l'uso di un certificato il cui nome e' definito con
328 caratteri jolly, per esempio <literal>*.example.org</literal>.
329 Un certificato con caratteri jolly va bene per tutti i sottodomini del
330 dominio specificato, ma per un solo livello: in questo caso ad esempio
331 verra' riconosciuta corrispondenza con <literal>www.example.org</literal>,
332 ma non con <literal>example.org</literal> e <literal>www.sub.example.org</literal>.
333 I due metodi mostrati possono essere combinati: nel campo SubjectAltName
334 un certificato puo' contenere sia nomi esatti sia nomi con caratteri jolly,
335 ad esempio <literal>example.org</literal> e <literal>*.example.org</literal>.
336 </para>
337
338 <para>
339 Nel caso in cui si usi un certificato con nomi multipli, e' bene
340 indicare la posizione del relativo file e della chiave nel livello
341 <i>http</i> della configurazione, in maniera da avere una singola
342 copia in memoria da far ereditare a tutti i server:
343
344 <programlisting>
345 ssl_certificate common.crt;
346 ssl_certificate_key common.key;
347
348 server {
349 listen 443 ssl;
350 server_name www.example.com;
351 ...
352 }
353
354 server {
355 listen 443 ssl;
356 server_name www.example.org;
357 ...
358 }
359 </programlisting>
360 </para>
361
362 </section>
363
364
365 <section id="sni" name="Server Name Indication">
366
367 <para>
368 Una soluzione piu' generale per l'uso di server HTTPS multipli su un singolo
369 indirizzo IP e' data dalla
370 <link url="http://en.wikipedia.org/wiki/Server_Name_Indication">estensione
371 TLS Server Name Indication</link> (SNI, RFC 6066), che consente ad un
372 browser di indicare il nome del server richiesto durante l'handshake SSL e,
373 percio', permette al server di sapere quale certificato dovrebbe essere
374 usato durante la connessione. Purtroppo, SNI ha un supporto piuttosto
375 limitato nei browser; al momento e' supportato a partire dalle seguenti
376 versioni:
377 </para>
378
379 <para>
380 <list type="bullet">
381
382 <listitem>
383 Opera 8.0;
384 </listitem>
385
386 <listitem>
387 MSIE 7.0 (ma solo su Windows Vista o superiore);
388 </listitem>
389
390 <listitem>
391 Firefox 2.0 e altri browser che usano Mozilla Platform rv:1.8.1;
392 </listitem>
393
394 <listitem>
395 Safari 3.2.1 (la versione per Windows supporta SNI su Vista o superiore);
396 </listitem>
397
398 <listitem>
399 Chrome (la versione per Windows supporta SNI su Vista o superiore).
400 </listitem>
401
402 </list>
403 <note>
404 Con SNI e' possibile passare solo nomi di dominio, tuttavia alcuni browser
405 potrebbero erroneamente consentire di passare come nome anche l'indirizzo
406 IP del server.
407 E' bene comunque non fare affidamento su questo comportamento.
408 </note>
409 </para>
410
411 <para>
412 Per poter usare SNI in nginx, e' necessario che sia supportato sia nella
413 libreria OpenSSL con cui il binario e' stato compilato, sia nella
414 libreria a cui e' linkato dinamicamente in esecuzione.
415 OpenSSL supporta SNI sin dalla versione 0.9.8f, a patto che sia stata
416 compilata con l'opzione di configurazione <nobr>“--enable-tlsext”</nobr>;
417 dalla versione 0.9.8j tale opzione e' abilitata per default.
418 Se nginx e' compilato con il supporto a SNI, allora l'esecuzione con
419 il parametro “-V” mostra:
420
421 <programlisting>
422 $ nginx -V
423 ...
424 TLS SNI support enabled
425 ...
426 </programlisting>
427
428 Di contro, se nginx e' stato compilato con il supporto a SNI, ma la libreria
429 OpenSSL a cui e' linkato dinamicamente ne e' priva, viene mostrato:
430
431 <programlisting>
432 nginx was built with SNI support, however, now it is linked
433 dynamically to an OpenSSL library which has no tlsext support,
434 therefore SNI is not available
435 </programlisting>
436 </para>
437
438 </section>
439
440 </section>
441
442
443 <section id="compatibility" name="Compatibilita'">
444
445 <para>
446 <list type="bullet">
447
448 <listitem>
449 Il parametro “-V” mostra lo stato del supporto a SNI
450 dalla versione 0.8.21 e 0.7.62 in poi.
451 </listitem>
452
453 <listitem>
454 Il parametro <literal>ssl</literal> della direttiva
455 <link doc="ngx_http_core_module.xml" id="listen"/>
456 e' supportato
457 dalla versione 0.7.14 in poi;
458 prima della versione 0.8.21 poteva essere specificato solo
459 insieme al parametro <literal>default</literal>.
460 </listitem>
461
462 <listitem>
463 SNI e' supportato
464 dalla versione 0.5.32 in poi.
465 </listitem>
466
467 <listitem>
468 La cache condivisa di sessione SSL e' supportata
469 dalla versione 0.5.6 in poi.
470 </listitem>
471
472 </list>
473 </para>
474
475 <para>
476 <list type="bullet">
477
478 <listitem>
479 Versioni 0.7.65, 0.8.19 e successive: i protocolli SSL default sono SSLv2, TLSv1,
480 e TLSv1.2 (se supportati dalla libreria OpenSSL).
481 </listitem>
482
483 <listitem>
484 Versioni 0.7.64, 0.8.18 e precedenti: i protocolli SSL default sono SSLv2,
485 SSLv3, e TLSv1.
486 </listitem>
487
488 </list>
489 </para>
490
491 <para>
492 <list type="bullet">
493
494 <listitem>
495 Versioni 1.0.5 e successive: i sistemi di cifratura SSL default sono
496 “<literal>HIGH:!aNULL:!MD5</literal>”.
497 </listitem>
498
499 <listitem>
500 Versioni 0.7.65, 0.8.20 e successive: i sistemi di cifratura SSL default sono
501 “<literal>HIGH:!ADH:!MD5</literal>”.
502 </listitem>
503
504 <listitem>
505 Versione 0.8.19: i sistemi di cifratura SSL default sono
506 “<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM</literal>”.
507 </listitem>
508
509 <listitem>
510 Versioni 0.7.64, 0.8.18 e precedenti: i sistemi di cifratura SSL default sono<br/>
511 “<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</literal>”.
512 </listitem>
513
514 </list>
515 </para>
516
517
518 </section>
519
520
521 </article>