Tous les sites doivent-ils utiliser SSL par défaut?

Nous sums en train de déplacer notre architecture Web vers un nouvel environnement. On y trouve des dizaines de sites différents allant de presque complètement statiques à des sites dynamics nécessitant une authentification et contenant du contenu sensible. Nos administrateurs de serveur Web ont décidé (sans aucune consortingbution de la part de l’équipe de développement) d’en faire un standard dans le nouvel environnement pour forcer le SSL pour tout. Je ne suis pas d’accord avec cette décision et j’aimerais avoir autant de connaissances que possible lorsque je m’assois pour en discuter. Voici ce que j’ai jusqu’à présent:

  • Pour chaque site, un certificate SSL a un coût direct. Nous avons un environnement dev, qa et prod et donc trois certificates sont nécessaires pour chaque site
  • Pour la majorité des pages, le contenu n’est pas sécurisé et forcer SSL rendrait les demandes de pages plus longues sur le serveur en raison du chiffrement et du déchiffrement
  • D’après ce que j’ai compris, la plupart des navigateurs ne mettent pas en cache les pages SSL ‘et, par conséquent, les demandes de pages prendront plus de temps.
  • Les anciens navigateurs ont des problèmes avec les téléchargements de fichiers lorsqu’ils sont sécurisés par SSL

Je n’ai aucun problème à forcer le protocole SSL lorsque les utilisateurs s’authentifient ou demandent des données sensibles. Cependant, je pense que forcer SSL par défaut sur tous les sites est un peu difficile.

SSL peut empêcher la mise en cache au niveau du réseau. Il existe des solutions à ce problème, mais cela peut signifier que plusieurs ordinateurs du même réseau doivent télécharger à nouveau les ressources de la page. Cela peut augmenter la charge du réseau aux deux extrémités. La mise en cache au niveau du navigateur n’est pas un problème dans les navigateurs modernes.

SSL complique l’utilisation des “domaines virtuels”. Traditionnellement, pour créer une connexion SSL, le navigateur et le serveur doivent travailler sur le même nom de domaine. Il était donc impossible d’héberger plusieurs certificates SSL sur une même adresse IP car le serveur répondrait avec un certificate incorrect. Les implémentations de l’ indication de nom de serveur (une extension du protocole TLS utilisé par SSL) ont résolu de nombreux problèmes.

Sur les performances pures, le chiffrement symésortingque et le contrôle de l’intégrité des données tunnelisées ne sont pas très coûteux. Si votre serveur ne peut pas chiffrer et déchiffrer à la vitesse du réseau, alors vous avez soit la fibre optique de Dieu, soit vous devriez penser à remplacer ces i486. Cependant, l’initialisation d’une connexion SSL, appelée “handshake”, est un peu plus coûteuse et peut impliquer un goulot d’étranglement sur les charges lourdes (lorsqu’il y a des centaines de connexions par seconde ou plus). Heureusement, une instance de navigateur donnée réutilisera les tunnels et les sessions SSL, ce qui ne pose aucun problème si vous ne disposez que de quelques dizaines d’utilisateurs.

Globalement, placer le SSL partout semble être un moyen d’obtenir un «sentiment de confusion» sur la sécurité. Ce n’est pas bien. Cela signifie généralement qu’en se concentrant sur les éléments non pertinents, les administrateurs seront plus enclins à ignorer les problèmes de sécurité réels. Ils rendront également le système plus complexe à entretenir, rendant plus difficile le diagnostic et la correction des problèmes. Notez que du sharepoint vue des administrateurs, cela rend leur travail plus sûr, car cela augmente le coût de les licencier et de les remplacer.

En réponse à la réponse de Thomas :

Pour chaque site, un certificate SSL a un coût direct. Nous avons un environnement dev, qa et prod et donc trois certificates sont nécessaires pour chaque site

À peine vrai Vous n’avez pas besoin d’avoir tous les dev et qa derrière SSL avec des certificates valides et actuels. Vous souhaitez peut-être un site de transit avec un certificate valide. Mais au-delà du serveur frontal Apache, votre back-end ne doit pas savoir que le protocole SSL est impliqué. Vous ne testez rien de particulier ou de spécial en achetant des certificates de développement.

En outre, le coût est nominal. Vous dépensez plus d’argent sur la conversation que le coût réel des certificates.

Pour la majorité des pages, le contenu n’est pas sécurisé et forcer SSL rendrait les demandes de pages plus longues sur le serveur en raison du chiffrement et du déchiffrement

Un peu. Avez-vous mesuré? Vous trouverez peut-être que c’est difficile à mesurer, car la variabilité des débits Internet dépasse le coût du traitement SSL.

D’après ce que j’ai compris, la plupart des navigateurs ne mettent pas en cache les pages SSL ‘et, par conséquent, les demandes de pages prendront plus de temps.

Encore une fois, avez-vous mesuré cela?

Les anciens navigateurs ont des problèmes avec les téléchargements de fichiers lorsqu’ils sont sécurisés par SSL

Vraiment? Quel “navigateur plus ancien” spécifique prévoyez-vous de prendre en charge ce problème? Si vous ne pouvez pas en trouver et que vous pensez que quelqu’un, quelque part, pourrait avoir ce problème, vous pourriez être trop ingénieux. Vérifiez vos journaux et voyez quels navigateurs vos clients utilisent réellement , puis déterminez si vous avez un problème.

Je suis d’accord que “SSL partout” n’est pas une très bonne approche. Je pense que vous avez besoin d’au moins une page “bienvenue” de port-80 non-SSL. Mais je ne suis pas sûr que vos problèmes actuels soient solides. Je pense que vous avez besoin de beaucoup plus de mesures pour démontrer que le protocole SSL implique des coûts réels ou des performances réelles.