Gestion des sites SSL à petite échelle
Bonjour les gens, J'aurais à gérer un nombre un peu plus important de sites SSL qu'actuellement mais de façon assez modeste, disons quelques dizaines. Chaque site aura son propre certificat SSL. Il n'y a pas de gros volume, ni un trafic très important, mais je ne dispose pas non plus de serveurs ultra puissants. Ça sera certainement installé sur un serveur virtualisé. La question porte sur la mise en oeuvre de tout ça. Peut-on raisonnablement envisager une gestion des serveurs web virtuels dans une telle config ? Ou au contraire prévoir systématiquement une IP par serveur web ssl (ça fait riche !) ? Plutôt utiliser Apache2 avec des modules PHP ou au contraire un Nginx avec fpm ? Vos remarques, suggestions, retours d’expérience sont les bienvenues ! Merci par avance. -- Cordialement, Artur.
'jour,
Peut-on raisonnablement envisager une gestion des serveurs web virtuels dans une telle config ?
Moi je dirai oui, avec HAProxy en frontal SSL (et pas que). La gestion est simple, tous les certificats dans un dossier et HAProxy trouve tout seul le bon à utiliser.
Ou au contraire prévoir systématiquement une IP par serveur web ssl (ça fait riche !) ?
Le SNI est géré par HAProxy mais pas par tous les clients (en particulier sous XP). David
Pourquoi faire compliquer ? Apache2 avec SNI et hop, 2 IP pour tout le monde à grand coup de virtualhost Le SNI est utilisable par tout les navigateurs utilisables.. si ton client ne supporte pas le SNI, tu ne devrais pas l'utiliser ! (ie6 etc) On 01/04/2015 12:07, Artur wrote:
Bonjour les gens,
J'aurais à gérer un nombre un peu plus important de sites SSL qu'actuellement mais de façon assez modeste, disons quelques dizaines. Chaque site aura son propre certificat SSL. Il n'y a pas de gros volume, ni un trafic très important, mais je ne dispose pas non plus de serveurs ultra puissants. Ça sera certainement installé sur un serveur virtualisé.
La question porte sur la mise en oeuvre de tout ça. Peut-on raisonnablement envisager une gestion des serveurs web virtuels dans une telle config ? Ou au contraire prévoir systématiquement une IP par serveur web ssl (ça fait riche !) ? Plutôt utiliser Apache2 avec des modules PHP ou au contraire un Nginx avec fpm ? Vos remarques, suggestions, retours d’expérience sont les bienvenues ! Merci par avance.
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
Le Wed, Apr 01, 2015 at 12:07:22PM +0200, Artur [frsag@pydo.org] a écrit: [...]
La question porte sur la mise en oeuvre de tout ça. Peut-on raisonnablement envisager une gestion des serveurs web virtuels dans une telle config ? Ou au contraire prévoir systématiquement une IP par serveur web ssl (ça fait riche !) ?
De nos jours, avec SNI, c'est faisable. En gros, à part les Windows XP, tout le monde peut disposer d'un navigateur comptaible : https://en.wikipedia.org/wiki/Server_Name_Indication#Implementation
Plutôt utiliser Apache2 avec des modules PHP ou au contraire un Nginx avec fpm ?
La même conf que celle que tu fais quand tu n'utilise pas de SSL ! (puisque c'est celle que tu connais) Selon le besoin, un "simple" reverse-proxy qui transfère les requetes arrivant sur un frontal HTTPS dédié vers le/s serveur/s hébegeant habituellement des sites. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
ne pas oublier un truc, normalement les IE sur XP ne devraient même plus pouvoir naviguer sur le SSL, avec poodle tout le monde a raisonnablement désactivé SSLv3, et TLS 1.0 est désactivé par défaut dans IE. Donc normalement, if IE + Win XP = Pas HTTPS. Donc SNI ou pas, ça changera pas le problème... Le 01/04/2015 12:19, Dominique Rousseau a écrit :
Le Wed, Apr 01, 2015 at 12:07:22PM +0200, Artur [frsag@pydo.org] a écrit: [...]
La question porte sur la mise en oeuvre de tout ça. Peut-on raisonnablement envisager une gestion des serveurs web virtuels dans une telle config ? Ou au contraire prévoir systématiquement une IP par serveur web ssl (ça fait riche !) ? De nos jours, avec SNI, c'est faisable. En gros, à part les Windows XP, tout le monde peut disposer d'un navigateur comptaible :
https://en.wikipedia.org/wiki/Server_Name_Indication#Implementation
Plutôt utiliser Apache2 avec des modules PHP ou au contraire un Nginx avec fpm ? La même conf que celle que tu fais quand tu n'utilise pas de SSL ! (puisque c'est celle que tu connais)
Selon le besoin, un "simple" reverse-proxy qui transfère les requetes arrivant sur un frontal HTTPS dédié vers le/s serveur/s hébegeant habituellement des sites.
2015-04-01 12:24 GMT+02:00 Pierre DOLIDON <sn4ky@sn4ky.net>:
ne pas oublier un truc, normalement les IE sur XP ne devraient même plus pouvoir naviguer sur le SSL, avec poodle tout le monde a raisonnablement désactivé SSLv3, et TLS 1.0 est désactivé par défaut dans IE. Donc normalement, if IE + Win XP = Pas HTTPS.
Bonjour, Poudle n'est que sur SSLv3. TLS1.0, bien que très proche de SSLv3 n'est pas touché. HAProxy permet de bloquer/rediriger les utilisateurs en SSLv3, sans affecter ceux utilisant TLS1.0. Baptiste
Pour avoir un peut le même besoin, je gére ça via du nginx + php-fpm. Cela demande un peu de config (surtout pour les projets libres qui fournissent souvent une conf apache) mais il me semble que cela tient mieux la charge dans ce type d'usage. Cordialement Alexis Lameire Le 1 avril 2015 12:24, Pierre DOLIDON <sn4ky@sn4ky.net> a écrit :
ne pas oublier un truc, normalement les IE sur XP ne devraient même plus pouvoir naviguer sur le SSL, avec poodle tout le monde a raisonnablement désactivé SSLv3, et TLS 1.0 est désactivé par défaut dans IE. Donc normalement, if IE + Win XP = Pas HTTPS.
Donc SNI ou pas, ça changera pas le problème...
Le 01/04/2015 12:19, Dominique Rousseau a écrit :
Le Wed, Apr 01, 2015 at 12:07:22PM +0200, Artur [frsag@pydo.org] a écrit: [...]
La question porte sur la mise en oeuvre de tout ça. Peut-on raisonnablement envisager une gestion des serveurs web virtuels dans une telle config ? Ou au contraire prévoir systématiquement une IP par serveur web ssl (ça fait riche !) ?
De nos jours, avec SNI, c'est faisable. En gros, à part les Windows XP, tout le monde peut disposer d'un navigateur comptaible :
https://en.wikipedia.org/wiki/Server_Name_Indication#Implementation
Plutôt utiliser Apache2 avec des modules PHP ou au contraire un Nginx
avec fpm ?
La même conf que celle que tu fais quand tu n'utilise pas de SSL ! (puisque c'est celle que tu connais)
Selon le besoin, un "simple" reverse-proxy qui transfère les requetes arrivant sur un frontal HTTPS dédié vers le/s serveur/s hébegeant habituellement des sites.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
D'après ce que je sais, la suppression d'SSL v3 n'interdit que IE6 + XP, mais on peut avoir des IE plus récents sous XP. Et SSLLabs indique que IE8 + XP gère le TLS par défaut, mais pas le SNI, donc si ça change le problème. Le 1 avril 2015 12:24, Pierre DOLIDON <sn4ky@sn4ky.net> a écrit :
ne pas oublier un truc, normalement les IE sur XP ne devraient même plus pouvoir naviguer sur le SSL, avec poodle tout le monde a raisonnablement désactivé SSLv3, et TLS 1.0 est désactivé par défaut dans IE. Donc normalement, if IE + Win XP = Pas HTTPS.
Donc SNI ou pas, ça changera pas le problème...
Le 01/04/2015 12:19, Dominique Rousseau a écrit :
Le Wed, Apr 01, 2015 at 12:07:22PM +0200, Artur [frsag@pydo.org] a écrit: [...]
La question porte sur la mise en oeuvre de tout ça. Peut-on raisonnablement envisager une gestion des serveurs web virtuels dans une telle config ? Ou au contraire prévoir systématiquement une IP par serveur web ssl (ça fait riche !) ?
De nos jours, avec SNI, c'est faisable. En gros, à part les Windows XP, tout le monde peut disposer d'un navigateur comptaible :
https://en.wikipedia.org/wiki/Server_Name_Indication#Implementation
Plutôt utiliser Apache2 avec des modules PHP ou au contraire un Nginx
avec fpm ?
La même conf que celle que tu fais quand tu n'utilise pas de SSL ! (puisque c'est celle que tu connais)
Selon le besoin, un "simple" reverse-proxy qui transfère les requetes arrivant sur un frontal HTTPS dédié vers le/s serveur/s hébegeant habituellement des sites.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
2015-04-01 14:18 GMT+02:00 Antoine Benoit <antoine.benoit@gmail.com>:
D'après ce que je sais, la suppression d'SSL v3 n'interdit que IE6 + XP, mais on peut avoir des IE plus récents sous XP. Et SSLLabs indique que IE8 + XP gère le TLS par défaut, mais pas le SNI, donc si ça change le problème.
HAProxy peut gérer un certificat par "défaut" pour les gens qui n'enverraient pas le SNI. En plus, HAProxy peut logger le SNI (et pleins d'autres info du SSL, comme la version du TLS et le cipher utilisé), mais aussi le user-agent HTTP. Ca permet de faire un "audit" et de savoir si certains site ont 100% de clients "compatibles" SNI (car ils l'ont envoyé) et donc migrables sur une même IP. Baptiste
Cette solution est il me semble la plus "propre". Si le client n'a pas de navigateur/plateforme compatible SNI --> on le route vers une page/vhost qui lui demande de mettre à jour son navigateur. Finalement c'est plutôt politique que technique... Le 1 avril 2015 14:23, Baptiste <bedis9@gmail.com> a écrit :
2015-04-01 14:18 GMT+02:00 Antoine Benoit <antoine.benoit@gmail.com>:
D'après ce que je sais, la suppression d'SSL v3 n'interdit que IE6 + XP, mais on peut avoir des IE plus récents sous XP. Et SSLLabs indique que IE8 + XP gère le TLS par défaut, mais pas le SNI, donc si ça change le problème.
HAProxy peut gérer un certificat par "défaut" pour les gens qui n'enverraient pas le SNI. En plus, HAProxy peut logger le SNI (et pleins d'autres info du SSL, comme la version du TLS et le cipher utilisé), mais aussi le user-agent HTTP. Ca permet de faire un "audit" et de savoir si certains site ont 100% de clients "compatibles" SNI (car ils l'ont envoyé) et donc migrables sur une même IP.
Baptiste _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Cordialement. Manuel Ozan
Juste une remarque là dessus : pour ceux qui ne sont pas compatibles SNI, ils auront un certificat serveur qui ne correspond pas à leur site, donc potentiellement ils n'arriveront pas sur la page qui demande à mettre à jour car ils ne passeront pas outre la popup de sécurité du navigateur. A avoir en tête pour le choix. Et pour le certificat "par défaut" à utiliser pour eux, il vaut mieux qu'il soit neutre pour ne pas afficher le certificat d'un des vrais sites quand on se connecte à un autre. Autre note : le navigateur par défaut sur Android 2.3 ne gère pas non plus le SNI. A voir si cela représente une proportion non négligeable de la cible. Le 1 avril 2015 14:34, Manuel OZAN <manuelozan@gmail.com> a écrit :
Cette solution est il me semble la plus "propre". Si le client n'a pas de navigateur/plateforme compatible SNI --> on le route vers une page/vhost qui lui demande de mettre à jour son navigateur.
Finalement c'est plutôt politique que technique...
Le 1 avril 2015 14:23, Baptiste <bedis9@gmail.com> a écrit :
2015-04-01 14:18 GMT+02:00 Antoine Benoit <antoine.benoit@gmail.com>:
D'après ce que je sais, la suppression d'SSL v3 n'interdit que IE6 + XP, mais on peut avoir des IE plus récents sous XP. Et SSLLabs indique que IE8 + XP gère le TLS par défaut, mais pas le SNI, donc si ça change le problème.
HAProxy peut gérer un certificat par "défaut" pour les gens qui n'enverraient pas le SNI. En plus, HAProxy peut logger le SNI (et pleins d'autres info du SSL, comme la version du TLS et le cipher utilisé), mais aussi le user-agent HTTP. Ca permet de faire un "audit" et de savoir si certains site ont 100% de clients "compatibles" SNI (car ils l'ont envoyé) et donc migrables sur une même IP.
Baptiste _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Cordialement.
Manuel Ozan
Merci pour vos réponses. Si je fais une synthèse un peu subjective cela donne : - SSL avec SNI peut être retenu si on fait l'impasse sur quelques versions de navigateurs plutôt anciens - Du coup on fait du virtual host avec une seule adresse IP - HAProxy, bien, mais comme je ne le connais pas et cela rajoute un chainon supplémentaire je l'élimine dans l'immédiat - Plutôt Nginx que Apache2, je connais les deux, Nginx est moins lourd qu'Apache2 -- Cordialement, Artur.
Bonsoir, Pour ma part j'utilise Apache2 avec le gestionnaire d'hébergement AlternC qui est très facile d'emploi et de mise en oeuvre, actuellement je gère les certificats à la main mais AlternC a déjà toute la configuration TLS nécessaire. Florian On 01. 04. 15 16:12, Artur wrote:
Merci pour vos réponses.
Si je fais une synthèse un peu subjective cela donne : - SSL avec SNI peut être retenu si on fait l'impasse sur quelques versions de navigateurs plutôt anciens - Du coup on fait du virtual host avec une seule adresse IP - HAProxy, bien, mais comme je ne le connais pas et cela rajoute un chainon supplémentaire je l'élimine dans l'immédiat - Plutôt Nginx que Apache2, je connais les deux, Nginx est moins lourd qu'Apache2
participants (10)
-
Alexis Lameire -
Antoine Benoit -
Artur -
Baptiste -
David Touitou -
Dominique Rousseau -
Florian Siegenthaler -
frsag＠jack.fr.eu.org -
Manuel OZAN -
Pierre DOLIDON