Devrait tous les sites de l'utilisation de SSL par défaut?

Question

Nous sommes dans le processus de déplacement de notre architecture web à un nouvel environnement. Sont inclus des dizaines de sites différents, allant de presque complètement statique à la dynamique des sites nécessitant une authentification et contenant des informations sensibles. Notre serveur web admins ont (sans aucun apport de l'équipe de développement) a décidé d'en faire un standard dans le nouvel environnement de forcer SSL pour tout. Je ne suis pas d'accord avec cette décision et voudrais avoir autant de connaissances que possible quand je m'assieds pour 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 c'est trois certificats qui sont nécessaires pour chaque site
• Pour la majorité des pages, le contenu n'est pas sécurisé et forcer SSL rendrait la page de demande de prendre plus de temps sur le serveur en raison de cryptage et de décryptage
• Ce que je comprends, la plupart des navigateurs pour ne pas mettre en cache les pages SSL ed et donc, de nouveau, les demandes de page prendra plus de temps
• Les navigateurs plus anciens ont des problèmes avec les téléchargements de fichiers lorsqu'ils sont SSL ed

Je n'ai pas un problème avec un forçage SSL lorsque les utilisateurs s'authentifient ou ils sont demandeurs de données sensibles. Cependant, je pense que forcer SSL par défaut sur tous les sites c'est un peu beaucoup.

Answer 1

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 c'est trois certificats qui sont nécessaires pour chaque site

À peine vrai. Vous n'avez pas besoin d'avoir chaque unique de développement et d'assurance qualité derrière SSL valide avec, certificats actuels. Vous -- peut-être -- veux un site de test avec un certificat valide. Mais au-delà de l'Apache en frontal, votre back-end ne doit pas savoir qu'il y a SSL impliqués. Vous n'êtes pas tester quelque chose d'unique ou de particulier en achat dev certificats.

En outre, le coût est modique. Vous serez en mesure de dépenser plus d'argent sur la conversation que les certificats en fait le coût.

Pour la majorité des pages, le contenu n'est pas sécurisé et forcer SSL rendrait la page de demande de prendre plus de temps sur le serveur en raison de cryptage et de décryptage

Un peu. Avez-vous mesuré? Vous pouvez trouver qu'il est difficile à mesurer en raison de la variabilité de la vitesse de l'internet l'emporte sur le coût de traitement SSL.

Ce que je comprends, la plupart des navigateurs pour ne pas mettre en cache les pages SSL ed et donc, de nouveau, les demandes de page prendra plus de temps

Encore une fois, avez-vous mesuré?

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

Vraiment? Qui "spécifiques à un navigateur plus ancien" envisagez-vous de soutien qui a ce problème? Si vous ne pouvez pas en trouver un, et sont à penser que quelqu'un, quelque part, pourrait avoir ce problème, vous pouvez peut-être overengineering. Vérifiez vos journaux et de voir quels sont les navigateurs de vos clients réellement utiliser, puis de 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 non-SSL-80 page de "bienvenue". Mais je ne suis pas sûr de votre jeu actuel de questions sont solides raisons. Je pense que vous avez besoin de beaucoup plus de mesures pour faire de la casse que SSL implique, en réalité, coût réel ou réel les performances.

Answer 2

En 2012, les sites devraient utiliser uniquement SSL si ils ont personnellement identifiables (PII) ou d'un commerce important d'informations, ou si elles ont toute notion de connexion.

Les Sites qui publient uniquement de faible valeur, faible confiance en lecture seule information du public sont un peu défendable, mais pourrait probablement encore utilement servir le tout sur HTTPS. Les attaquants peuvent tenter d'insérer des logiciels malveillants ou des logiciels publicitaires, ou des redirections, à l'adresse HTTP du contenu.

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

Vous devriez également regarder dans le déploiement HTTP Strict Transport Security pour assurez-vous que même l'utilisateur à sa première demande, à partir de la frappe example.com est envoyé via le protocole HTTPS.

Man-in-the-middle attaques sont un problème réel, en particulier sur les réseaux wifi, mais aussi à l'ISP et au niveau des pays. Si vous n'avez qu'à la phase de procédure de connexion via le protocole SSL et puis de passer un cookie de session en clair, que le cookie de session sera volé. Voir Firesheep pour une démonstration claire.

SSL en toute sécurité est mis en cache par utilisateur, soit pour la session ou pour une durée indéterminée. Client de fin d'proxy caches sont maintenant rares et l'optimisation pour que la casse n'est pas importante. Quand ils existent, ils sont souvent tout de travers, et de les contourner par le protocole SSL est la peine.

Correctement mis en œuvre le protocole SSL ou SPDY peut être rapide: la surcharge du serveur n'est pas très élevé et il est facile de les déplacer sur une autre proxy inverse de la machine. Il y a des SSL Cdn.

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

Le chiffrement des données à travers le réseau est un utile de la couche de défense en profondeur. Évidemment, il ne suffit pas en soi à rendre le service sécurisé, mais il élimine certains types de problèmes et a un faible coût.

Même pour la lecture seule des données, il est important que les clients de savoir qu'ils obtiennent le site authentique: par exemple, s'ils sont le téléchargement de fichiers binaires vous ne voulez pas que les chevaux de troie pour être inséré.

En toute sécurité distinguer les pages qui doivent être sur SSL de ceux qui ne prend développeur, qui pourrait presque certainement être mieux utilisé.

Normes relatives à la prise d'une camisole de force pour les différents systèmes, en particulier, sans consultation, n'est jamais bon. Mais en disant que les sites doivent tous être sur SSL, sauf s'il existe une raison particulière de faire autrement dans un cas, fait sens pour moi. De bons exemples de cas-par-cas des exceptions, où vous devriez toujours vous offrir SSL, mais pas de forcer une redirection:

• le site est au service de grandes binaire téléchargements (musique/vidéo/distributions de logiciels) afin de permettre à plus de cache et des téléchargements plus rapides est important (afficher les données)
• les clients sont archaïques IE ou incorporés les clients qui ne peuvent tout simplement pas faire SSL de manière adéquate (encore une fois, montrer que c'est effectivement un problème)
• il existe de très nombreuses ressources sur le site et que vous souhaitez les robots d'indexer sur HTTPS

Si vous utilisez SSL partout où vous allez l'utiliser un peu plus de ressources de la machine, d'une manière qui peut être optimisé si ils deviennent importants. Si vous n'utilisez pas le protocole SSL, vous pouvez soit passer 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 de vol.

Adam Langley de Google a écrit en 2010:

Si il y a un point que nous voulons communiquer au monde, c'est que le protocole SSL/TLS n'est pas gourmand en ressources, pas plus. Il y a dix ans, il aurait été vrai, mais c'est juste pas le cas, pas plus. Vous aussi, vous pouvez se permettre pour activer HTTPS pour vos utilisateurs.

En janvier de cette année (2010), Gmail a activé le HTTPS pour tout par défaut. Auparavant, il avait été présenté comme une option, mais maintenant l'ensemble de nos utilisateurs utilisent le protocole HTTPS pour sécuriser leurs emails entre leur navigateur et Google, tout le temps. Pour ce faire, nous avons dû déployer de nouvelles machines et pas de matériel spécial. Sur notre production frontend machines, SSL/TLS représente moins de 1% de la charge CPU, moins de 10 KO de mémoire par connexion et moins de 2% de la surcharge 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) aidera à dissiper les que.

Answer 3

Donc, j'ai vu certains fantastique réponses à cette question, mais quelques jours après j'ai vu qu'il y a quelques choses qui manquent. Par conséquent, il ya un couple de choses que je tiens à mentionner:

Pourquoi Utiliser SSL sur Tout

• Sécurité - Si seulement quelques pages sont chiffrées en SSL, il est plus facile de "renifler" hors les pages qui contiennent des données sensibles. Maintenant SSL est assez putain de coffre-fort, donc ce n'est pas quelque chose à craindre, mais dans le cas où votre clé privée est compromise, c'est une bonne pratique d'avoir cette couche supplémentaire de sécurité, de sorte qu'il est plus difficile pour le mauvais gars pour obtenir à la juteuse choses.
• Fiabilité - Il y a des gens qui prétendent que lorsque vous visitez un site qui possède un certificat vérifié, il est plus facile de faire confiance. Depuis un certificat vérifié coûte de l'argent, il est plus facile de faire confiance à un site sachant que le propriétaire a investi dans un symbole de confiance.
• Tracas - d'Emmaillotage tout sous le protocole SSL est tout simplement beaucoup plus facile. Tout ce que vous avez à faire est de couper l' http: au début de chaque lien et vous êtes bon.
• Le RÉFÉRENCEMENT de Configuration - Vous de ne pas avoir à s'embêter avec la SEO de configuration. J'ai entendu dire que les moteurs de recherche d'index http:// et https:// comme des entrées distinctes, donc, pour des raisons de cohérence (dans les deux RÉFÉRENCEMENT et le comportement de la page), d'emmaillotage SSL sur tout, et tout simplement la mise en place d'une redirection 301 semble être une bonne solution.
• Cohérence - Vous aurez une bien plus cohérente site web si vous venez https:// tout. Beaucoup de cadres de pause quand vous essayez de faire un hybride de SSL et non-SSL. En plus de cela, URL dépendant de plugins et le code seront vraiment dire, si vous essayez de rebondir et-vient entre http et https.
• Que Floue Sentiment de sécurité - il faut avouer, cette petite 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. C'est un fait incontournable, cependant, que le protocole SSL sera toujours plus lent.
• Compatibilité du navigateur - C'est probablement négligeable, mais si vous voulez soutenir vraiment les vieux navigateurs qui ne met pas en cache sur SSL, vous devez coller avec le port 80.
• Plugins - Un tas de plugins ne fonctionnent pas correctement sur SSL, donc vous devez être prudent à ce niveau. Si jamais vous voulez ajouter un nouveau plugin, vous devrez reconfigurer les paramètres SSL ou chercher un autre plugin.
• Professionnalisme - Maintenant, bien que certaines personnes affirment que le fait de voir un vérifiée SSL domaine semble digne de confiance, d'autres la considèrent comme un très amateur et paresseux solution. En fait, c'est vraiment facile et pas cher (m'a coûté environ $10) pour obtenir un vérifiée certificat SSL qui frappe jusqu'à 96% des navigateurs!
• Tracas - je n'ai Donc dire qu'il est plus facile de SSL tout, mais en même temps, vous allez devoir faire en sorte que chaque ressource est chargé par le biais d' https:// (ou ne l' http:// -> // solution rapide). Il peut être un peu fastidieux si vous avez un tas de liens ou encore incompatible si vous avez soumis par l'utilisateur du contenu hébergé sur un site qui ne prend pas en charge SSL. Dans ces cas, votre navigateur vont se plaindre à vous. Si vous avez déjà vu l'avis qui dit "cette page a un contenu non sécurisé", vous saurez quoi de plus ennuyeux que c'est et comment mauvaise que les regards.

Donc en bref, c'est vraiment de la situation, mais j'ai tendance à éviter d'emmaillotage SSL. Bien sûr, il prend un peu plus de configuration, mais à la fin vous obtenez un système beaucoup plus souple. Personnellement, je pense que l'ensemble du "professionnalisme" chose, c'est de la connerie (Twitter et Google SSL tout). Toutefois, si vous avez hébergé en externe contenu ou du contenu posté, il est généralement une très mauvaise idée SSL tout. Vous pourriez aussi commencer SSL-ing tout et courir dans un tas d'ennuis.

Mais c'est juste moi. :D

Answer 4

SSL empêche la mise en cache, non seulement à partir des navigateurs, mais aussi à partir des serveurs proxy. Tous les éléments de page web devra être envoyé par votre serveur principal, encore et encore. Cela augmente la charge du réseau.

SSL empêche l'utilisation de soi-disant "domaines virtuels". Lorsqu'un navigateur se connecte à un serveur HTTPS, le serveur doit répondre à l'aide d'un certificat de serveur qui contient le nom du serveur; le navigateur vérifie que le nom dans le certificat correspond au nom du serveur dans l'URL. Cela se produit avant que le navigateur envoie l'URL, donc une machine serveur qui héberge plusieurs serveurs HTTPS doit deviner le "droit" de certificats, hors de l'air mince. Dans la pratique, cela signifie une seule adresse IP publique par le nom du serveur (le serveur utilise ensuite l'adresse IP entrante de deviner le certificat à utiliser). Selon votre situation, il peut ou peut ne pas être un problème grave.

Sur la performance pure, le symétrique de chiffrement et de contrôle d'intégrité sur les données tunnel n'est pas très cher; si votre serveur est incapable de chiffrer et de déchiffrer à la vitesse du réseau, alors soit vous avez de Dieu de la fibre optique, ou vous devriez penser à remplacer ceux i486. Toutefois, l'ouverture d'une connexion SSL, connue comme la "poignée de main", est un peu plus cher, et peut impliquer un goulot d'étranglement des performances sur des charges lourdes (quand il y a des centaines de connexions par seconde, ou plus). Heureusement, un navigateur donné instance de réutilisation des tunnels et des sessions SSL, ce n'est donc pas un problème si vous avez seulement quelques dizaines d'utilisateurs.

Dans l'ensemble, les mettre SSL partout ressemble à un moyen d'obtenir une "ambiance chaleureuse et douillette" sur la sécurité. Ce n'est pas bon. Cela signifie généralement que, en se concentrant sur la pertinence, les administrateurs seront plus enclins à ignorer les réels problèmes de sécurité. Ils vont aussi rendre le système plus complexe à maintenir, en la rendant plus difficile à diagnostiquer et corriger les problèmes. On remarque que dans les administrateurs de point de vue, ce qui rend leur travail plus sûr, car il augmente le coût de la cuisson et de les remplacer.

Answer 5

Cette première chose à vous demander, qu'est-SSL-vous acheter? Il vous achète l'assurance que personne et aucune application ne peut "sentir" 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 sur les coûts d'une légère augmentation de la vitesse de téléchargement. Vous mentionnez que les plus anciennes du navigateur ont de la difficulté à télécharger les fichiers sur la communication SSL. Je ne peux pas en parler, et je ne voudrais pas me préoccuper trop avec ça. En matière de sécurité point de vue, vous avez une autre source de préoccupation. Les pare-feux modernes surveiller le trafic à la recherche pour les diverses tentatives d'intrusion. SSL empêche le pare-feu de moniteur de communication, de sorte que le développeur de l'application / web-admin doit être encore plus concernés par la protection de leurs applications et des sites à partir de diverses tentatives de piratage. Longue histoire courte, on ne devrait chiffrer les communications qui en ont vraiment besoin.