Quels sont les avantages et les inconvénients du SSL à l'échelle du site (https)?
Quels sont les avantages et les inconvénients du cryptage de tout le trafic HTTP pour l'ensemble du site via SSL, par opposition à SSL uniquement sur la page de connexion?
Étant donné que la plupart des autres réponses ici traitent des inconvénients du SSL à l'échelle du site (principalement des problèmes de performances - entre-temps, ceux-ci peuvent facilement être atténués en déchargeant la terminaison SSL, soit vers une boîte de proxy SSL, soit une carte SSL), je soulignerai quelques problèmes avec seulement la page de connexion via SSL, puis en passant à non SSL:
- Le reste du site n'est pas sécurisé (bien que cela soit évident, parfois l'accent est trop mis uniquement sur le mot de passe de l'utilisateur).
- L'identifiant de session de l'utilisateur doit être transmis en clair, ce qui lui permet d'être intercepté et utilisé, et ainsi permettre aux méchants d'usurper l'identité de vos utilisateurs. (C'est principalement le sujet du brouhaha Firesheep ).
- En raison du point précédent, vos cookies de session ne peuvent pas être marqués avec l'attribut
secure, ce qui signifie qu'ils peuvent être récupérés de manières supplémentaires. - J'ai vu des sites avec SSL uniquement pour la connexion, et bien sûr, j'oublie d'inclure la page Mot de passe oublié, la page Changer le mot de passe et même la page d'inscription ...
- Le passage de SSL à non-SSL est souvent compliqué, peut nécessiter une configuration complexe sur votre serveur Web et, dans de nombreux cas, un message effrayant apparaîtra pour vos utilisateurs.
- Si c'est UNIQUEMENT la page de connexion, et f.e. il y a un lien vers la page de connexion depuis la page d'accueil de votre site - qu'est-ce qui garantit que quelqu'un ne usurpera/modifiera/interceptera pas votre page d'accueil et ne le fera pas pointer vers une autre page de connexion?
- Ensuite, il y a le cas où la page de connexion elle-même n'est pas SSL, mais seul le [~ # ~] soumet [~ # ~] l'est - puisque c'est la seule fois où le mot de passe est envoyé, donc ça devrait être sûr, non? Mais en vérité, cela enlève à l'utilisateur la possibilité de s'assurer à l'avance que le mot de passe est envoyé au bon site, jusqu'à ce qu'il soit trop tard. (Par exemple, Bank of America et bien d'autres).
La "surcharge du serveur" augmentant comme un "con" significatif est un mythe courant. Les ingénieurs de Google noté que lors du passage de gmail à 100% SSL, ils n'ont déployé aucun matériel supplémentaire et que SSL représentait moins de 1% d'augmentation de la charge du processeur et de 2% du trafic réseau. Stack Overflow a également quelques questions à ce sujet: Combien de frais généraux SSL impose-t-il? et performances HTTP vs HTTPS .
Depuis l'entrée du blog zscaler Pourquoi le Web n'est-il pas encore passé au SSL uniquement?
"Avec le problème de détournement de session mis en évidence une fois de plus par Firesheep, beaucoup de gens m'ont demandé pourquoi plus de sites Web, ou du moins les principaux acteurs (Google, Facebook, Amazon, etc.) n'ont pas activé SSL par défaut pour toutes les communications. En effet , le chiffrement est le seul moyen de garantir que les sessions utilisateur ne peuvent pas être facilement détectées sur un réseau sans fil ouvert.
Cela semble facile - il suffit d'ajouter un s après http dans l'URL! Ce n'est pas si simple que ça. Voici quelques-uns des défis. "
Résumé des défis (contre):
- "surcharge du serveur"
- "latence accrue"
- "défi pour les CDN"
- "Les certificats génériques ne suffisent pas"
- "HTTP/HTTPS mixte: le problème du poulet et des œufs"
- "les avertissements font peur!"
Ars Technica a n excellent article expliquant certains des défis du déploiement de SSL à l'échelle du site.
Un gros: la plupart des réseaux publicitaires ne fournissent aucun moyen de diffuser des annonces via SSL. De plus, si vous intégrez des annonces (diffusées via HTTP) dans une page principale diffusée via HTTPS, les navigateurs émettront des avertissements effrayants à contenu mixte, auxquels vous ne voudrez pas soumettre vos utilisateurs. Ainsi, les sites financés par la publicité auront probablement du mal à passer à SSL sur tout le site.
L'article décrit également d'autres défis, tels que les widgets tiers, les analyses, les vidéos intégrées, etc.
OK, c'est une question ancienne, donc ma réponse languira probablement ici en bas. Cependant, j'ai quelque chose à ajouter du côté "contre".
Latence HTTPS:
Avoir une faible latence HTTP client-serveur est essentiel pour créer sites Web réactifs à chargement rapide . Et les temps de chargement de page rapides augmentent le bonheur de l'utilisateur final .
TCP/IP seul a le fameux TCP poignée de main à 3 voies, c'est-à-dire la configuration de connexion initiale pour HTTP simple sur TCP nécessite 3 paquets. Lorsque SSL/TLS est utilisé, la configuration de la connexion est plus impliquée, ce qui signifie la la latence pour les nouvelles connexions HTTPS est inévitablement plus élevée que le HTTP en texte brut.
Notez que l'impact de cela peut être réduit (mais pas éliminé) en réutilisant la connexion HTTPS plusieurs fois, c'est-à-dire en utilisant des connexions persistantes et autres optimisations de performances telles que SSL False Start .
Modéliser exactement combien HTTPS ralentit le chargement des pages est compliqué, car tous les navigateurs modernes téléchargez les objets HTTP en parallèle chaque fois que possible. Même ainsi, le temps d'établissement de connexion initiale plus élevé est à la fois significatif et inévitable avec la technologie actuelle; la latence accrue des nouvelles connexions est donc une considération importante.
Un inconvénient qui est omis dans les autres réponses ci-dessus est la dépendance massive de nos jours sur les réseaux de distribution de contenu (par exemple Akamai) - de nombreuses pages Web en utilisation actuelle récupèrent le contenu d'une variété de domaines, de sorte que le navigateur devrait avoir des certificats pour chacun de ces ou des avertissements apparaissent. Et puis bien sûr, si l'attaquant a utilisé une plate-forme CDN pour laquelle le navigateur avait déjà des certificats, il se peut qu'il ne reçoive pas d'avertissement quand il le devrait.
Problème délicat avec la façon dont les applications et le contenu sont actuellement livrés.
Les avantages sont certainement une sécurité accrue. Les inconvénients pourraient être des connexions relativement plus lentes, une utilisation plus intensive du processeur, une gestion précise des certificats, certains coûts de certificat (si vous n'utilisez pas de certificats auto-signés). Mais ces derniers temps, il y a une pratique répandue d'utiliser https et ces inconvénients viennent à l'arrière-plan en raison des avantages pour les utilisateurs finaux et de la confiance accrue envers une entreprise qui fournit des services.
D'autres réponses ont affirmé un "problème de poulet/œuf" en raison d'avertissements à contenu mixte qui rendent la migration HTTP-> HTTPS difficile. C'est un problème, mais je ne pense pas que ce soit aussi difficile qu'ils le prétendent.
Le contenu mixte peut être traité en utilisant RL relatives au protocole et les mêmes scanners que vous devriez utiliser pour trouver des problèmes XSS.
RFC 3986 section 4.2 utilise le terme référence de chemin de réseau:
Une référence relative qui commence par deux barres obliques est appelée une référence de chemin de réseau
Scannez d'abord vos pages jusqu'à ce que vous trouviez toutes les utilisations de http://example.com/ dans les liens, images et autres éléments du site de même origine et remplacez-les par des URL relatives au protocole (//example.com/...). Cela vous permet de faire servir le même HTML, que vous serviez une page via HTTP ou HTTPS et vous place dans une bien meilleure position pour revenir en arrière en cas de problème plus tard dans votre migration.
Ensuite, configurez des redirections HTTP-> HTTPS permanentes afin que les URL existantes sur les sites hors de votre contrôle continuent de fonctionner et commencent à être diffusées via HTTPS. L'utilisation d'une redirection permanente avec des en-têtes de cache agressifs aidera les moteurs de recherche à transférer le classement des pages et à accélérer le site pour les visiteurs de retour.
Vous devez bien sûr garder vos scanners à la recherche de contenu mixte afin de détecter les régressions.
Je sais que c'est une vieille question/thread, mais je voulais juste souligner un énorme PRO pour faire du SSL côte à côte.
SPDY
L'utilisation de mod_spdy sur Apache nécessite SSL.
Si vous n'avez pas encore déployé SPDY, faites-le! Les deux Chrome et Firefox prennent en charge le protocole, ainsi que Opera.
C'est environ la moitié de vos utilisateurs qui pourront profiter de SPDY.
Un autre inconvénient (évoqué par d'autres) est un manque de mise en cache qui affectera évidemment la vitesse. De plus, certaines variables de serveur ne sont pas disponibles - comme HTTP_FORWARDED_FOR je pense.
Tout bon point mentionné ici, cependant, j'ai mal le coût de la con! Et par coût, je ne veux pas seulement acheter le certificat, mais avoir l'infrastructure appropriée pour gérer les certificats, les révocations, les modules de cryptographie dédiés pour réduire la charge CPU du serveur Web, etc.
Avantages de garder le site entier crypté:
- vous ne fâcherez pas vos visiteurs soucieux de leur confidentialité en leur envoyant du texte en clair après la connexion.
- moins de risques d'erreurs lors de la redirection/liaison entre les parties http et https du site.
Le con:?
Lisez les témoignages de Google et d'autres. Il ne doit pas être coûteux de passer à 100% https.
Si un site Web est géré par un CMS qu'un utilisateur non technique peut utiliser pour modifier des pages, il peut modifier le code HTML pour inclure des références à des ressources hors site, telles que des images, via HTTP. J'ai construit un site d'achat qui utilise SSL uniquement lorsque cela est nécessaire et redirige les autres pages vers HTTP, car sinon vous obtiendriez des avertissements de contenu mélangés en raison de toutes les images hors site que le propriétaire a collées sur le site.