Pourquoi ne pas utiliser HTTPS pour tout?
Si je configurais un serveur et possédais un ou plusieurs certificats SSL, pourquoi n’utiliserais-je pas le protocole HTTPS pour l’ensemble du site plutôt que pour les achats/connexions? Je penserais qu'il serait plus logique de chiffrer l'ensemble du site et de protéger entièrement l'utilisateur. Cela éviterait des problèmes tels que le choix de ce qui doit être sécurisé car tout le serait, et ce n'est pas vraiment un inconvénient pour l'utilisateur.
Si j'utilisais déjà un protocole HTTPS pour une partie du site, pourquoi ne voudrais-je pas l'utiliser pour l'ensemble du site?
C'est une question connexe: Pourquoi https est-il uniquement utilisé pour la connexion? , mais les réponses ne sont pas satisfaisantes. Les réponses supposent que vous n’avez pas été en mesure d’appliquer https à l’ensemble du site.
Je peux penser à plusieurs raisons.
- Certains navigateurs peuvent ne pas prendre en charge SSL.
- SSL peut diminuer quelque peu les performances. Si les utilisateurs téléchargent des fichiers publics volumineux, il peut s’avérer fastidieux de les chiffrer chaque fois.
Outre les autres raisons (liées notamment aux performances), vous ne pouvez héberger qu'un seul domaine par adresse IP * lorsque vous utilisez HTTPS.
Un seul serveur peut prendre en charge plusieurs domaines dans HTTP, car l'en-tête Server HTTP indique au serveur avec quel domaine il doit répondre.
Avec HTTPS, le serveur doit offrir son certificat au client lors de la première prise de contact TLS (avant le démarrage de HTTP). Cela signifie que l'en-tête Server n'a pas encore été envoyé. Il est donc impossible pour le serveur de savoir quel domaine est demandé et quel certificat (www.foo.com ou www.bar.com) il faut répondre. avec.
* Note de bas de page: Techniquement, vous pouvez héberger plusieurs domaines si vous les hébergez sur différents ports, mais ce n'est généralement pas une option. Vous pouvez également héberger plusieurs domaines si votre certificat SSL a une carte de remplacement. Par exemple, vous pouvez héberger foo.example.com et bar.example.com avec le certificat * .example.com.
SSL/TLS n'est pas utilisé assez souvent. HTTPS doit être utilisé pour la toute la session. Aucun ID de session ne peut être envoyé via HTTP. Si vous utilisez uniquement https pour vous connecter, vous êtes en violation flagrante de Le top 10 de l'OWASP pour 2010 "A3: authentification et gestion de session rompues".
Pourquoi ne pas envoyer chaque courrier postal dans une enveloppe opaque inviolable par courrier recommandé? Quelqu'un du bureau de poste en aurait toujours la garde personnelle, alors vous pouvez être à peu près sûr que personne ne surveille votre courrier. De toute évidence, la réponse est que même si certains courriers en valent la peine, la plupart ne le sont pas. Je m'en fiche si quelqu'un lit mon "Content que tu sois sorti de prison!" carte postale à oncle Joe.
Le chiffrement n'est pas gratuit et ne vous aide pas toujours.
Si une session (telle que des achats, des opérations bancaires, etc.) doit aboutir à HTTPS, il n’ya aucune bonne raison de ne pas créer l’ensemble de la session HTTPS le plus tôt possible.
Mon opinion est que HTTPS ne devrait être utilisé que lorsque cela est inévitablement nécessaire, soit parce que la demande ou la réponse doit être protégée de la surveillance intermédiaire. Par exemple, consultez le site Yahoo! page d'accueil. Même si vous êtes connecté, la plupart de vos interactions se feront via HTTP. Vous vous authentifiez via HTTPS et obtenez des cookies qui prouvent votre identité. Vous n'avez donc pas besoin de HTTPS pour lire les reportages.
La principale raison, au-delà de la charge du système, est qu'il casse l'hébergement virtuel basé sur le nom. Avec SSL, c'est un site, une adresse IP. C'est assez coûteux et difficile à administrer.
Pour les liaisons à latence élevée, l'établissement de la liaison TLS initiale nécessite des allers-retours supplémentaires pour valider la chaîne de certificats (y compris l'envoi de certificats intermédiaires), convenir de suites de chiffrement et établir une session. Une fois la session établie, les requêtes suivantes peuvent utiliser la mise en cache de session pour réduire le nombre d'allers et retours, mais même dans le meilleur des cas, le nombre d'allers et retours qu'il reste est supérieur au nombre requis par une connexion HTTP normale. Même si les opérations de chiffrement étaient gratuites, les allers-retours ne sont pas et peuvent être assez visibles sur des liens de réseau plus lents, en particulier si le site ne exploite pas le traitement en pipeline http. Pour les utilisateurs à large bande dans un segment bien connecté du réseau, ce n'est pas un problème. Si vous faites des affaires à l'international, requérir https peut facilement entraîner des retards notables.
Il existe des considérations supplémentaires telles que la maintenance de l'état de session par le serveur nécessitant potentiellement beaucoup plus de mémoire et bien sûr les opérations de cryptage des données. Tous les petits sites n’ont pratiquement pas à s’inquiéter de la capacité du serveur par rapport au coût du matériel actuel. N'importe quel site de grande taille pourrait facilement se permettre des cartes d'extension ou de déchargement AES CPU/w pour fournir une fonctionnalité similaire.
Tous ces problèmes deviennent de moins en moins problématiques à mesure que le temps passe et que les capacités du matériel et du réseau s'améliorent. Dans la plupart des cas, je doute qu'il y ait une différence tangible aujourd'hui.
Il peut y avoir des considérations opérationnelles telles que des restrictions administratives sur le trafic https (pensez aux filtres de contenu intermédiaires, etc.) et éventuellement à certaines réglementations d'entreprise ou gouvernementales. Certains environnements d’entreprise exigent un déchiffrement des données au niveau du périmètre pour éviter les fuites d’informations. Interférences avec des points d’accès ou des systèmes d’accès Web similaires ne pouvant pas injecter de messages dans des transactions https. À la fin de la journée, à mon avis, les raisons de ne pas utiliser https par défaut sont susceptibles d’être relativement modestes.
https est plus gourmand en ressources que le http normal.
Cela exige plus des serveurs et des clients.
Vous devez utiliser HTTPS partout, mais vous perdrez les éléments suivants:
Vous ne devez absolument pas utiliser la compression SSL ou HTTP sur SSL en raison d'attaques BREACH et CRIME. Donc, pas de compression si votre réponse contient des identifiants de session ou csrf. Vous pouvez limiter ceci en plaçant vos ressources statiques (images, js, css) sur un domaine sans cookie et y utiliser la compression. Vous pouvez également utiliser la minification HTML.
Un certificat SSL, une adresse IP, sauf si vous utilisez SNI, qui ne fonctionne pas sur tous les navigateurs (ancien Android, BlackBerry 6, etc.).
Vous ne devriez pas héberger de contenu externe sur vos pages qui ne provient pas de SSL.
Vous perdez l'en-tête HTTP Referer sortant lorsque le navigateur accède à une page HTTP, ce qui peut ne pas être un problème pour vous.
Si toute la session est cryptée, vous ne pourrez pas utiliser la mise en cache pour les ressources statiques telles que les images et les js au niveau du proxy, par exemple, le fournisseur de services Internet.
LeHTTPSest un protocole HTTP sécurisé avecSSL. Vous devrez peut-être enregistrer un certificat payé pour que votre site soit maintenu et digne de confiance.
Le protocole HTTPS est nécessaire lorsque votre site doit échanger des informations avec l'utilisateur et que vous souhaitez conserver les informations sécurisées par cryptage.
Sinon, HTTPS n'est pas nécessaire mais vous pouvez quand même l'utiliser si vous le souhaitez.
Un autre petit point (peut-être que quelqu'un peut vérifier), si un utilisateur saisit des données dans un élément de formulaire, tel qu'une zone de texte, puis actualise la page ou si le serveur tombe en panne pendant une seconde, les données saisies par l'utilisateur sont perdues. HTTPS mais est préservé en utilisant HTTP.
Note: Je ne suis pas sûr que ce soit spécifique à votre navigateur, mais cela arrive certainement avec mon navigateur Firefox.
windows Server 2012 avec IIS 8.0 offre maintenant SNI qui est une indication du nom du serveur qui permet à plusieurs applications Web SSL de IIS d'être hébergées sur une seule adresse IP.
Outre la réponse de WhirlWind, vous devez prendre en compte le coût et l'applicabilité des certificats SSL, les problèmes d'accès (il est possible, bien que peu probable, qu'un client ne puisse pas communiquer via le port SSL), etc.
L'utilisation de SSL n'est pas une garantie de sécurité. Ce type de protection doit être intégré à l'architecture de l'application, plutôt que d'essayer de s'appuyer sur une solution miracle.
La raison évidente est la performance: toutes les données devront être chiffrées par le serveur avant la transmission, puis déchiffrées par le client à la réception, ce qui est une perte de temps s'il n'y a pas de données sensibles. Cela peut également affecter la quantité de mémoire cache mise en cache sur votre site.
Il est également potentiellement déroutant pour les utilisateurs finaux si toutes les adresses utilisent https:// plutôt que le http:// bien connu. Voir aussi cette réponse:
Pourquoi ne pas toujours utiliser https lors de l'inclusion d'un fichier js?
https nécessite que le serveur crypte et décrypte les demandes et les réponses des clients. L’impact sur les performances s’ajoutera si le serveur sert de nombreux clients. C'est pourquoi la plupart des implémentations actuelles de https sont limitées à l'authentification par mot de passe. Mais avec l’augmentation de la puissance de calcul, cela peut changer, car Gmail utilise SSL pour l’ensemble du site.
On m'a dit que, sur l'un des projets de notre société, ils ont constaté que la bande passante occupée par les messages SSL était nettement supérieure à celle des messages simples. Je crois que quelqu'un m'a dit qu'il s'agissait de 12 fois plus de données. Je n'ai pas vérifié cela moi-même et ça sonne très fort, mais si une sorte d'en-tête est ajouté à chaque page et que la plupart des pages ont une petite quantité de contenu, cela risque de ne pas être aussi éloigné.
Cela étant dit, il est fastidieux d’aller et de retour entre http et https et de savoir quelles pages sont ce qui me semble être un effort excessif. Une seule fois, j'ai essayé de construire un site qui les mélangeait et nous avons fini par abandonner le plan lorsque des choses complexes, telles que les fenêtres contextuelles créées par Javascript, nous ont fait trébucher, et que le mauvais protocole y était attaché, etc. Nous avons fini par rendre le site entier https moins pénible. Je suppose que dans les cas simples où vous avez juste un écran de connexion et un écran de paiement qui doivent être protégés et qui sont des pages simples, ce ne serait pas un gros problème de mélanger et de faire correspondre.
Je ne m'inquiéterais pas beaucoup de la charge qui incombe au client de décrypter. Normalement, le client passera beaucoup plus de temps à attendre que les données arrivent sur le réseau téléphonique qu’il en faut pour les traiter. Tant que les utilisateurs n’ont pas systématiquement des connexions Internet gigabit/s, la puissance de traitement du client n’est probablement pas pertinente. La puissance de calcul requise par le serveur pour chiffrer les pages est un problème différent. Il se peut que le problème ne puisse pas être suivi par des centaines, voire des milliers d’utilisateurs.