<a href="../ja/mod/core.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
<a href="../tr/mod/core.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>Fonctionnalités de base du serveur HTTP Apache toujours
disponibles</td></tr>
<tr><th><a href="module-dict.html#Status">Statut:</a></th><td>Core</td></tr></table>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Modifie les contraintes sur les messages des requêtes HTTP</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntaxe:</a></th><td><code>HttpProtocolOptions [Strict|Unsafe] [StrictURL|UnsafeURL]
- [StrictWhitespace|LenientWhitespace] [RegisteredMethods|LenientMethods]
+ [StrictWhitespace|UnsafeWhitespace] [RegisteredMethods|LenientMethods]
[Allow0.9|Require1.0]</code></td></tr>
-<tr><th><a href="directive-dict.html#Default">Défaut:</a></th><td><code>HttpProtocolOptions Strict StrictURL LenientWhitespace
+<tr><th><a href="directive-dict.html#Default">Défaut:</a></th><td><code>HttpProtocolOptions Strict StrictURL StrictWhitespace
LenientMethods Allow0.9</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Contexte:</a></th><td>configuration du serveur, serveur virtuel</td></tr>
<tr><th><a href="directive-dict.html#Status">Statut:</a></th><td>Core</td></tr>
règles de grammaire de la spécification doivent être respectées dans le mode
d'opérations par défaut <code>Strict</code>.</p>
- <p><a href="https://tools.ietf.org/html/rfc3986#section-2.2">RFC 7230
+ <p><a href="https://tools.ietf.org/html/rfc3986#section-2.2">RFC 3986
§2.2 and 2.3</a> définit les "Caractères réservés" ainsi que les
"Caractères non réservés". Tous les autres caractères doivent être encodés
sous la forme %XX selon la spécification, et la RFC7230 se conforme à ces
contournée en utilisant l'option <code>UnsafeURI</code> qui permet de
supporter les agents utilisateur mal conçus.</p>
+
+
+ <p>La section de la <a href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230
+ §3.5</a> "Message Parsing Robustness" décrit les risques potentiels
+ induits par l'interprétation de messages contenant des blancs représentés
+ par un caractère autre que l'espace. Alors que les spécifications indiquent
+ qu'un et un seul espace sépare l'URI de la méthode et le protocole de l'URI,
+ et que seuls les espaces et les tabulations horizontales sont autorisés
+ dans le contenu des en-têtes de requêtes,
+ le serveur HTTP Apache a toujours toléré des blancs constitués d'un ou
+ plusieurs espaces ou tabulations horizontales. L'option par défaut
+ <code>StrictWhitespace</code> permet maintenant de rejeter toute requête non
+ conforme. L'administrateur peut cependant utiliser l'option
+ <code>UnsafeWhitespace</code> pour continuer à accepter les requêtes non
+ conformes, avec un risque important d'interactions avec le mandataire.</p>
+
<p>Il est fortement déconseillé aux utilisateurs d'utiliser les modes
- d'opérations <code>Unsafe</code> et <code>UnsafeURI</code>, en particulier
- pour les déploiements de serveurs ouverts sur l'extérieur et/ou accessibles
- au public. Si un moniteur défectueux ou autre logiciel spécialisé ne
- s'exécutant que sur un intranet nécessite une interface, les utilisateurs
- ne doivent les utilisés qu'au sein d'un serveur virtuel bien spécifique et
- sur un réseau privé.</p>
+ d'opérations <code>Unsafe</code> et <code>UnsafeURI</code>, ou
+ <code>UnsafeWhitespace</code>, en particulier pour les déploiements de
+ serveurs ouverts sur l'extérieur et/ou accessibles au public. Si un moniteur
+ défectueux ou autre logiciel spécialisé ne s'exécutant que sur un intranet
+ nécessite une interface, les utilisateurs ne doivent utiliser les options de
+ type UnSafe qu'en cas de nécessité et uniquement au sein d'un serveur
+ virtuel bien spécifique et sur un réseau privé.</p>
<p>La consultation des messages enregistrés dans le journal
<code class="directive">ErrorLog</code>, configuré via la directive
messages d'erreur de type 400 dans le journal access pour détecter les
requêtes apparemment valides mais rejetées.</p>
- <p>La section de la <a href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230
- §3.5</a> "Message Parsing Robustness" décrit les risques potentiels
- induits par l'interprétation de messages contenant des blancs représentés
- par un caractère autre que l'espace. Alors que les spécifications indiquent
- qu'un et un seul espace sépare l'URI de la méthode et le protocole de l'URI,
- le serveur HTTP Apache a toujours toléré des blancs constitués d'un ou
- plusieurs espaces ou tabulations horizontales. L'option par défaut
- <code>LenientWhitespace</code> continue d'accepter de telles requêtes en
- provenance d'agents utilisateurs non conformes, mais l'administrateur est
- encouragé à utiliser plutôt l'option <code>StrictWhitespace</code> pour
- imposer la présence d'exactement deux espaces dans la ligne de requête.
- D'autres types de blancs comme les tabulations verticales, form feed
- ou retour chariot seront alors rejetés et ne seront plus supportés.</p>
-
<p>La section de la <a href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231
§4.1</a> "Request Methods" "Overview" indique que les serveurs doivent
renvoyer un message d'erreur lorsque la ligne de requête comporte une
§19.6</a> "Compatibility With Previous Versions" encouragait les
serveurs HTTP à supporter les anciennes requêtes HTTP/0.9. La RFC 7230 va
cependant à son encontre via sa préconisation "Le souhait de supporter les
- requêtes HTTP/0.9 a été supprimé" et y adjoint des commentaires dans <a href="https://tools.ietf.org/html/rfc7230#appendix-A">RFC 2616 Appendix
+ requêtes HTTP/0.9 a été supprimé" et y adjoint des commentaires dans <a href="https://tools.ietf.org/html/rfc7230#appendix-A">RFC 7230 Appendix
A</a>. A ce titre, l'option <code>Require1.0</code> permet à l'utilisateur
d'inhiber le comportement induit par l'option par défaut
<code>Allow0.9</code>.</p>
<variant outdated="yes">de</variant>
<variant>en</variant>
<variant outdated="yes">es</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">tr</variant>
</variants>
<p><span>Langues Disponibles: </span><a href="../en/mod/mod_rewrite.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/mod/mod_rewrite.html" title="Français"> fr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>Ce module fournit un moteur de réécriture à base de
règles permettant de réécrire les URLs des requêtes
à la volée</td></tr>
la réécriture soit effectuée
</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntaxe:</a></th><td><code> RewriteCond
- <em>chaîne_de_test</em> <em>expression_de_comparaison</em></code></td></tr>
+ <em>chaîne_de_test</em> <em>expression_de_comparaison</em> [<em>drapeaux</em>]</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Contexte:</a></th><td>configuration du serveur, serveur virtuel, répertoire, .htaccess</td></tr>
<tr><th><a href="directive-dict.html#Override">AllowOverride:</a></th><td>FileInfo</td></tr>
<tr><th><a href="directive-dict.html#Status">Statut:</a></th><td>Extension</td></tr>
RewriteRule "^/images" "-" [F]</pre>
</li>
+ </ol>
- <li>Vous pouvez aussi définir certains drapeaux pour
+ <p>Vous pouvez aussi définir certains drapeaux pour
l'<em>expression_de_comparaison</em> en ajoutant ces
<strong><code>[</code><em>drapeaux</em><code>]</code></strong>
comme troisième argument de la directive
<code>RewriteCond</code>, où <em>drapeaux</em> est un
- sous-ensemble séparé par des virgules des drapeaux suivants :
+ sous-ensemble séparé par des virgules des drapeaux suivants :</p>
<ul>
<li>'<strong><code>nocase|NC</code></strong>'
fonctionnement de l'en-tête Vary.
</li>
</ul>
- </li>
- </ol>
+
<p><strong>Exemple :</strong></p>
<p><a id="patterns" name="patterns"><em>Modèle</em></a> est une
<a id="regexp" name="regexp">expression rationnelle</a>
- compatible perl. Dans la première règle de réécriture,
- l'expression est comparée au (%-decoded)
- <a href="directive-dict.html#Syntax">chemin de l'URL</a> de la
- requête, ou, dans un contexte de répertoire (voir
- ci-dessous), au chemin de l'URL relativement à ce contexte de
- répertoire. Les expressions suivantes sont comparées à la sortie de
- la dernière règle de réécriture qui
- correspondait.</p>
+ compatible perl. Ce avec quoi ce modèle est comparé dépend de l'endroit où
+ la directive <code class="directive">RewriteRule</code> est définie.</p>
<div class="note"><h3><a id="what_is_matched" name="what_is_matched">Qu'est-ce qui est comparé ?</a></h3>
- <p>Dans un contexte de serveur virtuel <code class="directive"><a href="../mod/core.html#virtualhost">VirtualHost</a></code>, le <em>modèle</em> est tout
+<ul>
+ <li><p>Dans un contexte de serveur virtuel <code class="directive"><a href="../mod/core.html#virtualhost">VirtualHost</a></code>, le <em>modèle</em> est tout
d'abord comparé à la portion de l'URL située entre le nom d'hôte
éventuellement accompagné du port, et la chaîne de paramètres (par
- exemple "/app1/index.html").</p>
-
- <p>Dans les contextes de répertoire <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> et htaccess, le
- <em>modèle</em> est tout d'abord comparé au chemin du <em>système
- de fichiers</em>, après suppression du préfixe ou chemin de base
- ayant conduit le serveur vers la règle <code class="directive">RewriteRule</code> (par
- exemple "app1/index.html" ou
- "index.html" selon l'endroit où les directives sont définies).</p>
+ exemple "/app1/index.html"). Il s'agit du <a href="directive-dict.html#Syntax">URL-path</a> décodé de sa valeur "%xx".</p></li>
+
+ <li><p>Dans un contexte de répertoire (sections <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> et fichiers .htaccess), le
+ <em>Modèle</em> est comparé avec une partie de chemin ; par exemple une
+ requête pour "/app1/index.html" entraînera une comparaison avec
+ "app1/index.html" ou "index.html" selon l'endroit où la directive
+ <code class="directive">RewriteRule</code> est définie.</p>
+
+ <p>Le chemin où la règle est défini est supprimé du chemin correspondant
+ du système de fichiers avant comparaison (jusqu'au slash final compris).
+ En conséquence de cette suppression, les règles définies dans
+ ce contexte n'effectuent des comparaisons qu'avec la portion du chemin
+ du système de fichiers "en dessous" de l'endroit où la règle est définie.</p>
+
+ <p>Le chemin correspondant actuel du système de fichiers est déterminé par
+ des directives telles que <code class="directive">DocumentRoot</code> et
+ <code class="directive">Alias</code>, ou même le résultat de substitutions dans
+ des règles <code class="directive">RewriteRule</code> précédentes.
+ </p>
+ </li>
- <p>Si vous souhaitez faire une comparaison sur le nom
+ <li><p>Si vous souhaitez faire une comparaison sur le nom
d'hôte, le port, ou la chaîne de requête, utilisez une
directive <code class="directive"><a href="#rewritecond">RewriteCond</a></code>
comportant respectivement les variables
<code>%{HTTP_HOST}</code>, <code>%{SERVER_PORT}</code>, ou
- <code>%{QUERY_STRING}</code>.</p>
-
- <p>Dans tous les cas, il faut garder à l'esprit que les expressions
- rationnelles permettent de rechercher des correspondances de sous-chaînes.
- En d'autres termes, l'expression rationnelle n'a pas besoin de correspondre à
- l'ensemble de la chaîne, mais seulement à la partie que vous souhaitez
- voir correspondre. Ainsi, l'utilisation de l'expression <code>.</code> est
- souvent suffisante et préférable à <code>.*</code>, et l'expression
- <code>abc</code> <strong>n'est pas</strong> identique à l'expression
- <code>^abc$</code>.</p>
+ <code>%{QUERY_STRING}</code>.</p></li>
+</ul>
+
</div>
<div class="note"><h3>Réécritures dans un contexte de répertoire</h3>
moteur de réécriture. Cette restriction a été instaurée à des fins de
sécurité.</li>
-<li>Lorsqu'on utilise le moteur de réécriture dans un fichier
-<code>.htaccess</code>, le chemin de base du répertoire courant (autrement dit
-le chemin URI qui représente le répertoire contenant ce fichier
-<code>.htaccess</code>) est <em>supprimé</em> au cours de la
-comparaison avec le modèle de la règle de réécriture, et
-<em>ajouté</em> lorsqu'une substitution relative (ne débutant pas par un slash
-ou un nom de protocole) arrive à la fin d'un jeu de règles. Voir la directive
+<li>Voir la directive
<code class="directive"><a href="#rewritebase">RewriteBase</a></code> pour plus de détails à
propos de l'ajout du préfixe après les substitutions relatives.</li>
<variants>
<variant>en</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
</variants>
</metafile>
<p><span>Langues Disponibles: </span><a href="../en/ssl/ssl_howto.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/ssl/ssl_howto.html" title="Français"> fr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>Ce document doit vous permettre de démarrer et de faire fonctionner
manière plus approfondie.</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#configexample">Exemple de configuration basique</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#ciphersuites">Suites de chiffrement et mise en application de la sécurité
-de haut niveau</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#ciphersuites">Suites d'algorithmes de chiffrement et mise en oeuvre du chiffrement fort</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#ocspstapling">Agrafage OCSP</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#accesscontrol">Authentification du client et contrôle d'accès</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#logging">Journalisation</a></li>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
-<h2><a name="ciphersuites" id="ciphersuites">Suites de chiffrement et mise en application de la sécurité
-de haut niveau</a></h2>
+<h2><a name="ciphersuites" id="ciphersuites">Suites d'algorithmes de chiffrement et mise en oeuvre du chiffrement fort</a></h2>
+
+
+<div class="warning">
+<p>Le "chiffrement fort est et a toujours été une cible mouvante. En outre, la
+définition du terme "fort" dépend de l'utilisation que vous allez faire de votre
+chiffrement, de vos modèles de menaces, et du niveau de risque que vous
+considérez comme acceptable. L'équipe du serveur HTTP Apache ne peut donc pas
+définir ce chiffrement fort à votre place.</p>
+<p>Dans ce document dont la dernière mise à jour remonte à la mi-2016, une
+"chiffrement fort" fait référence à une implémentation TLS qui fournit, en plus
+d'une protection basique de la confidentialité, de l'intégrité et de
+l'authenticité que tout utilisateur s'attend à trouver, toutes les
+fonctionnalités suivantes :</p>
+<ul>
+<li>Une confidentialité persistante (Forward Secrecy) parfaite qui garantie que
+la découverte de la clé privée d'un serveur ne compromettra pas la
+condidentialité des communications TLS passées.</li>
+<li>Une protection contre les types d'attaque connus contre les anciennes
+implémentations SSL et TLS comme <a href="https://en.wikipedia.org/wiki/POODLE">POODLE</a> et <a href="https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack">BEAST</a>.</li>
+<li>Le support des algorithmes de chiffrement les plus efficaces disponibles sur
+les navigateurs web modernes (et à jour), ainsi que sur les autres clients HTTP.</li>
+<li>Le <strong>Rejet</strong> des clients qui ne sont pas en mesure de respecter
+ces prérequis. En d'autres termes, un "chiffrement fort" implique que les
+clients obsolètes ne doivent pas avoir la possibilité de se connecter au serveur
+afin de les empêcher de mettre en danger leurs utilisateurs. Vous seul(e) êtes
+alors à même de décider si ce comportement est approprié à votre situation.</li>
+</ul>
+<p>Notez cependant qu'un <em>chiffrement fort</em> ne suffit pas à lui seul pour
+assurer un niveau de <em>securité</em> fort (A titre d'exemple, les attaques
+oracle sur la compression HTTP comme <a href="https://en.wikipedia.org/wiki/BREACH_(security_exploit)">BREACH</a>
+peuvent nécessiter des actions supplémentaires pour être éradiquées).</p>
+</div>
<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
+<li><a href="#strongurl">Comment créer un serveur qui accepte de nombreux types de
chiffrement en général, mais exige un chiffrement fort pour pouvoir
accéder à une URL particulière ?</a></li>
</ul>
<h3><a name="onlystrong" id="onlystrong">Comment créer un serveur SSL qui n'accepte
que le chiffrement fort ?</a></h3>
- <p>Les directives suivantes ne permettent que les
- chiffrements de plus haut niveau :</p>
- <pre class="prettyprint lang-config">SSLCipherSuite HIGH:!aNULL:!MD5</pre>
-
-
- <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>
-
- <pre class="prettyprint lang-config">SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
-SSLHonorCipherOrder on</pre>
-
-
-
-<h3><a name="strongurl" id="strongurl">Comment créer un serveur qui accepte tous les types de
+ <p>La configuration suivante active le "chiffrement fort" telle qu'il est
+ défini ci-dessus, et s'inspire du document de la Fondation Mozilla sur les
+ prérequis de <a href="https://wiki.mozilla.org/Security/Server_Side_TLS">Server Side
+ TLS</a> :</p>
+
+ <pre class="prettyprint lang-config"># Configuration "moderne" définie en août 2016 par le générateur de
+# configuration SSL de la Fondation Mozilla. Ce dernier est disponible à
+# https://mozilla.github.io/server-side-tls/ssl-config-generator/
+SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
+# De nombreux algorithmes de chiffrement définis ici nécessitent une version
+# récente (1.0.1 ou plus) d'OpenSSL. Certains nécessitent même OpenSSL 1.1.0
+# qui, à l'heure où ces lignes sont écrites, était encore en pre-release.
+SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
+SSLHonorCipherOrder on
+SSLCompression off
+SSLSessionTickets off</pre>
+
+
+ <ul>
+ <li>SSL 3.0 et TLS 1.0 étant vulnérables à certaines attaques connues contre
+ le protocole, ils ont été entièrement retirés.</li>
+ <li>Actuellement (en août 2016), la désactivation de TLS 1.1 est facultative
+ ; TLS 1.2 fournit des options de chiffrement plus évoluées, mais la version
+ 1.1 n'est pas encore considérée comme obsolète. La désactivation de TLS 1.1
+ peut cependant juguler des attaques contre certaines implémentations
+ dépassées de TLS.</li>
+ <li>La directive <code class="directive"><a href="../mod/mod_ssl.html#sslhonorcipherorder">SSLHonorCipherOrder</a></code>
+ permet de s'assurer que ce sont les préférences de chiffrement du serveur
+ qui seront suivies, et non celles du client.</li>
+ <li>La désactivation de <code class="directive"><a href="../mod/mod_ssl.html#sslcompression">SSLCompression</a></code> permet de prévenir les attaques
+ oracle sur la compression TLS (en autres <a href="https://en.wikipedia.org/wiki/CRIME">CRIME</a>).</li>
+ <li>La désactivation de <code class="directive"><a href="../mod/mod_ssl.html#sslsessiontickets">SSLSessionTickets</a></code> permet de s'assurer que la
+ qualité de la confidentialité persistante (Forward Secrecy) ne sera pas
+ compromise, même si le serveur n'est pas redémarré régulièrement.</li>
+ </ul>
+
+ <p>C'est votre version d'OpenSSL installée qui détermine la liste des
+ algorithmes de chiffrement supportés par la directive <code class="directive"><a href="../mod/mod_ssl.html#sslciphersuite">SSLCipherSuite</a></code>, et non le serveur. Pour pouvoir
+ utiliser certains d'entre eux, vous devrez peut-être mettre à jour votre
+ version d'OpenSSL.</p>
+
+
+<h3><a name="strongurl" id="strongurl">Comment créer un serveur qui accepte de nombreux types de
chiffrement en général, mais exige un chiffrement fort pour pouvoir
accéder à une URL particulière ?</a></h3>
<code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> 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>
- <pre class="prettyprint lang-config"># soyons très tolérant a priori
-SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
+ <pre class="prettyprint lang-config"># soyons très tolérant a priori -- utilisons la suite d'algorithmes de
+# chiffrement "intermédiaire" de Mozilla (des suites plus légères peuvent aussi
+# être utilisées mais ne seront pas documentées ici)
+SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
<Location "/strong/area">
-# sauf pour https://hostname/strong/area/ et ses sous-répertoires
-# qui exigent des chiffrements forts
-SSLCipherSuite HIGH:!aNULL:!MD5
+# sauf pour https://hostname/strong/area/ et ses sous-répertoires qui exigent
+# des chiffrements forts
+SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
</Location></pre>
<variants>
<variant>en</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
</variants>
</metafile>
projects / apache / commitdiff