É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 - ceux-ci peuvent facilement être atténués en déchargeant la terminaison SSL, soit sur une boîte proxy SSL, soit sur une carte SSL), je soulignera certains problèmes liés au fait de n'avoir que la page de connexion via SSL, puis au passage à non SSL:

• Le reste du site n'est pas sécurisé (bien que cela soit évident, parfois l'objectif est aussi beaucoup sur juste le mot de passe de l'utilisateur).
• L'identifiant de session de l'utilisateur doit être transmis en clair, lui permettant d'être intercepté et utilisé, et permettant ainsi aux méchants de se faire passer pour vos utilisateurs. (C’est surtout ce dont parlait le 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ère supplémentaire.
• I ont vu des sites avec login-only-SSL, et bien sûr négliger d'inclure dans cela la page Forgot-password, la page Change-password, et même la page Registration ...
• 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 SEULEMENT la page de connexion, et fe il y a un lien vers la page de connexion à partir de la page d'accueil de votre site - qu'est-ce qui garantit que quelqu'un ne usurpera pas / ne modifiera pas / n'interceptera pas votre page d'accueil et la fera pointer vers une autre page de connexion?
• Alors là est le cas où la page de connexion elle-même n'est pas SSL, mais seulement le SUBMIT est - puisque c'est la seule fois que le mot de passe est envoyé, donc cela 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 ont noté que lors du passage de Gmail à 100% SSL, ils n'ont déployé aucun matériel supplémentaire et que SSL représentait une augmentation de moins de 1% de la charge du processeur et de 2% du trafic réseau. Stack Overflow pose également quelques questions à ce sujet: Quelle surcharge SSL impose-t-il? et Performances HTTP vs HTTPS.

À partir de l'entrée du blog zscaler Pourquoi le Web n'est pas encore passé à 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 cryptage est le seul moyen de garantir que les sessions des utilisateurs ne peuvent pas être facilement sniffé sur un réseau sans fil ouvert.

Cela semble facile - ajoutez simplement un s après http dans l'URL! Ce n'est pas vraiment aussi simple que ça. Voici quelques-uns des défis. "

Résumé des défis (inconvénients):

• "surcharge du serveur"
• "augmentation de la latence"
• "défi pour les CDN "
• " les certificats génériques ne suffisent pas "
• " mixte HTTP / HTTPS: le poulet & le problème de l'œuf "
• " les avertissements sont effrayants! "

Ars Technica a un excellent article expliquant certains des défis du déploiement de SSL sur tout le site.

Un gros problème: la plupart des réseaux publicitaires ne proposent aucun moyen de diffuser des annonces via SSL . De plus, si vous intégrez des publicités (diffusées via HTTP) dans une page principale diffusée via HTTPS, les navigateurs émettront des avertissements effrayants de contenu mixte, auxquels vous ne souhaitez pas soumettre vos utilisateurs. Ainsi, les sites financés par la publicité trouveront probablement très difficile la transition vers SSL à l'échelle du 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 va probablement languir ici en bas. Cependant, j'ai quelque chose à ajouter sur le côté «contre».

Latence HTTPS:

Il est essentiel d'avoir une faible latence HTTP client-serveur pour créer des sites Web réactifs et à chargement rapide. Et les temps de chargement rapides des pages augmentent le bonheur des utilisateurs finaux.

Seul TCP / IP a la fameuse poignée de main TCP à 3 voies, c'est-à-dire que la configuration initiale de la connexion pour HTTP sur TCP nécessite 3 paquets . Lorsque SSL / TLS est utilisé, la configuration de la connexion est plus complexe, ce qui signifie que la latence des nouvelles connexions HTTPS est inévitablement plus élevée que le HTTP en texte brut.

Notez que cela peut avoir un impact réduit (mais pas éliminé) en réutilisant la connexion HTTPS plusieurs fois, c'est-à-dire en utilisant des connexions persistantes, et d'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échargent des objets HTTP en parallèle chaque fois que possible. Même ainsi, le temps de configuration de la connexion initiale plus élevé est à la fois significatif et inévitable avec la technologie actuelle; donc l'augmentation de la nouvelle latence de connexion est une considération importante.

Un inconvénient qui manque 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 utilisées actuellement capturent le contenu de divers domaines, le navigateur aurait donc besoin de certificats pour chacun de ces avertissements ou avertissements apparaîtrait. 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 épineux avec la façon dont les applications et le contenu sont actuellement livrés.

Le pour est certainement une sécurité accrue. Les inconvénients peuvent être des connexions relativement plus lentes, une utilisation plus intensive du processeur, une gestion précise des certificats requise, 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 au contexte en raison des avantages pour les utilisateurs finaux et d'une confiance accrue envers une entreprise qui fournit des services.

D'autres réponses ont fait état d'un "problème de poule / œuf" en raison d'avertissements de 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 des URL relatives au protocole et les mêmes scanners que vous devriez utiliser pour trouver des problèmes XSS.

La section 4.2 de la RFC 3986 utilise le terme référence de chemin réseau:

Une référence relative qui commence par deux barres obliques est appelé une référence de chemin réseau

Commencez par scanner vos pages jusqu'à ce que vous trouviez toutes les utilisations de http://example.com/ dans liens, images et autres ressources du site de même origine et remplacez-les par des URL relatives au protocole ( //example.com / ... ). Cela vous permet d'avoir le même HTML servi, que vous diffusiez 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 définitivement Les redirections HTTP-> HTTPS afin que les URL existantes sur des 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 qui reviennent.

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 / discussion, mais je voulais juste souligner un énorme PRO pour faire du SSL latéral.

SPDY

L'utilisation de mod_spdy sur Apache nécessite SSL.

Je n'ai pas encore déployé SPDY, faites-le! Chrome et Firefox prennent en charge le protocole, ainsi qu'Opera.

C'est environ la moitié de vos utilisateurs qui pourront profiter de SPDY.

Un autre inconvénient (abordé 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.

Tous les bons points mentionnés ici, cependant, je mets le prix con! Et par coût, je ne veux pas dire uniquement acheter le certificat, mais avoir l'infrastructure appropriée pour gérer les certificats, les révocations, les modules de cryptage dédiés pour réduire la charge CPU du serveur Web, etc.

Avantages de garder l'intégralité du site crypté:

• vous ne ferez pas chier vos visiteurs soucieux de leur confidentialité en leur envoyant du texte en clair après la connexion.
• moins de risques d'erreur lors de la redirection / de la liaison entre les parties http et https du site.

Le con:?

Lisez les témoignages de Google et d'autres. Il n'est pas forcément 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 créé 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 mixte en raison de toutes les images hors site que le propriétaire a bloquées sur le site. >