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,
|
|
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>
|