Mercurial > hg > nginx-site
annotate xml/it/docs/http/configuring_https_servers.xml @ 1053:6303d4e343a8
Updated the Italian translation.
| author | Vladimir Homutov <vl@nginx.com> |
|---|---|
| date | Mon, 27 Jan 2014 19:25:54 +0400 |
| parents | 19129672444e |
| children |
| rev | line source |
|---|---|
| 1018 | 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, | |
|
1053
6303d4e343a8
Updated the Italian translation.
Vladimir Homutov <vl@nginx.com>
parents:
1018
diff
changeset
|
62 per cui una configurazione esplicita ha senso solo per le versioni di nginx |
| 1018 | 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> |