J'ai un site ... appelons-le mysite.com. Sur ce site, il y a la section d'inscription que je pense devrait être la partie sécurisée de ce site.
a) Devrais-je activer SSL sur l'ensemble du site ou simplement la pièce d'inscription (E.G. Signup.Mysite.com) b) Quels sont les avantages et les inconvénients de l'activer pour tout le site?
4 Réponses :
Forcer tout le site à utiliser SSL mangera votre bande passante car tout le contenu est crypté, y compris des images. Veuillez vérifier Apache SSL FAQ pour plus d'informations
Pratiquement, à quel point la bande passante est-elle touchée. Disons que le site a environ 100 à 200 hits uniques un jour. Cela signifie-t-il que cela va diminuer de manière significative à la vitesse et utilisera beaucoup de bande passante?
La mise en cache dans le navigateur ne fonctionne pas (ou ne devrait pas) travailler sur SSL.
C'est une mauvaise information. Vous pouvez les actifs CDN même sur TLS. Vous pouvez écrire des en-têtes de cache client pour le client pour cache des ressources. TLS inclut la compression native comprenant la compression des demandes complètes et des en-têtes de réponse, ce qui va bien au-delà de la compression HTTP. Pour la plupart des sites Web, TLS n'ajoute que l'utilisation supplémentaire minimale de la CPU.
Les navigateurs modernes cacheront correctement les actifs récupérés sur SSL si une en-tête de contrôle de cache correcte.
En fait, l'utilisation du CPU côté client et du serveur pourrait augmenter et pourrait être une préoccupation plutôt que la bande passante. Cependant, dans les temps modernes, les ressources informatiques sont abondantes et servant un site entièrement sur SSL, c'est une bonne pratique avec peu de compromis. Si votre serveur se bat pour servir les actifs sur TLS, il est évidemment atteint la capacité maximale et luttera probablement sans TLS. Dans une solution de qualité d'entreprise et des actifs ne correspondent même pas à ce que ceux-ci soient servis via CDN et la résiliation TLS / SSL seraient pris en charge sur l'équilibreur de charge qui constitue un appareil extrêmement optimisé.
Le Pro est accru de sécurité et de confidentialité pour toutes les pages de votre site, et le côté bas est inférieur aux performances en raison de la nécessité de chiffrer / déchiffrer le trafic aux deux extrémités de la connexion.
Pour certains sites publics de haut niveau tels que Gmail, qui utilise uniquement SSL pour la connexion, il y a eu une pression de montage pour que toutes les pages utilisent SSL.
Je dirais, essayez-le et voyez si la performance est un problème. Sinon, bien et bon; Sinon, vous pouvez toujours revenir à SSL pour connecter uniquement.
Ce que vous dites à propos de Gmail n'est pas tout à fait vrai. Il vous permettra de vous connecter si vous appelez la page de connexion en utilisant HTTP normal. Si vous appelez la page de connexion en utilisant SSL (à l'aide de HTTPS :) Le reste de votre session sera effectué en SSL. Cela a été de cette façon pour un moment.
Cela dépend de ce que votre site sert. Si les données qu'il sert sont sensibles, vous fournissez une connexion cryptée SSL complète est un bonus.
Mais, comme d'autres personnes ont mentionné, vous mangerez votre bande passante. Les données cryptées SSL, que ce soit des images IT, des pages HTML ou d'autres informations ne sont pas (censées être) mis en cache sur le client. Chaque fois que l'utilisateur redémarre le navigateur, les fichiers sont à nouveau téléchargés.
Je suis d'accord avec Vinay, fournissez Signon / Signup sur SSL, puis retombez à HTTP normal, puis voir.
L'autre approche peut être de fournir tout votre contenu statique sur http pendant tout le contenu sensible sur https (par exemple, si vous utilisez des systèmes tels que ExtJS, les pages sont des fichiers statiques et les données sont toutes récupérées via AJAX).
Bien sûr, si vous servez des informations sensibles (par exemple, des informations bancaires) où les données elles-mêmes sont toujours sensibles, utilisez-la et mangez les coûts.
Si le contenu statique est fourni par, disons un réseau de livraison de contenu, ne montrera-t-il pas d'avertir un "contenu non sécurisé"?
Je suis au courant, oui.
"Fournissez Signon / Signup sur SSL, puis retombez à HTTP normal, puis voir." Comment envisagez-vous cela pour travailler avec des cookies sécurisés? Ou comment atténuez-vous les fuites d'informations sensibles lorsque vous mélangez SSL avec un trafic non SSL.
C'est absolument incorrect . Les navigateurs font (et sont censés) cacher le contenu livré par SSL.
Utiliser entièrement SSL n'augmentera pas nécessairement vos factures de bande passante. Le cryptage ne rend pas les données plus grandes. Assurez-vous d'activer la compression de déflation ASWELL.
où SSL pourrait augmenter votre facture de bande passante est des navigateurs (Firefox) ne cache pas les pages récupérées sur SSL sur le disque. Cela signifie la prochaine fois qu'un utilisateur visite votre site après avoir quitté le navigateur de Thier, ils téléchargeront à nouveau chaque peu de contenu.
Si vous choisissez de vous assurer de la confidentialité de l'utilisateur, assurez-vous que tous les cookies que votre site envoie avoir le drapeau «Envoyer sur SSL uniquement» défini par les utilisateurs, sinon les utilisateurs peuvent être tracés à donner ce cookie en clair avec un phishing très simple.
SSL signifie également payer pour un certificat signé par une CA significative, qui, dans certains cas, coûtera plus que votre brandwidth.