FAQ du serveur HTTP ApacheConsultez toutes les FAQ

Nombre d'auteurs : 9, nombre de questions : 47, dernière mise à jour : 2 septembre 2018 

 
OuvrirSommaireConfiguration généraleHTTPS

Apache crée automatiquement une variable d'environnement interne nommée HTTPS et lui assigne la valeur on lorsque la ressource est demandée par l'intermédiaire du protocole sécurisé HTTPS. En HTTP normal, elle n'existera pas mais pour un comportement portable il est recommandé de tester à la fois sa présence puis sa valeur afin de pouvoir le déterminer précisément (sous IIS, elle sera définie mais de valeur off).

Vous pouvez donc regarder cette variable aussi bien dans un programme CGI que dans un script (PHP) ou encore lors d'une réécriture (voir Comment rendre certains documents accessibles uniquement par le protocole HTTPS ? pour des exemples).

Ne testez surtout pas les ports pour déterminer si vous êtes ou non en HTTPS : ce n'est en rien fiable contrairement à ce qui est dit ci-dessus ! On peut très bien configurer un serveur pour utiliser d'autres ports que les ports standards (bien que le client doivent les expliciter). Il est tout à fait possible de faire de l'HTTP sur le port 443 et de l'HTTPS sur le port 80.

Créé le 30 mars 2010  par julp

Il est possible de réaliser la redirection de ressources particulières en vue de forcer, pour celles-ci, l'usage du protocole sécurisé (HTTPS). Pour ce faire, il est possible d'agir à plusieurs niveaux :

  • Indiquer les redirections (directives Redirect*) directement depuis la déclaration du virtualhost HTTP correspondant (méthode à privilégier). Exemple :

     
    Sélectionnez
    
    <VirtualHost ...:80>
        # ...
        RedirectPermanent page_securisee.html https://www.monserveur.fr/page_securisee.html
    </VirtualHost>
  • Depuis un fichier .htaccess et à l'aide du module de réécriture :

     
    Sélectionnez
    
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule secure[/_].* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
  • Que l'on peut aussi, éventuellement, implémenter en PHP :

     
    Sélectionnez
    
    <?php
    if (!isset($_SERVER['HTTPS']) || $_SERVER['HTTPS'] != 'on') {
        header('Location: https://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI']);
        exit;
    }
Créé le 17 décembre 2008  par julp

A l'origine, et jusqu'à peu en ce qui concerne le module standard ssl, il n'était pas possible, de par la conception même du protocole SSL, d'avoir plusieurs hôtes virtuels pour une même adresse IP. Pourquoi ? Il s'agit tout simplement du paradoxe de l'oeuf et de la poule : le protocole SSL encapsule HTTP et implique, au préalable, une négociation entre le client et le serveur sur la façon dont ils vont ensuite communiquer de manière sécurisée. L'entête HTTP déterminant le virtualhost (Host) ne peut donc être lue à ce moment, le serveur doit, avant cela, convenir des paramètres de connexion HTTPS selon sa propre configuration et fournir son certificat. C'est ensuite, donc trop tard, que l'entête Host est lue. Apache n'a donc d'autre choix, dans un tel cas de figure, que de s'en remettre à un virtualhost par défaut (le premier de la liste).

Voici une caricature de la négociation :

 
Sélectionnez

_ client : (négociation TLS) Salut, je supporte telle et telle méthodes de chiffrement.
_ serveur : (négociation TLS) Bonjour, voici mon certificat public, nous allons utiliser tel algorithme de chiffrement.
_ client : (négociation TLS) ça me semble bon.
_ client : (chiffré) requête HTTP
_ serveur : (chiffré) réponse HTTP

Aujourd'hui, les versions récentes d'Apache (>= 2.2.12) et OpenSSL (>= 0.9.8j) (à moins d'avoir été patchés et/ou compilés à la main) implémente une solution qu'est l'extension appelée Server Name Indication (d'acronyme SNI, RFC 4366) du protocole SSL. Elle permet alors au client d'indiquer dès le départ, lors de la négociation SSL, le nom de domaine désiré. Le serveur est alors capable d'associer à la requête le bon hôte virtuel.

Illustration des échanges client/serveur avec SNI :

 
Sélectionnez

_ client : (négociation TLS) Salut, je supporte telle et telle méthodes de chiffrement, et je cherche à me connecter à 'www.exemple.fr'.
_ serveur : (négociation TLS) Bonjour, voici mon certificat public, nous allons utiliser tel algorithme de chiffrement.
_ client : (négociation TLS) ça me semble bon.
_ client : (chiffré) requête HTTP
_ serveur : (chiffré) réponse HTTP

Mais encore faut-il que le client supporte cette extension. A défaut, soit il sera dirigé sur le virtualhost par défaut (lorsque SSLStrictSNIVHostCheck est à off - comportement par défaut) soit il verra sa requête refusée (erreur 403 avec un message d'erreur indiquant son incapacité à prendre en charge SNI) lorsque SSLStrictSNIVHostCheck est à on.

Créé le 30 mars 2010  par julp

Si vous disposez déjà d'un hôte virtuel en HTTPS, vous pouvez contrôler le support de SNI via cet espace. En effet, le module SSL créera automatiquement, s'il est actif, une variable d'environnement interne à Apache appelée SSL_TLS_SNI, prenant pour valeur le nom de votre virtual host.

Comme pour la variable HTTPS, vue plus haut, vous indiquant ou non si la ressource a été appelée par le protocole sécurisé, il vous sera facile de l'exploiter via le module de réécriture, un programme CGI, en PHP, etc.

Un code PHP pour effectuer cette vérification :

 
Sélectionnez

<?php
if (isset($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) == 'on') {
    if (isset($_SERVER['SSL_TLS_SNI']) /*&& $_SERVER['SSL_TLS_SNI'] == $_SERVER['HTTP_HOST']*/) {
        echo "SNI est supporté par ce serveur";
    } else {
        echo "SNI n'est pas supporté sur ce serveur";
    }
} else {
    die("Ce script doit être exécuté en HTTPS.");
}
Créé le 30 mars 2010  par julp
  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2010 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.