1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
|
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision: 1330881:1353828 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="ssl_howto.xml.meta">
<parentdocument href="./">SSL/TLS</parentdocument>
<title>Chiffrement fort SSL/TLS : Mode d'emploi</title>
<summary>
<p>Ce document doit vous permettre de démarrer et de faire fonctionner
une configuration de base. Avant de vous lancer dans l'application de
techniques avancées, il est fortement recommandé de lire le reste
de la documentation SSL afin d'en comprendre le fonctionnement de
manière plus approfondie.</p>
</summary>
<section id="configexample">
<title>Exemple de configuration basique</title>
<p>Votre configuration SSL doit comporter au moins les directives
suivantes :</p>
<highlight language="config">
Listen 443
<VirtualHost *:443>
ServerName www.example.com
SSLEngine on
SSLCertificateFile /path/to/www.example.com.cert
SSLCertificateKeyFile /path/to/www.example.com.key
</VirtualHost>
</highlight>
</section>
<section id="ciphersuites">
<title>Suites de chiffrement et mise en application de la sécurité
de haut niveau</title>
<ul>
<li><a href="#onlystrong">Comment créer un serveur SSL
qui n'accepte que le chiffrement fort ?</a></li>
<li><a href="#strongurl">Comment créer un serveur qui accepte tous les types de
chiffrement en général, mais exige un chiffrement fort pour pouvoir
accéder à une URL particulière ?</a></li>
</ul>
<section id="onlystrong">
<title>Comment créer un serveur SSL qui n'accepte
que le chiffrement fort ?</title>
<p>Les directives suivantes ne permettent que les
chiffrements de plus haut niveau :</p>
<highlight language="config">
SSLCipherSuite HIGH:!aNULL:!MD5
</highlight>
</section>
<p>Avec la configuration qui suit, vous indiquez une préférence pour
des algorityhmes de chiffrement spécifiques optimisés en matière de
rapidité (le choix final sera opéré par mod_ssl, dans la mesure ou le
client les supporte) :</p>
<highlight language="config">
SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
SSLHonorCipherOrder on
</highlight>
</section>
<section id="strongurl">
<title>Comment créer un serveur qui accepte tous les types de
chiffrement en général, mais exige un chiffrement fort pour pouvoir
accéder à une URL particulière ?</title>
<p>Dans ce cas bien évidemment, une directive <directive
module="mod_ssl">SSLCipherSuite</directive> au niveau du serveur principal
qui restreint le choix des suites de chiffrement aux versions les plus
fortes ne conviendra pas. <module>mod_ssl</module> peut cependant être
reconfiguré au sein de blocs <code>Location</code> qui permettent
d'adapter la configuration générale à un répertoire spécifique ;
<module>mod_ssl</module> peut alors forcer automatiquement une
renégociation des paramètres SSL pour parvenir au but recherché.
Cette configuration peut se présenter comme suit :</p>
<highlight language="config">
# soyons très tolérant a priori
SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
<Location /strong/area>
# sauf pour https://hostname/strong/area/ et ses sous-répertoires
# qui exigent des chiffrements forts
SSLCipherSuite HIGH:!aNULL:!MD5
</Location>
</highlight>
</section>
<!-- /ciphersuites -->
<section id="accesscontrol">
<title>Authentification du client et contrôle d'accès</title>
<ul>
<li><a href="#allclients">Comment forcer les clients
à s'authentifier à l'aide de certificats ?</a></li>
<li><a href="#arbitraryclients">Comment forcer les clients
à s'authentifier à l'aide de certificats pour une URL particulière,
mais autoriser quand-même tout client anonyme
à accéder au reste du serveur ?</a></li>
<li><a href="#certauthenticate">Comment n'autoriser l'accès à une URL
particulière qu'aux clients qui possèdent des certificats, mais autoriser
l'accès au reste du serveur à tous les clients ?</a></li>
<li><a href="#intranet">Comment imposer HTTPS avec chiffrements forts,
et soit authentification de base, soit possession de certificats clients,
pour l'accès à une partie de l'Intranet, pour les clients en
provenance de l'Internet ?</a></li>
</ul>
<section id="allclients">
<title>Comment forcer les clients
à s'authentifier à l'aide de certificats ?
</title>
<p>Lorsque vous connaissez tous vos clients (comme c'est en général le cas
au sein d'un intranet d'entreprise), vous pouvez imposer une
authentification basée uniquement sur les certificats. Tout ce dont vous
avez besoin pour y parvenir est de créer des certificats clients signés par
le certificat de votre propre autorité de certification
(<code>ca.crt</code>), et d'authentifier les clients à l'aide de ces
certificats.</p>
<highlight language="config">
# exige un certificat client signé par le certificat de votre CA
# contenu dans ca.crt
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt
</highlight>
</section>
<section id="arbitraryclients">
<title>Comment forcer les clients
à s'authentifier à l'aide de certificats pour une URL particulière,
mais autoriser quand-même tout client anonyme
à accéder au reste du serveur ?</title>
<p>Pour forcer les clients à s'authentifier à l'aide de certificats pour une
URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration
de <module>mod_ssl</module> en fonction du répertoire :</p>
<highlight language="config">
SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt
<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>
</highlight>
</section>
<section id="certauthenticate">
<title>Comment n'autoriser l'accès à une URL
particulière qu'aux clients qui possèdent des certificats, mais autoriser
l'accès au reste du serveur à tous les clients ?</title>
<p>La clé du problème consiste à vérifier si une partie du certificat
client correspond à ce que vous attendez. Cela signifie en général
consulter tout ou partie du nom distinctif (DN), afin de vérifier s'il
contient une chaîne connue. Il existe deux méthodes pour y parvenir ;
on utilise soit le module <module>mod_auth_basic</module>, soit la
directive <directive module="mod_ssl">SSLRequire</directive>.</p>
<p>La méthode du module <module>mod_auth_basic</module> est en général
incontournable lorsque les certificats ont un contenu arbitraire, ou
lorsque leur DN ne contient aucun champ connu
(comme l'organisation, etc...). Dans ce cas, vous devez construire une base
de données de mots de passe contenant <em>tous</em> les clients
autorisés, comme suit :</p>
<highlight language="config">
SSLVerifyClient none
<Directory /usr/local/apache2/htdocs/secure/area>
SSLVerifyClient require
SSLVerifyDepth 5
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
SSLOptions +FakeBasicAuth
SSLRequireSSL
AuthName "Snake Oil Authentication"
AuthType Basic
AuthBasicProvider file
AuthUserFile /usr/local/apache2/conf/httpd.passwd
Require valid-user
</Directory>
</highlight>
<p>Le mot de passe utilisé dans cet exemple correspond à la chaîne de
caractères "password" chiffrée en DES. Voir la documentation de la
directive <directive module="mod_ssl">SSLOptions</directive> pour
plus de détails.</p>
<example><title>httpd.passwd</title><pre>
/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA</pre>
</example>
<p>Lorsque vos clients font tous partie d'une même hiérarchie, ce qui
apparaît dans le DN, vous pouvez les authentifier plus facilement en
utilisant la directive <directive module="mod_ssl"
>SSLRequire</directive>, comme suit :</p>
<highlight language="config">
SSLVerifyClient none
<Directory /usr/local/apache2/htdocs/secure/area>
SSLVerifyClient require
SSLVerifyDepth 5
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
SSLOptions +FakeBasicAuth
SSLRequireSSL
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
</Directory>
</highlight>
</section>
<section id="intranet">
<title>Comment imposer HTTPS avec chiffrements forts,
et soit authentification de base, soit possession de certificats clients,
pour l'accès à une partie de l'Intranet, pour les clients en
provenance de l'Internet ? Je souhaite quand-même autoriser l'accès en HTTP
aux clients de l'intranet.</title>
<p>On suppose dans ces exemples que les clients de l'intranet ont des
adresses IP dans la gamme 192.168.1.0/24, et que la partie de l'intranet
à laquelle vous voulez autoriser l'accès depuis l'Internet est
<code>/usr/local/apache2/htdocs/subarea</code>. Ces lignes de configuration
doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles
s'appliquent à la fois à HTTP et HTTPS.</p>
<highlight language="config">
SSLCACertificateFile conf/ssl.crt/company-ca.crt
<Directory /usr/local/apache2/htdocs>
# En dehors de subarea, seul l'accès depuis l'intranet est
# autorisé
Order deny,allow
Deny from all
Allow from 192.168.1.0/24
</Directory>
<Directory /usr/local/apache2/htdocs/subarea>
# Dans subarea, tout accès depuis l'intranet est autorisé
# mais depuis l'Internet, seul l'accès par HTTPS + chiffrement fort + Mot de passe
# ou HTTPS + chiffrement fort + certificat client n'est autorisé.
# Si HTTPS est utilisé, on s'assure que le niveau de chiffrement est fort.
# Autorise en plus les certificats clients comme une alternative à
# l'authentification basique.
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +FakeBasicAuth +StrictRequire
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
# ON oblige les clients venant d'Internet à utiliser HTTPS
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
RewriteCond %{HTTPS} !=on
RewriteRule . - [F]
# On permet l'accès soit sur les critères réseaux, soit par authentification Basique
Satisfy any
# Contrôle d'accès réseau
Order deny,allow
Deny from all
Allow 192.168.1.0/24
# Configuration de l'authentification HTTP Basique
AuthType basic
AuthName "Protected Intranet Area"
AuthBasicProvider file
AuthUserFile conf/protected.passwd
Require valid-user
</Directory>
</highlight>
</section>
</section>
<!-- /access control -->
<section id="logging">
<title>Journalisation</title>
<p><module>mod_ssl</module> peut enregistrer des informations de
débogage très verbeuses dans le journal des erreurs, lorsque sa
directive <directive module="core">LogLevel</directive> est définie
à des niveaux de trace élevés. Par contre, sur un serveur très
sollicité, le niveau <code>info</code> sera probablement déjà trop
élevé. Souvenez-vous que vous pouvez configurer la directive
<directive module="core">LogLevel</directive> par module afin de
pourvoir à vos besoins.</p>
</section>
</manualpage>
|