Si tous les sites utiliser SSL par défaut?

Question

Nous sommes en train de déplacer notre architecture web à un nouvel environnement. On y trouve des dizaines de sites différents allant de presque complètement statique à des sites dynamiques nécessitant une authentification et un contenu sensible. Nos administrateurs de serveurs Web ont (sans aucune intervention de l'équipe de développement) a décidé d'en faire une norme dans le nouvel environnement à la force pour tout SSL. Je ne suis pas d'accord avec cette décision et je voudrais avoir autant de connaissances que possible quand je me mets à en discuter. Voici ce que j'ai à ce jour:

• Pour chaque site, un certificat SSL a un coût direct. Nous avons un dev, qa et de l'environnement de prod et donc qui est trois certificats qui sont nécessaires pour chaque site
• Pour la majorité des pages, le contenu est pas sécurisé et forcer SSL rendrait les demandes de page prennent plus de temps sur le serveur à cause de chiffrement et de déchiffrement
• D'après ce que je comprends, la plupart des navigateurs à ne proposent pas en cache les pages qui sont SSL'ed et donc à nouveau, les demandes de page prendront plus
• Les navigateurs plus anciens ont des problèmes avec les téléchargements de fichiers quand ils sont SSL'ed

Je n'ai pas un problème avec force SSL lorsque les utilisateurs sont authentifiés ou ils demandent des données sensibles. Cependant, je pense que forcer SSL par défaut sur tous les sites est un peu beaucoup.

Answer 1

SSL

peut inhiber la mise en cache au niveau du réseau. Il y a des solutions de contournement à cela, mais cela peut signifier que plusieurs ordinateurs du même réseau ont des ressources de la page de re-téléchargement. 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 soi-disant « domaines virtuels ». Traditionnellement, afin de former une connexion SSL le navigateur et le serveur doivent travailler au même nom de domaine. Cela a rendu impossible d'accueillir plus d'un certificat SSL sur une seule adresse IP car le serveur répondrait avec le mauvais certificat. Les implémentations de href="http://en.wikipedia.org/wiki/Server_Name_Indication" Nom du serveur Indication (une extension du protocole TLS SSL utilise) a fixé de nombreux des problèmes avec cela.

Sur la performance pure, la vérification de chiffrement symétrique et de l'intégrité des données est tunneling pas très cher; si votre serveur ne peut pas chiffrer et déchiffrer à la vitesse de réseau, soit vous avez propre fibre optique de Dieu, ou vous devriez penser à remplacer ces i486. Cependant, l'ouverture d'une connexion SSL, appelée « poignée de main », est un peu plus cher, et peut impliquer un goulot d'étranglement sur les charges lourdes (quand il y a des centaines de connexions par seconde ou plus). Heureusement, une instance de navigateur donné réutilisera les tunnels et les sessions SSL, donc ce n'est pas un problème si vous avez seulement quelques dizaines d'utilisateurs.

Dans l'ensemble, en mettant SSL ressemble partout comme un moyen d'obtenir un « sentiment positif » sur la sécurité. Ce n'est pas bien. Cela signifie généralement que, en se concentrant sur la non pertinente, les administrateurs seront plus susceptibles de ne pas tenir compte des problèmes de sécurité réels. Ils seront également rendre le système plus complexe à maintenir, le rendant plus difficile à diagnostiquer et corriger les problèmes. Notez que du point de vue des administrateurs, ce qui rend leur travail plus sûr, car il augmente le coût de leur mise à feu et de les remplacer.

Answer 2

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

  

Pour chaque site, un certificat SSL a un coût direct. Nous avons un dev, qa et de l'environnement de prod et donc qui est trois certificats qui sont nécessaires pour chaque site

A peine vrai. Vous n'avez pas besoin d'avoir chaque dev et qa derrière SSL avec des certificats valides, en cours. Vous - peut-être - voulez un site de mise en scène avec un certificat valide. Mais au-delà du front-end Apache, votre back-end ne devrait pas savoir qu'il ya SSL impliqué. Vous n'êtes pas tester quelque chose d'unique ou spécial en achetant des certificats dev.

En outre, le coût est minime. Vous dépensez plus d'argent sur la conversation que les certificats coût réel.

  

Pour la majorité des pages, le contenu n'est pas sûr et forcer SSL rendrait les demandes de page prennent plus de temps sur le serveur à cause de chiffrement et de déchiffrement

Un peu. Avez-vous mesuré? Vous trouverez peut-être qu'il est difficile à mesurer, car la variabilité d'Internet accélère atout le coût du traitement SSL.

  

D'après ce que je comprends, la plupart des navigateurs à ne proposent pas en cache les pages qui sont SSL'ed et donc à nouveau, les demandes de page prendront plus

Encore une fois, avez-vous mesuré cela?

  

Les navigateurs plus anciens ont des problèmes avec les téléchargements de fichiers quand ils sont SSL'ed

Vraiment? Ce qui spécifique « ancien navigateur » vous prévoyez de soutenir qui a ce problème? Si vous ne trouvez pas un et pensent que quelqu'un, quelque part pourrait avoir ce problème, vous pouvez overengineering. Vérifiez vos journaux et de voir ce que les navigateurs vos clients en fait utiliser, puis déterminer 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 un port-80 non-SSL page « bienvenue ». Mais je ne suis pas sûr que votre ensemble actuel de questions sont des raisons solides. Je pense que vous avez besoin des mesures beaucoup plus pour faire valoir que SSL implique en réalité le coût réel ou de véritables hits de performance.

Answer 3

A partir de 2012, Les sites doivent utiliser SSL uniquement si elles ont personnellement identifiables (PII) ou des informations commercialement importantes, ou si elles ont un concept de connexion.

Les sites qui publient seulement une faible valeur, l'information du public readonly faible confiance sont un peu défendables, mais pourrait probablement encore servir utilement tout HTTPS. Les pirates peuvent essayer d'insérer des logiciels malveillants ou des logiciels publicitaires ou réoriente, dans le contenu HTTP.

Une politique d'entreprise de "tout sur SSL, sans une exemption spécifique" est raisonnable.

Vous devriez également consulter le déploiement HTTP Strict Transport sécurité pour vous assurer que même la première demande de l'utilisateur de taper example.com est envoyé via le protocole HTTPS.

attaques Man-in-the-middle sont un problème réel, en particulier sur les réseaux wifi, mais aussi au niveau du FAI et le pays. Si vous faites seulement la phase de connexion via SSL et passez ensuite un cookie de session non chiffrée, ce cookie de session sera volé. Voir Firesheep pour une démonstration claire.

SSL est en toute sécurité cacheable par utilisateur, que ce soit pour la session ou indéfiniment. caches proxy-end du client sont maintenant rares et l'optimisation pour ce cas est pas important. Quand ils existent, ils obtiennent souvent des choses mauvaises et les contourner par SSL est utile.

SSL correctement mis en œuvre ou SPDY peut être rapide: la surcharge du serveur n'est pas élevé et est facilement déplacé sur une machine proxy inverse séparée. Il y a CDNs SSL.

Il n'y a pas besoin d'acheter de vrais certificats pour les sites qui ne sont que pour les développeurs et les testeurs. Le coût des certificats, des dizaines faibles de dollars, est négligeable même pour les sites non commerciaux.

Cryptage des données à travers le réseau est une couche utile de défense en profondeur. De toute évidence, il ne suffit pas par lui-même pour rendre le service sécurisé, mais il élimine certains types de problèmes et a un faible coût.

Même pour les données en lecture seule, il y a valeur des clients sachant qu'ils obtiennent le site authentique:. Par exemple, si elles téléchargent les fichiers binaires que vous ne voulez pas trojans à insérer

distinguer en toute sécurité les pages qui doivent être sur SSL de ceux qui ne prend pas l'effort de développement qui pourrait être presque certainement mieux utilisé.

Faire des normes pour les systèmes d'un carcan divers, en particulier sans consultation, est jamais bon. Mais dire que les sites devraient tous être sur SSL à moins d'une raison particulière de faire autrement dans un cas est logique pour moi. De bons exemples d'exceptions au cas par cas, où vous devez offrir encore SSL, mais pas forcer une redirection:

• le site sert les téléchargements volumineux binaires (musique / vidéo / distributions de logiciels) permettant ainsi la mise en cache plus et des téléchargements plus rapides est important (les données montrent)
• les clients sont archaïques ou IE clients intégrés qui ne peuvent tout simplement pas faire SSL correctement (encore une fois, il est en fait montrent un problème)
• il y a de très nombreuses ressources sur le site et que vous voulez les robots à indexer via HTTPS

Si vous utilisez SSL partout où vous utiliserez quelques ressources de la machine, de manière qui peuvent être optimisés si elles deviennent importantes. Si vous ne l'utilisez SSL, soit vous passez plus de ressources pour les développeurs de considérer la sécurité au cas par cas, ou tout à fait probable que vous serez plus enclin à tenir compte du vol.

Adam Langley de Google écrit en 2010 :

  

S'il y a un point que nous voulons communiquer au monde, il est que le protocole SSL / TLS est pas cher informatiquement plus. Il y a dix ans, il aurait pu être vrai, mais il est tout simplement pas le cas plus. Vous aussi pouvez vous permettre de permettre le protocole HTTPS est utilisateurs.

     

En Janvier de cette année (2010), Gmail commencé à utiliser le protocole HTTPS pour tout par défaut. Auparavant, il avait étéprésenté comme une option, mais maintenant utiliser tous nos utilisateurs HTTPS pour sécuriser leur courrier électronique entre leur navigateur et Google, tout le temps. Pour ce faire, nous avons dû déployer pas de machines supplémentaires et pas de matériel spécial. Sur nos machines frontend de production, les comptes SSL / TLS pour moins de 1% de la charge CPU, moins de 10 Ko de mémoire par connexion et moins de 2% des frais généraux du réseau. Beaucoup de gens croient que le protocole SSL prend beaucoup de temps CPU et nous espérons que les chiffres ci-dessus (public pour la première fois) contribuera à dissiper que.

Answer 4

J'ai vu des fantastiques réponses à cette question, mais après quelques jours, j'ai vu qu'il ya quelques petites choses manquantes . Par conséquent, il y a deux ou trois choses que je veux mentionner:

Pourquoi utiliser SSL sur tout

• Sécurité - Si seulement quelques pages sont cryptées SSL, il est plus facile de « renifler » quelles pages contiennent des données sensibles. Maintenant SSL est assez goddamn sûr, donc ce n'est pas quelque chose à craindre, mais dans le cas où votre clé privée est compromis, il est bon d'avoir cette couche supplémentaire de sécurité pour qu'il soit plus difficile pour les méchants pour obtenir au trucs juteux.
• Trustworthiness - Il y a des gens qui prétendent que lorsque vous visitez un site qui a un certificat vérifié, il est plus facile de faire confiance. Étant donné qu'un certificat coûte vérifié l'argent, il est plus facile de faire confiance à un site sachant que le propriétaire a investi dans un symbole de confiance.
• Hassle - tout inertage sous SSL est tellement plus facile. Tout ce que vous devez faire est de couper le http: au début de chaque lien de ressources et vous êtes bien.
• Configuration SEO - Vous n'aurez pas à se soucier du tout avec la configuration de SEO. J'ai entendu dire que les moteurs de recherche indexent http:// et https:// comme entrées distinctes, donc pour la cohérence (dans les deux SEO et le comportement de la page), inertage SSL sur tout et mettre juste une redirection 301 semble être une belle solution facile.
• Cohérence - Vous avez un site web beaucoup plus cohérent si vous https:// que tout. Beaucoup de cadres rompent lorsque vous essayez de faire un hybride de SSL et non-SSL. En plus de cela, les plugins en fonction de l'URL et le code seront vraiment dire si vous essayez de rebondir et-vient entre http et https.
• Fuzzy sentir en sécurité -. Il faut admettre que peu barre verte en haut à gauche qui dit « domaine vérifié » est juste un putain de bon sentiment

Pourquoi ne pas SSL Tout

• Vitesse - SSL est plus lent. Pas de beaucoup, bien sûr, et la plupart du temps le coût est négligeable. Il est un fait inévitable, cependant, que le protocole SSL sera toujours plus lent.
• Compatibilité navigateur - Ceci est probablement négligeable, mais si vous voulez soutenir vraiment anciens navigateurs qui ne met pas en cache sur SSL, vous devrez coller avec le port 80.
• Plugins - Un tas de plugins ne fonctionnent pas correctement sur SSL, vous devrez faire attention à cela. Si jamais vous voulez ajouter un nouveau plugin, vous devrez reconfigurer vos paramètres SSL ou chercher un autre plug-in.
• Professionnalisme - Maintenant, bien que certaines personnes affirment que voir un domaine SSL Verified semble digne de confiance, d'autres le considèrent comme une solution très amateur et paresseux. En fait, il est vraiment facile et pas cher (m'a coûté environ 10 $) pour obtenir un certificat SSL vérifié qui frappe jusqu'à 96% des navigateurs!
• Hassle - Je ne dis qu'il est plus facile de SSL tout, mais en même temps, vous allez devoir faire en sorte que chaque ressource est chargée par https:// (ou faire la http:// -> // solution rapide ). Il peut être un peu fastidieux si vous avez un tas de liens ou même incompatibles si vous avez du contenu soumis par les utilisateurs hébergé sur un site qui ne prend pas en charge SSL. Dans ces cas, votre navigateur pleurnicher à vous. Si vous avez déjà vu cet avis qui dit: « Cette page a un contenu non sécurisé », vous saurez comment blessants et à quel point cette apparence.

Donc en bref, il est vraiment la situation, mais j'ai tendance à éviter inertage SSL. Bien sûr, cela prend un peu plus de configuration, mais à la fin vous obtenez un système beaucoup plus flexible. Personnellement, je pense toute chose de « professionnalisme » est des conneries (de tout Twitter et Google SSL). Toutefois, si vous avez excontenu hébergé ternally ou contenu affiché par l'utilisateur, il est généralement une très mauvaise idée à tout SSL. Vous pouvez également commencer tout SSL-ing et courir dans un tas de problèmes.

Mais c'est juste moi. : D

Answer 5

Cette première chose à vous demander, qu'est-ce que SSL vous achetez? Il vous permet d'acheter l'assurance que personne et aucune application ne peut « renifler » le trafic et voir ce qui se passe entre le serveur Web et le navigateur. Le coût est le coût réel de l'achat d'un certificat SSL, et le coût d'aller d'une légère augmentation de la vitesse de téléchargement. Vous mentionnez que le navigateur plus ont le téléchargement des fichiers de trouble sur la communication SSL. Je ne peux pas répondre à cette question, et je ne me préoccuper trop avec cela. D'un point de support de sécurité, vous avez une autre préoccupation. pare-feu modernes surveillent le trafic à la recherche de diverses tentatives de piratage. SSL empêche le pare-feu de moniteur que la communication, de sorte que le développeur d'applications / web-admin doit être encore plus soucieux de protéger leur application et les sites de diverses tentatives de piratage. Longue histoire courte, on ne devrait chiffrer les communications qui ont vraiment besoin.

Answer 6

Dans une autre réponse à la réponse Thomas, d'autant qu'il est sur le dessus.

En outre, plus bas que je livre blanc avec les meilleures pratiques pour SSL .

  

SSL empêche la mise en cache, non seulement des navigateurs, mais aussi des serveurs proxy. Chaque page Web   élément devra être envoyé par votre serveur principal, encore et encore. Cela augmente réseau   charge.

que partiellement vrai. SSL empêche la mise en cache proxy, mais pas mise en cache du navigateur - voir aussi les réponses à cette question. Pas un gros problème à mon avis.

  

SSL empêche l'utilisation de soi-disant « domaines virtuels ». [...]

Ceci est partiellement vrai. Cependant, les domaines virtuels fonctionnera bien aussi longtemps que vous avez un seul certificat. Même si vous n'êtes pas, Nom du serveur Indication (SNI) devrait être une alternative viable (ou devrait être, une fois que Windows XP est la face de la planète).

  

[performances] Cependant, l'ouverture d'une connexion SSL, appelée « poignée de main », est un peu plus cher,> et peut impliquer un goulot d'étranglement sur les charges lourdes (quand il y a des centaines de connexions par seconde ou plus) . Heureusement, une instance de navigateur donné réutilisera les tunnels   et des sessions SSL, donc ce n'est pas un problème si vous avez seulement quelques dizaines d'utilisateurs.

Même la poignée de main ne devrait pas causer de problèmes de performances sur le côté serveur si vous disposez d'un matériel moderne. La raison principale de la poignée de main étant « lente » est due au fait que les paquets de réseau doivent être envoyés avant et en arrière à quelques reprises entre le serveur et le navigateur - la puissance de calcul n'a rien à voir avec elle.

Pour le dire d'une autre manière:. Configuration de la connexion SSL sera un ordre de grandeur moins cher que le rendu d'une page PHP qui récupère des données à partir d'une base de données

  

Dans l'ensemble, en mettant SSL ressemble partout comme un moyen d'obtenir un « sentiment positif » sur la sécurité. > Ce n'est pas bon. Cela signifie généralement que, en se concentrant sur la non pertinente,

pas vrai . Soit vous n'avez pas besoin du tout SSL sur votre site, car il est tout à fait le contenu public. Ou vous avez besoin SSL pour une raison quelconque (connexions utilisateur, zones protégées). Dans ce cas, la meilleure pratique est de mettre partout.

Avoir SSL uniquement sur les parties de votre page peut vous ouvrir à toutes sortes de risques obscurs. Et pendant que vous pouvez trouver et atténuer ceux d'une autre manière, est sera plus complexe, sujette aux erreurs et de temps que d'avoir simplement SSL activé sur toutes les pages.

J'ai trouvé ce livre blanc sur SSL . Je ne suis pas affilié à la société qui en est l'auteur, mais je l'ai trouvé un résumé très concis de toutes les choses que vous devez garder à l'esprit lors du déploiement d'une configuration SSL.

Cette sécurité a plus d'un composant va sans dire. Mais déjà gagné le premier mal est pas un bon début.

Answer 7

Je ne pense pas que vous devez SSL tous vos sites et certainement vous ne pas besoin d'acheter certs pour vos environnements de dev. Si vous voulez / besoin d'un certificat SSL pour dev il peut être facilement généré et que, dans la plupart des cas seraient enought pour cet environnement. L'autre possibilité est que vous pouvez acheter un certificat générique et que vous définissez dev serveurs dans l'un des sous-domaines, de cette façon vous pouvez avoir le même certificat pour les deux environnements mais encore une fois: il est un gaspillage d'argent si vous achetez un certificat générique (qui sont plus cher) juste pour avoir le travail de dev sur aussi bien. Il est logique si vous avez plusieurs sous-domaines sur prod qui doit être SSLed.

En ce qui concerne la vitesse: oui, il y a un peu d'un problème, mais pas significatif. réponses SSL ne sont pas mises en cache afin de les utiliser augmentera vos serveurs charge un peu mais je pense que cela est la partie qui doit être administrateur au courant.