From: Lucien Gentis Date: Sun, 28 Aug 2016 13:59:31 +0000 (+0000) Subject: Rebuild. X-Git-Tag: 2.5.0-alpha~1189 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=04a554dc9f3cef65eb451cb9f2dae012e67678cb;p=thirdparty%2Fapache%2Fhttpd.git Rebuild. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1758115 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.html.fr b/docs/manual/mod/core.html.fr index afe28c369da..0c4b3d898ae 100644 --- a/docs/manual/mod/core.html.fr +++ b/docs/manual/mod/core.html.fr @@ -33,8 +33,6 @@  ja  |  tr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
Description:Fonctionnalités de base du serveur HTTP Apache toujours disponibles
Statut:Core
@@ -2176,9 +2174,9 @@ clients - @@ -2209,7 +2207,7 @@ Apache règles de grammaire de la spécification doivent être respectées dans le mode d'opérations par défaut Strict.

-

RFC 7230 +

RFC 3986 §2.2 and 2.3 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 @@ -2218,13 +2216,30 @@ Apache contournée en utilisant l'option UnsafeURI qui permet de supporter les agents utilisateur mal conçus.

+ + +

La section de la RFC 7230 + §3.5 "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 + StrictWhitespace permet maintenant de rejeter toute requête non + conforme. L'administrateur peut cependant utiliser l'option + UnsafeWhitespace pour continuer à accepter les requêtes non + conformes, avec un risque important d'interactions avec le mandataire.

+

Il est fortement déconseillé aux utilisateurs d'utiliser les modes - d'opérations Unsafe et UnsafeURI, 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é.

+ d'opérations Unsafe et UnsafeURI, ou + UnsafeWhitespace, 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é.

La consultation des messages enregistrés dans le journal ErrorLog, configuré via la directive @@ -2234,20 +2249,6 @@ Apache messages d'erreur de type 400 dans le journal access pour détecter les requêtes apparemment valides mais rejetées.

-

La section de la RFC 7230 - §3.5 "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 - LenientWhitespace continue d'accepter de telles requêtes en - provenance d'agents utilisateurs non conformes, mais l'administrateur est - encouragé à utiliser plutôt l'option StrictWhitespace 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.

-

La section de la RFC 7231 §4.1 "Request Methods" "Overview" indique que les serveurs doivent renvoyer un message d'erreur lorsque la ligne de requête comporte une @@ -2265,7 +2266,7 @@ Apache §19.6 "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 RFC 2616 Appendix + requêtes HTTP/0.9 a été supprimé" et y adjoint des commentaires dans RFC 7230 Appendix A. A ce titre, l'option Require1.0 permet à l'utilisateur d'inhiber le comportement induit par l'option par défaut Allow0.9.

diff --git a/docs/manual/mod/core.xml.meta b/docs/manual/mod/core.xml.meta index b9d96ee4c52..e78755527af 100644 --- a/docs/manual/mod/core.xml.meta +++ b/docs/manual/mod/core.xml.meta @@ -10,7 +10,7 @@ deenes - fr + frjatr diff --git a/docs/manual/mod/mod_rewrite.html.fr b/docs/manual/mod/mod_rewrite.html.fr index 65189b7dced..9edea9a4677 100644 --- a/docs/manual/mod/mod_rewrite.html.fr +++ b/docs/manual/mod/mod_rewrite.html.fr @@ -29,8 +29,6 @@

Langues Disponibles:  en  |  fr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
Description:Modifie les contraintes sur les messages des requêtes HTTP
Syntaxe:HttpProtocolOptions [Strict|Unsafe] [StrictURL|UnsafeURL] - [StrictWhitespace|LenientWhitespace] [RegisteredMethods|LenientMethods] + [StrictWhitespace|UnsafeWhitespace] [RegisteredMethods|LenientMethods] [Allow0.9|Require1.0]
Défaut:HttpProtocolOptions Strict StrictURL LenientWhitespace +
Défaut:HttpProtocolOptions Strict StrictURL StrictWhitespace LenientMethods Allow0.9
Contexte:configuration du serveur, serveur virtuel
Statut:Core
@@ -183,7 +181,7 @@ AliasMatch "^/myapp" "/opt/myapp-1.2.3" la réécriture soit effectuée + chaîne_de_testexpression_de_comparaison [drapeaux] @@ -728,13 +726,14 @@ RewriteRule ^(.+) /other/archive/$1 [R] RewriteRule "^/images" "-" [F] + -
  • Vous pouvez aussi définir certains drapeaux pour +

    Vous pouvez aussi définir certains drapeaux pour l'expression_de_comparaison en ajoutant ces [drapeaux] comme troisième argument de la directive RewriteCond, où drapeaux est un - sous-ensemble séparé par des virgules des drapeaux suivants : + sous-ensemble séparé par des virgules des drapeaux suivants :

    -
    • - +

    Exemple :

    @@ -1116,44 +1114,44 @@ pour le moteur de r

    Modèle est une expression rationnelle - compatible perl. Dans la première règle de réécriture, - l'expression est comparée au (%-decoded) - chemin de l'URL 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.

    + compatible perl. Ce avec quoi ce modèle est comparé dépend de l'endroit où + la directive RewriteRule est définie.

    Qu'est-ce qui est comparé ?

    -

    Dans un contexte de serveur virtuel VirtualHost, le modèle est tout +

    +

    Réécritures dans un contexte de répertoire

    @@ -1171,13 +1169,7 @@ niveau du r moteur de réécriture. Cette restriction a été instaurée à des fins de sécurité. -
  • Lorsqu'on utilise le moteur de réécriture dans un fichier -.htaccess, le chemin de base du répertoire courant (autrement dit -le chemin URI qui représente le répertoire contenant ce fichier -.htaccess) est supprimé au cours de la -comparaison avec le modèle de la règle de réécriture, et -ajouté 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 +
  • Voir la directive RewriteBase pour plus de détails à propos de l'ajout du préfixe après les substitutions relatives.
    • diff --git a/docs/manual/mod/mod_rewrite.xml.meta b/docs/manual/mod/mod_rewrite.xml.meta index 0be21e86f4d..decc0a7b1e8 100644 --- a/docs/manual/mod/mod_rewrite.xml.meta +++ b/docs/manual/mod/mod_rewrite.xml.meta @@ -8,6 +8,6 @@ en - fr + fr diff --git a/docs/manual/ssl/ssl_howto.html.fr b/docs/manual/ssl/ssl_howto.html.fr index c12f5033e22..5508dbf44b0 100644 --- a/docs/manual/ssl/ssl_howto.html.fr +++ b/docs/manual/ssl/ssl_howto.html.fr @@ -26,8 +26,6 @@

    Langues Disponibles:  en  |  fr 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

    Ce document doit vous permettre de démarrer et de faire fonctionner @@ -37,8 +35,7 @@ de la documentation SSL afin d'en comprendre le fonctionnement de manière plus approfondie.

    top
    -

    Suites de chiffrement et mise en application de la sécurité -de haut niveau

    +

    Suites d'algorithmes de chiffrement et mise en oeuvre du chiffrement fort

    + + +
    +

    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.

    +

    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 :

    +
      +
    • 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.
      • +
    • Une protection contre les types d'attaque connus contre les anciennes +implémentations SSL et TLS comme POODLE et BEAST.
      • +
    • Le support des algorithmes de chiffrement les plus efficaces disponibles sur +les navigateurs web modernes (et à jour), ainsi que sur les autres clients HTTP.
      • +
    • Le Rejet 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.
      • +
    +

    Notez cependant qu'un chiffrement fort ne suffit pas à lui seul pour +assurer un niveau de securité fort (A titre d'exemple, les attaques +oracle sur la compression HTTP comme BREACH +peuvent nécessiter des actions supplémentaires pour être éradiquées).

    +
    @@ -77,22 +105,49 @@ acc

    Comment créer un serveur SSL qui n'accepte que le chiffrement fort ?

    -

    Les directives suivantes ne permettent que les - chiffrements de plus haut niveau :

    - 
    SSLCipherSuite HIGH:!aNULL:!MD5
    - - -

    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) :

    - - 
    SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
-SSLHonorCipherOrder on
    - - - -

    Comment créer un serveur qui accepte tous les types de +

    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 Server Side + TLS :

    + + 
    # 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
    + + +
      +
    • SSL 3.0 et TLS 1.0 étant vulnérables à certaines attaques connues contre + le protocole, ils ont été entièrement retirés.
      • +
    • 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.
      • +
    • La directive SSLHonorCipherOrder + permet de s'assurer que ce sont les préférences de chiffrement du serveur + qui seront suivies, et non celles du client.
      • +
    • La désactivation de SSLCompression permet de prévenir les attaques + oracle sur la compression TLS (en autres CRIME).
      • +
    • La désactivation de SSLSessionTickets 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.
      • +
    + +

    C'est votre version d'OpenSSL installée qui détermine la liste des + algorithmes de chiffrement supportés par la directive SSLCipherSuite, et non le serveur. Pour pouvoir + utiliser certains d'entre eux, vous devrez peut-être mettre à jour votre + version d'OpenSSL.

    + + +

    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 ?

    @@ -104,13 +159,15 @@ acc mod_ssl peut alors forcer automatiquement une renégociation des paramètres SSL pour parvenir au but recherché. Cette configuration peut se présenter comme suit :

    - 
    # soyons très tolérant a priori
-SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
+    
    # 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>
    
 
 
diff --git a/docs/manual/ssl/ssl_howto.xml.meta b/docs/manual/ssl/ssl_howto.xml.meta
index 8d9a5237f4e..b7c021fd9a8 100644
--- a/docs/manual/ssl/ssl_howto.xml.meta
+++ b/docs/manual/ssl/ssl_howto.xml.meta
@@ -8,6 +8,6 @@
 
   
     en
-    fr
+    fr
    Description:Ce module fournit un moteur de réécriture à base de règles permettant de réécrire les URLs des requêtes à la volée
    Syntaxe: RewriteCond - chaîne_de_test expression_de_comparaison
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Extension