Est-il possible de définir un protocole SSL dans Apache pour un seul VirtualHost (caniche)?

13

J'essaie de tester un correctif pour la vulnérabilité de caniche qui implique la désactivation de SSLv3 sur mon serveur Web. Afin de tester cela sur un environnement non-production d'abord, je configure le protocole SSL sur un VirtualHost pour un serveur de test différent. Ma configuration ressemble à ceci:

<VirtualHost *:443>
    SSLEngine On
    SSLProtocol All -SSLv2 -SSLv3
    ServerName test.mysite.com
    # bunch of other stuff omitted
</VirtualHost>

Cependant, même après le redémarrage d'apache, mon site de test est toujours considéré comme vulnérable. Est-ce que cela devrait fonctionner? Je me demande si je dois le définir dans la configuration globale SSL ou s'il y a quelque chose d'autre subtil qui empêche le paramètre de prendre et / ou de fonctionner.

— Cory
source

16

Vous ne pouvez définir le protocole SSL que pour le premier VirtualHost dans le fichier de configuration. Toutes les entrées VirtualHost suivantes hériteront de ce paramètre de la première entrée et ignoreront silencieusement leur propre paramètre en raison d'un bogue OpenSSL .

Il existe un rapport de bogue correspondant pour mod_ssl , mais comme décrit dans le rapport de bogue, le problème doit être résolu dans OpenSSL (le certificat est hérité mais pas les protocoles).

Les suites de chiffrement doivent être définies indépendamment pour chaque VirtualHost, sinon vous vous retrouverez avec la liste par défaut, y compris beaucoup de chiffrements non sécurisés. Sachez également que les anciens clients qui ne prennent pas en charge l'indication de nom de serveur (SNI) utiliseront toujours l'hôte par défaut (sauf s'ils sont bloqués à l'aide deSSLStrictSNIVHostCheck ), ce qui peut perturber vos tests.

En bref, vous devriez pouvoir spécifier des suites de chiffrement et des certificats personnalisés pour chaque hôte virtuel, mais tant que le bogue n'est pas corrigé, ne vous attendez pas à un comportement correct avec des protocoles personnalisés pour chaque hôte virtuel.

J'ai rencontré ce problème avec Apache 2.4 et modssl avec OpenSSL 1.0.1k, et je m'attends à ce qu'Apache 2.2 soit soumis aux mêmes problèmes.

Mise à jour (octobre 2016): le bogue OpenSSL a été marqué comme résolu le 13 octobre 2016. Cependant, il faisait partie d'une fermeture en masse de problèmes ouverts et bien qu'un «correctif partiel» ait été fourni, le problème n'a jamais été entièrement résolu.

Mise à jour (avril 2018): le bogue OpenSSL soumis à nouveau dispose désormais d'un correctif (à compter du 9 avril 2018). Ce correctif changera le comportement des instances Apache configurées avec plusieurs hôtes virtuels SNI:

Refuser les connexions non conformes au protocole SSL vhost

Ceci a été développé et testé avec 2.4.27 et en production avec cette version. Le patch a été modifié pour 2.4.33 et légèrement testé.

Cela vérifie la version de la connexion par rapport au protocole SSL configuré pour l'hôte virtuel qui est mis en correspondance en fonction du SNI. Étant donné que la connexion est initialement établie avec le protocole SSL configuré pour l'hôte par défaut du port, l'hôte par défaut doit inclure tous les protocoles qui seront pris en charge par n'importe quel hôte virtuel.

Ce correctif ajoute un état de retour supplémentaire APR_EMISMATCH à la fonction init_vhost afin que le rappel ssl_callback_ServerNameIndication enregistré avec OpenSSL puisse renvoyer l'alerte fatale SSL_AD_PROTOCOL_VERSION. Ceci est destiné à produire la même réponse au ClientHello que d'avoir un protocole SSL spécifié qui n'inclut pas la version en question. Parce que le rappel SNI est appelé pendant le traitement du ClientHello et avant qu'une réponse ne soit produite, il semble faire exactement cela.

Si vous voyez soudain des messages du format suivant:

Rejecting version [version] for servername [hostname]

Ensuite, vous devez vérifier votre SSLProtocolhôte par défaut.

— vallismortis
source

Les informations supplémentaires ajoutées par @anx concernant SSLStrictSNIVHostChecksont très appréciées. Cependant, il convient également de noter à partir de la documentation citée que si cette option est activée sur tout autre hôte virtuel, les clients ignorant SNI ne sont pas autorisés à accéder à cet hôte virtuel particulier .

— vallismortis

5

Vous pouvez avoir différents protocoles SSL pour chaque Vhost s'ils écoutent sur une IP différente.

Exemple avec un hôte spécifique autorisant TLSv1 et tous les autres autorisant uniquement TLSv1.1 et TLSv1.2 - et un autorisant uniquement TLSv1.2:

<VirtualHost *:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3 -TLSv1
  ServerName test.mysite.com
  # bunch of other stuff omitted
</VirtualHost>

<VirtualHost 10.0.0.2:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3
  ServerName test2.mysite.com
</VirtualHost>

<VirtualHost 10.0.0.3:443>
  SSLEngine On
  SSLProtocol TLSv1.2
  ServerName test2.mysite.com
</VirtualHost>

— BitLegacy01
source

De plus, si vous en avez besoin à des fins de test uniquement, vous pouvez utiliser un autre port au lieu d'une autre IP, par exemple un port HTTPS alternatif commun 8443.

— Esa Jokinen

0

Si vous utilisez l'indication de nom de serveur (SNI) avec votre vhost, en effet, vous ne pouvez pas définir plusieurs versions SSL.

Cependant, si vous utilisez un serveur dédié, vous pouvez probablement ajouter une autre adresse IP à votre serveur. De cette façon, vous pourrez utiliser une version SSL différente par IP. Il vous suffit de modifier vos paramètres vhost comme prévu IP: 443.

— tryp
source

-2

Ou vous pouvez utiliser:

SSLProtocol TLSv1 TLSv1.1 TLSv1.2

J'ai été testé sur de nombreux serveurs et travaille pour moi! Vous pouvez tester votre site sur ce site

— Rodrigo Moreno
source

4

Cette ligne SSLProtocol ne semble fonctionner que parce qu'Apache ne s'en plaint pas. En réalité, seul le protocole SSL de la première entrée VirtualHost est utilisé.

— vallismortis