Question:
Y a-t-il jamais une bonne raison _pas_ d'utiliser TLS / SSL?
Naftuli Kay
2014-08-07 06:55:09 UTC
view on stackexchange narkive permalink

En écrivant une réponse à cette question sur la faute du serveur, une pensée qui rebondit dans ma tête depuis un certain temps a refait surface sous forme de question:

Y a-t-il déjà une bonne raison de ne pas utiliser TLS / SSL?

Pour élucider davantage la question, je demande le cas spécifique dans lequel les choses ont été configuré correctement:

  1. Performances:
    • Le temps jusqu'au premier octet a été optimisé.
    • La liste de chiffrement est suffisamment petite pour éviter les allers-retours multiples du serveur au client.
    • Pour les applications Web mobiles, des clés de serveur RSA de 2048 bits ont été utilisées par opposition à des clés de 4096 bits pour réduire la charge de calcul sur les clients.
    • SSL les sessions ont une durée de vie raisonnable pour éviter la régénération des clés de session.
  2. Sécurité:

Si cela est fait correctement, y a-t-il une bonne raison de ne pas utiliser TLS / SSL pour les communications TCP?

Nous avons quelques questions connexes que vous voudrez peut-être examiner pour des informations intéressantes: [Pourquoi les sites Web utilisent-ils HTTPS alors qu'ils n'en ont pas besoin?] (Http://security.stackexchange.com/questions/52856/why-do-websites- use-https-when-they-don't-need-to) et [Un site devrait-il avoir SSL s'il n'a pas de formulaire de connexion?] (http://security.stackexchange.com/questions/38832/should-a -site-have-ssl-if-it-doesnt-have-a-login-form)
Cela donne également à votre entreprise un aspect professionnel avec le verrou vert (du moins pour moi).
Exemple: [Pourquoi les téléchargements d'applications ne sont-ils pas systématiquement effectués via HTTPS?] (Https://security.stackexchange.com/questions/18853/why-arent-application-downloads-routinely-done-over-https)
Complexité ajoutée? (Pour de nombreux sites, l'authenticité peut être si peu importante que ses avantages l'emportent de loin sur la petite chance d'un bug de type Heartbleed). Considérez icanhazcheezburger.com comme un exemple de quelque chose où HTTPS est à peine utile (sauf lorsque vous êtes connecté).
Aussi, quelle que soit la qualité des performances de TLS, il ne peut approcher que de manière asymptotique les performances de non-TLS.
Douze réponses:
#1
+73
Bruno Rohée
2014-08-07 18:16:23 UTC
view on stackexchange narkive permalink

Le principal problème avec HTTPS partout est qu'il rend fondamentalement inutile la mise en cache des proxys Web (à moins que vous ne fassiez confiance au proxy et que vous ne le fassiez vous faire passer pour des sites, mais cela ne fonctionne pas avec l'agrafage de certificats et est probablement illégal dans certaines juridictions) . Pour certains cas d'utilisation, comme par exemple la distribution de mises à jour logicielles signées, HTTP est parfaitement logique. Si vous avez par exemple une centaine de postes de travail derrière un proxy d'entreprise, le téléchargement de la mise à jour avec HTTP signifiera que pour tous sauf un, il sera livré hors du cache du proxy. Ce sera beaucoup plus efficace que chacun d'entre eux le fasse via HTTPS ...

En bref, HTTP a du sens comme couche de transport si un autre mécanicien est là pour vérifier l'authenticité et l'intégrité du contenu, et si la confidentialité est de peu d'importance ...

Pour la navigation sur le Web par des êtres humains réels, j'ai beaucoup de mal à justifier de ne pas utiliser HTTPS à notre époque.

Cela a en fait beaucoup de sens. Je n'avais pas envisagé les problèmes de mise en cache que causerait HTTPS. Bien que je convienne que les packages logiciels signés via HTTP fonctionnent et ont du sens, les utilisateurs soucieux de leur confidentialité peuvent toujours vouloir HTTPS pour l'anonymat: "Je ne veux pas (tiers) voir que j'ai changé de Chrome à Firefox." Un adversaire peut voir que vous téléchargez des packages, mais pas nécessairement ce qu'ils sont. (Sauf si le corréler la taille exacte du paquet ...)
SSL / TLS n'a-t-il pas quelque chose comme le type de message MSG_IGNORE de SSH pour aider à l'analyse du trafic?
Donc TL; DR "Utilisez TLS sur chaque site Web."
@raz TLS autorise officiellement les enregistrements de données de longueur 0 (qui, après un éventuel pad, HMAC et un éventuel IV, sont plus gros), mais quand OpenSSL a tenté de l'utiliser il y a des années pour se défendre contre l'attaque de Vaudenay alors théorique, il n'a pas bien interopé. Lorsque Rizzo & Duong ont transformé l'attaque en BEAST, la solution consensuelle pour
@raz ... * HTTPS * permet cependant d'ajouter ou non des en-têtes arbitraires "x-ignoreme:", et 1.1 permet d'insérer plus souvent, moins ou pas du tout, du codage fragmenté avec des extensions et des remorques variables ignorables. En outre, il peut utiliser ou non la compression, et l'algorithme de compression peut prendre ou ignorer diverses opportunités; mais toutes les implémentations que j'ai vues ne sont contrôlées que grossièrement par la limite de l'historique, elles saisissent toutes les opportunités dans cette limite. De plus, de nombreuses personnes ont désactivé la compression en raison de BREACH.
Fait intéressant, le choix de Debian du transport HTTP pour la récupération de paquets à la place de HTTPS les a simplement exposés à une attaque MitM escaladant vers RCE en tant que root.Un autre cas où l'utilisation du HTTPS même là où il n'y avait pas de besoin évident de confidentialité aurait sauvé la mise.Voir https://justi.cz/security/2019/01/22/apt-rce.html pour plus d'informations.
#2
+16
Steffen Ullrich
2014-08-07 11:12:42 UTC
view on stackexchange narkive permalink

Je ne suis pas d'accord avec la réponse de @valentinas. Il y a une perte de performances avec TLS. Si cela est pertinent pour vous dépend de votre site:

  • Pour établir la connexion, vous devez d'abord établir la liaison TCP entre le client et le serveur pour HTTP et HTTPS, ce qui nécessite un aller-retour complet entre le client et serveur.
  • Pour HTTPS, vous disposez en plus de la prise de contact TLS qui nécessite deux allers-retours lors de l'établissement de la session initiale (un seul si le faux départ TLS est pris en charge) et un aller-retour si vous pouvez reprendre une session.
  • Bien que la cryptographie symétrique utilisée dans la session TLS soit bon marché, l'échange de clé initial ne l'est pas. Si vous le faites correctement, vous souhaitez utiliser le secret de transmission, ce qui signifie DHE ou ECDHE. Le DHE simple est très coûteux à mettre en place, l'ECDHE est beaucoup moins cher mais tous les clients ne le supportent pas. Voir http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html pour les benchmarks.

Ces éléments combinés rendent les connexions TLS plus coûteuses à mettre en place et introduisent ainsi un impact notable sur les performances avec des connexions courtes. Plus de matériel n'aidera pas beaucoup, car le problème majeur réside dans les échanges supplémentaires entre les pairs, où ils doivent attendre les uns les autres pour continuer.

Avec de longues connexions, cette surcharge n'a plus tellement d'importance, donc si vous utilisez keep-alive (la plupart des clients et des serveurs le font) et que vous n'avez que peu de connexions, tout ira probablement bien. Mais, peu de connexions signifie que vous ne devriez pas inclure de réseaux publicitaires, car ils redirigent souvent entre plusieurs hôtes jusqu'à ce qu'ils atteignent celui qui sert finalement la publicité. Les sites qui dépendent fortement des publicités sont déjà ralentis par cela (aller-retour initial pour TCP) mais ils seront plus lents s'ils basculent vers HTTPS, en raison de deux autres allers-retours nécessaires pour établir la session TLS vers chacun des serveurs dans le chaîne publicitaire.

Une prise de contact TLS peut être utile pour plusieurs connexions.
Je ne sais pas ce que vous entendez par «connexion», mais une prise de contact SSL est requise pour chaque connexion TCP, bien que vous puissiez faire une prise de contact raccourcie si le client et le serveur peuvent reprendre une session SSL établie. Chaque connexion TCP elle-même peut contenir plusieurs requêtes HTTP (keep-alive), mais uniquement vers le même serveur. Donc, si vous avez plusieurs serveurs (par exemple, des réseaux publicitaires), vous aurez besoin de plusieurs connexions et vous devez également configurer plusieurs sessions SSL.
Je ne vois pas vraiment pénaliser les réseaux publicitaires comme un inconvénient :)
Concernant votre troisième point, je pense que la DHE peut être utilisée comme mesure DOS, mais je ne pense pas que les performances du processeur soient vraiment importantes sur les ordinateurs de bureau et les appareils mobiles, même si je suppose que nous pouvons nous permettre le coût sur le serveur. À propos de l'utilisation de TLS pour la communication interne des services ... Je pense que les gens commenceront à utiliser ACL et VPN dès qu'ils verront l'impact de TLS, donc il n'y a aucune raison de s'inquiéter à ce sujet tant que nous pouvons configurer le système pour désactiver TLS.
#3
+11
Mike Precup
2014-08-07 23:26:33 UTC
view on stackexchange narkive permalink

Une raison que je n'ai pas encore vue mentionnée est que, aussi archaïque que cela puisse paraître, certains clients peuvent ne pas prendre en charge TLS / SSL. C'est un cas spécialisé, bien sûr, et implique généralement des systèmes embarqués ou hérités, mais malheureusement, certains existent encore.

Le premier exemple qui me vient à l'esprit est un microcontrôleur personnalisé que nous utilisions, où nous ' d sous-estimé la quantité d'espace dont nous aurions besoin et n'allions pas pouvoir inclure la taille d'une bibliothèque SSL. Nous avons fini par avoir besoin de le supprimer et de communiquer via HTTP standard à la place, et nous avons été très reconnaissants que le serveur qui en ait tiré des données offrait les deux méthodes.

Nous avons également rencontré un système hérité il y a quelques années. empêché l'utilisation de TLS / SSL. Un projet pour lequel un de mes amis a été embauché impliquait la mise en place d'un serveur Web distant et d'un client automatisé dans une université. Le script client s'exécutait dans un environnement désuet et fortement bac à sable à l'université - chaque partie de la compilation était gérée par un système automatisé et l'ensemble des bibliothèques auxquelles on pouvait accéder était une liste codée en dur.

S'agit-il de assez commun pour justifier d'éviter TLS / SSL dans des cas normaux? Je dirais non, mais il y a des moments où ils peuvent être importants. Si vous écrivez un logiciel principalement destiné à communiquer avec des systèmes embarqués, j'y réfléchirais à deux fois avant de proposer uniquement TLS / SSL.

Vous pouvez configurer un proxy de suppression SSL entre le microcontrôleur et le périphérique intégré. Bien que vous deviez tenir compte de l'impact sur la sécurité, comme les services qui offrent une connexion SSL uniquement le font généralement par souci réel. Si vous souhaitez tout de même offrir un peu de protection, vous pouvez réenvelopper la connexion entre l'appareil et votre serveur proxy avec un schéma de chiffrement personnalisé qui a une plus petite surcharge.
Microcontrôleur @LieRyan = périphérique intégré, donc un proxy de suppression de SSL entre le périphérique et lui-même?
Je voulais dire entre l'appareil embarqué et le serveur
@LieRyan: "... le fait généralement par souci réel" et la mentalité moderne de "TLS / SSL partout" se heurte un peu. Soit il * y a * des préoccupations réelles / spécifiques (ce qui signifie que * ne pas * le faire est justifiable dans d'autres cas), ou l'utilisation de TLS / SSL est simplement "ce que vous devriez faire" ces jours-ci (et les préoccupations réelles sont facilement noyées par tous les chanter les meilleures pratiques).
#4
+9
Insecure
2014-08-07 19:31:22 UTC
view on stackexchange narkive permalink

Une autre remarque à ce sujet, comme je ne la vois pas spécifiée dans votre question, est que tout le monde semble avoir fait le saut pour suggérer que lorsque vous avez posé des questions sur TLS / SSL, vous vouliez simplement dire HTTPS. Puisque vous mentionnez les communications TCP, vous pouvez également envisager l'utilisation de TLS / SSL pour d'autres applications qui s'exécutent dessus en plus de HTTPS.

Ce qui vient à l'esprit est TLS / SSL tel qu'utilisé par SMTP. Quand il s'agit d'utiliser TLS / SSL pour les communications SMTP, personnellement, je ne m'y fierais jamais comme méthode maintenable pour la sécurité (notez que je veux dire les communications SMTP, pas l'utilisation de TLS / SSL pour assurer la sécurité entre un client de messagerie et le courrier serveur). La raison pour laquelle je dis cela est la nature inhérente de TLS / SSL. Vous recherchez une connexion de socket sécurisée point à point en cours d'adaptation pour un mécanisme de communication à sauts multiples.

Donc, même si vous forcez l'utilisation de TLS / SSL pour vos connexions SMTP, vous ne pouvez vérifier que la connexion était sécurisée à un saut de votre serveur. Comme la plupart des flux de messagerie ont plusieurs sauts comme celui-ci:

serveur de messagerie -> solution AV -> Internet -> Solution AV -> serveur de messagerie

Et l'utilisation de solutions audiovisuelles tierces dans le cloud devient de plus en plus importante, il est difficile de garantir que TLS est utilisé pour chaque saut entre deux organisations.

Par souci d'argumentation (comme je l'ai fait), disons que vous prenez le temps de sécuriser ce trafic SMTP entre deux sites en vérifiant chaque saut entre les sites force TLS. C'est bien beau pour aujourd'hui, mais que se passe-t-il lorsque l'infrastructure change dans 5 ans? Si vous ne faites pas attention, par exemple, lorsque la solution audiovisuelle est modifiée / remplacée, vous pouvez facilement laisser un bond sans forcer TLS.

Je voulais juste jeter cela là-bas comme une autre implémentation TLS pour le brainstorming (et BTW si vous avez besoin d'un e-mail sécurisé, j'utiliserais la route S / Mime pour crypter le message du côté de l'expéditeur et le décrypter sur le destinataire côté). Comme pour tout outil, vous devez utiliser le bon outil pour le bon travail

"Si le seul outil dont vous disposez est un marteau, chaque problème devient un clou"

#5
+7
valentinas
2014-08-07 08:47:20 UTC
view on stackexchange narkive permalink

Non.

Les excuses habituelles sont les performances et le prix, mais les deux sont de mauvaises raisons. La performance est minime (je reste corrigé. D'autres affiches ici soulignent des métriques intéressantes. Je pense toujours que "TLS est un must" est une bonne ligne directrice générale) et le prix est bas aussi - la plupart les gens dépenseront ordres de grandeur plus que cela pour le café).

Rétrospectivement, il aurait dû être intégré au protocole HTTP, mais à nouveau le jour où personne n'a pensé que HTTP évoluerait pour devenir quelque chose qu'il est aujourd'hui. À l'époque, il était utilisé pour transférer des documents hypertextes sans aucune garantie d'intégrité, de sécurité ou autre.

[Lorsque la solution numéro un suggérée à un problème est "l'accélération matérielle", elle n'est pas minimale] (http://www.cs.rice.edu/~dwallach/pub/tls-tocs.pdf)
#6
+6
cweiske
2014-08-08 14:07:14 UTC
view on stackexchange narkive permalink

Pendant le développement, SSL rend le débogage des connexions HTTP tellement plus difficile. Vous pouvez sûrement enregistrer les certificats de serveur dans Wireshark, mais c'est très compliqué.

Donc, pour le développement, je l'ai presque toujours désactivé.

* Vous pouvez sûrement enregistrer les certificats de serveur dans Wireshark * Si vous utilisez des protocoles autres que HTTP, Wireshark est probablement un bon outil pour ce travail. Mais des outils spécialisés comme Fiddler [peuvent automatiquement MITM vos connexions HTTPS pour vous] (http://docs.telerik.com/fiddler/configure-fiddler/tasks/decrypthttps).
Je préfère mitmproxy, car Fiddler ne fonctionne que sur Windows. Mais il est toujours plus difficile de configurer le proxy dans votre application que de simplement démarrer WireShark et jeter un œil aux packages.
Le proxy Burp n'a également aucun problème à intercepter SSL.
#7
+3
Jeff-Inventor ChromeOS
2014-08-11 03:58:16 UTC
view on stackexchange narkive permalink

J'ai déjà écrit une réponse à cela sur Quora:

https://www.quora.com/If-HTTPS-is-more-secure-than-HTTP-why-dont -all-sites-use-HTTPS? s = 1

Il y a 10 ans, j'aurais été d'accord avec les autres réponses que HTTPS est inutile pour la plupart des sites Web. Aujourd'hui, je ne suis plus convaincu que ce soit facultatif.

  • Les connexions chiffrées réduisent les possibilités de suivi des FAI et du gouvernement, tous deux un problème dans la plupart des pays, y compris aux États-Unis.
  • Les connexions chiffrées réduisent les possibilités de malwares et d'usurpation d'identité en ligne.
  • Les connexions chiffrées compensent dans une certaine mesure l'insuffisance de l'infrastructure DNS non sécurisée.
  • Le navigateur applique une politique de sécurité légèrement plus élevée pour les connexions HTTPS, réduisant les opportunités de piratage sur le client quel que soit le canal de communication.
  • Si HTTPS n'est pas présent, même une fois, pour un site Web, un utilisateur est vulnérable à tous des attaques ou du suivi ci-dessus.
  • Un ordinateur piraté une seule fois appartient au pirate informatique, pour toujours ou jusqu'à ce qu'il soit reformaté et restauré dans un état sûr.

Le coût du HTTPS est également minime pour chaque connexion Web.

  • Le coût du processeur du cryptage 256 bits est très faible, comparable ou faible wer que des algorithmes de compression.
  • La latence supplémentaire d'environ 500 ms de la négociation SSL à 7 voies ne se produit qu'une seule fois par connexion Web.

Les avantages l'emportent largement sur les coûts dans l'environnement informatique moderne sur Internet. Écrit le 3 juillet.

#8
+2
paj28
2014-08-07 12:10:11 UTC
view on stackexchange narkive permalink

L'une des raisons qui me vient à l'esprit est IPsec.

De nos jours, le chiffrement sur les réseaux internes est reconnu comme une pratique de haute sécurité. Ce n'est probablement pas une pratique standard pour le moment, mais c'est dans ce sens.

IPsec a quelques avantages par rapport à TLS pour le chiffrement du réseau interne. Principalement parce que si vous allez tout crypter, alors c'est un protocole conçu pour tout crypter, ce que TLS n'est pas.

Il est normalement inutile de faire un double cryptage, donc si vous utilisez IPsec en interne, c'est généralement une mauvaise idée d'utiliser également TLS.

Ce n'est probablement vrai que si vous utilisez IPsec partout et DNSSEC pour tout, en vous assurant que chaque résolveur de nom vérifie correctement la réponse DNS. Je n'ai jamais vu ça. En pratique, TLS sur IPsec est une bonne idée.
@BrunoRohée - la question était "y a-t-il ** jamais ** une bonne raison ..."
#9
+2
anon
2014-08-11 06:22:53 UTC
view on stackexchange narkive permalink

Le chiffrement aveugle les dispositifs de surveillance du réseau (IDS / IPS / etc). Selon le réseau, on peut choisir de ne pas crypter le trafic. Au lieu de cela, tirez parti d'IPsec pour garantir l'intégrité du trafic tout en lui permettant de passer en clair. Fournissant ainsi un accès complet aux dispositifs de surveillance du réseau sans la surcharge du cryptage.

#10
+1
Dominic Cronin
2014-08-09 14:08:46 UTC
view on stackexchange narkive permalink

Clair et simple: lorsque la sécurité n'est pas requise. En d'autres termes, lorsqu'un visiteur anonyme navigue sur votre site Web public, HTTP est suffisant et l'ajout de protocoles de sécurité est inutile et coûteux. (Comme d'autres l'ont noté, c'est également un gaspillage des ressources d'autres personnes car cela interfère avec la mise en cache.)

La plupart des sites Web fournissent des informations à usage général sans exigences de sécurité particulières. Évidemment, si votre site contient des informations que les gens peuvent utiliser dans un contexte où la fiabilité du contenu est essentielle, alors bien sûr, vous ne tombez pas dans cette catégorie et vous devriez envisager des mesures telles qu'un site uniquement HTTPS.

Vous ne savez jamais à l'avance quel type d'information pourrait être critique.
Christian - Je ne sais pas dans quel sens vous utilisez "on ne sait jamais". Êtes-vous en train de dire que plus de sécurité est toujours mieux? L'essence de cette question est de savoir si https est toujours meilleur. Je dis qu'un propriétaire de site Web / peut / évaluer ses besoins en matière de sécurité, et que pour de nombreux / la plupart des sites Web, cela n'aide pas. Ma maison a une serrure sur la porte d'entrée, mais pas sur la porte du jardin.
Le peut évaluer leurs besoins en matière de sécurité, mais pas les besoins des visiteurs, surtout si le propriétaire du site Web n'a pas beaucoup d'informations sur les visiteurs.
La plupart des sites Web savent exactement quel est leur public cible.
Tous les utilisateurs du site Web ne font pas partie du public cible. Il n'est pas non plus anodin de comprendre ce que quelqu'un peut faire avec la connaissance des habitudes de navigation: un attaquant peut créer des profils de personnalité grâce à des corrélations complexes que vous ne voyez tout simplement pas lorsque vous pensez à votre site Web.
Christian - c'est comme dire que je devrais mettre une serrure sur la porte de mon jardin parce que quelqu'un pourrait suivre le facteur et décider de le muger parce qu'il a rendu visite un mardi. Il existe des défenses plus appropriées que la sécurité générale du transport. Une certaine paranoïa est justifiée, mais il y a vraiment beaucoup de situations où le simple http (ou tout autre protocole) convient. Même avec TLS / ssl, vos modèles de navigation sont toujours visibles, à moins que vous n'utilisiez quelque chose comme tor, auquel cas vous n'avez fait que déplacer le problème.
Vous avez oublié quelque chose de critique que TLS fournit aux clients: la confidentialité. Un adversaire peut voir que vous avez accédé à une certaine adresse IP, mais ne peut pas voir le contenu ni le modifier. En tant qu'utilisateur, je le souhaite pour CHAQUE site que je visite. Il est extrêmement simple d'exécuter un MITM et de réécrire les pages Web comme bon vous semble. TLS protège les utilisateurs contre les écoutes téléphoniques et la falsification.
Naftuli - Je ne l'ai pas oublié. Je ne lui accorde pas autant de valeur que vous. La plupart des sites proposent un contenu qui n'est pas critique. Si je me présente une demi-heure de retard au match de cricket du village parce qu'un farceur a interféré avec ma connexion au site du club de cricket, le monde ne se terminera pas. Votre question était de savoir s'il y avait jamais une bonne raison de ne pas sécuriser le trafic. Ma réponse est: oui, parfois les avantages sont inférieurs aux coûts.
C'est une réponse raisonnable à la question que vous avez posée, surtout compte tenu de votre stipulation de «bien faire les choses». Votre question devrait peut-être refléter votre point de vue selon lequel tout doit être sécurisé.
Le fait que vous n'accordiez pas de valeur à votre vie privée ne signifie pas que vous pouvez être sûr que vous n'avez pas d'utilisateurs qui apprécient leur vie privée.
Christian - si vous devez justifier le budget, vous ferez ces jugements. Pour un site Web normal, le désir de confidentialité de votre visiteur est sa propre préoccupation. Vous vous souciez peut-être suffisamment de la façon dont ils perçoivent que vous investissez dans une sécurité supplémentaire, ou non.
@Christian Ce n'est pas parce que les utilisateurs attachent de l'importance à leur vie privée que cela compte.
Je conviens que cela peut être un fardeau lorsque vous recevez un avertissement de certificat pour un site auquel vous ne feriez pas trop confiance et qui n'est utilisé que comme cryptage opportuniste. Cependant, c'est un problème côté client. Je trouve un problème plus important lorsque vous ** voulez ** une couche sécurisée et que le site ne la fournit pas, même pas en changeant manuellement le protocole en _https_ (et parfois il est configuré, mais pas activé pour la page / sous-domaine) . Même si vous ne pensez pas que beaucoup de gens auront besoin de TLS pour votre service / page Web, vous devez fournir https comme facultatif si ce n'est pas un gros problème pour vous.
#11
+1
Damian Yerrick
2014-08-10 10:08:43 UTC
view on stackexchange narkive permalink

La plus grande excuse que les gens donnent pour ne pas utiliser TLS est probablement l'hébergement Web d'entrée de gamme à l'ère de l'épuisement des adresses IPv4. Les hébergeurs Web bon marché utilisent l'hébergement virtuel basé sur le nom pour regrouper les sites Web de dizaines d'abonnés sur une machine derrière une adresse IP. Lorsque j'avais l'habitude d'héberger mon site personnel sur Go Daddy, j'ai constaté que mon domaine était l'un des plus de mille sur une seule IP. L'utilisation de HTTPS avec un hébergement virtuel basé sur le nom nécessite un ajout relativement récent à TLS appelé Indication de nom de serveur (SNI). Presque tous les principaux navigateurs Web encore utilisés, à l'exception du navigateur Android sur Android 2.x et d'Internet Explorer sur Windows XP, prennent en charge SNI. Quelques fournisseurs d'hébergement bas de gamme offrent un service SNI, mais peu le font en raison des problèmes de support que IE / XP et Android 2 causeraient. Vous devrez peut-être payer plus pour passer à un VPS.

Une seconde est le coût récurrent d'un certificat d'une autorité de certification commerciale bien connue. Même si vous utilisez une autorité de certification qui offre un niveau de service sans frais, comme StartSSL, c'est toujours un travail manuel tous les 12 mois pour réémettre et réinstaller le certificat.

Enfin, de nombreux réseaux publicitaires ne fonctionnent pas dans les pages HTTPS en raison du blocage de contenu mixte des navigateurs Web. AdSense est le seul à qui je puisse penser, et il n'a proposé HTTPS qu'en septembre 2013.

#12
  0
OuzoPower
2018-07-27 12:23:04 UTC
view on stackexchange narkive permalink

Je ne peux pas répondre à votre question quant à la sécurité des communications et des performances, mais je vois une bonne raison pour laquelle un World Wide Web exclusivement HTTPS pourrait être dangereux.

Quand l'heure d'une machine cliente est n'est pas correctement défini, cela entraîne des problèmes de certificat pour la navigation sur le Web.On peut l'observer lorsque la batterie CMOS ne tient plus la charge.Bien sûr, dans ce cas, on peut à nouveau régler l'heure correcte dans le système d'exploitation.

Cependant, si un virus était capable d'apporter des modifications permanentes à l'heure du système d'exploitation sur un grand nombre d'ordinateurs, il provoquerait une panne Internet pour les sites https: //.

Une brève note sur _comment_ une horloge système incorrecte sur le client peut entraîner des problèmes de certificat serait utile.
@PhilipRowlands Une partie est [discutée ici] (https://security.stackexchange.com/q/71364/5405), mais on constate également que TLS ne s'appuie pas sur lui.
Rendre un tas de sites Web inaccessibles est mieux que l'alternative de régler l'horloge pour qu'ils puissent MitM avec des certificats faibles ou exposés.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...