Question:
L'avantage SSL (sécurité) pour le propriétaire du site Web
Luke Sawczak
2017-09-13 20:33:12 UTC
view on stackexchange narkive permalink

Je connais les nombreux avantages de SSL pour les utilisateurs d'un site Web. Il crée un contrat par lequel l'utilisateur peut être certain que l'entité avec laquelle il traite est bien celle qu'il prétend être et que les informations transmises sont cryptées. J'ai aussi une idée des autres avantages (par exemple, les avantages de vitesse de HTTP / 2).

Mais quelque chose que je me demandais récemment était de savoir si le site Web bénéficiait de la même manière de cette transaction. Autrement dit, mon site Web devient-il plus sécurisé contre les attaques si j'active SSL? Je suppose que parce que je saurais également que le client avec lequel je traite est certifié et que les informations que je leur envoie sont cryptées. Mais aucun client ne peut-il agir de manière contraire à l'éthique et accéder à mon site Web avec des certificats auto-signés, etc., en prétendant être celui qu'il aime?

Au fait, je suis venu dans les connaissances que j'ai dans un de manière autonome, donc s'il s'agit d'une question basique ou d'un problème XY, n'hésitez pas à me diriger vers des ressources élémentaires ou à me mettre au clair.

Modifier: Pour tous ceux qui continuent de répondre ou de commenter avec des raisons générales d'utiliser SSL: celles-ci sont appréciées et sans doute utiles aux nouveaux utilisateurs. Cela dit, j'en fais une partie de chaque site Web que j'ai créé et j'étais curieux de connaître les avantages en matière de sécurité. Dans la tradition SE, je veux juste rappeler aux gens de rester à la question si possible. (Désolé pour le titre manquant à l'origine le qualificatif clé!)

+1 pour l'auto-marquage comme problème XY.(ce n'est pas cependant, bonne question)
Dans la plupart des cas, SSL ne prouve rien du tout sur le client - certainement, la plupart des sites Web n'ont pas besoin que les clients aient une forme de certificat (bien qu'il existe des moyens de l'exiger).Au niveau de base, il permet de chiffrer le trafic dans les deux sens entre un client et un serveur et, dans certains cas, que le client vérifie que le site appartient à un propriétaire spécifique.
L'incitation principale est maintenant que lorsqu'un utilisateur essaie de taper quelque chose sur votre site, il n'obtiendra pas le message "CE SITE EST INSÉCURISÉ N'ENTREZ PAS D'INFORMATIONS SECRETES".
"L'utilisateur peut être certain que l'entité avec laquelle il traite est bien celle qu'il prétend être" est peut-être trompeur.L'utilisateur peut être certain que le propriétaire du site Web est propriétaire du site Web et du certificat de serveur, mais pas que le site Web appartient à quelqu'un en particulier.Un site d'hameçonnage avec un nom de domaine plausible peut toujours utiliser des URL HTTPS mais pas du tout être associé au domaine "réel".Seul EV permet ce niveau de confiance plus élevé.
Lectures connexes / FAQ: https://doesmysiteneedhttps.com/ et https://whytls.com/
Il y a un argument tueur: vos utilisateurs se connectent et quelqu'un peut voler leurs informations d'identification et abuser de votre site.Pensez au webmail.Votre utilisateur est contrarié parce que quelqu'un lit ses e-mails, mais vous rencontrez un problème, car quelqu'un utilise votre serveur pour envoyer du spam via votre serveur et vous met sur la liste noire.
Onze réponses:
#1
+63
user15392
2017-09-13 23:43:58 UTC
view on stackexchange narkive permalink

Cela empêche le FAI de injecter ses propres annonces à la place des vôtres. Si vous comptez sur la publicité pour générer des revenus, https vous aide à protéger votre flux de revenus.

#2
+59
Mike Ounsworth
2017-09-13 20:59:38 UTC
view on stackexchange narkive permalink

Vous avez quelques bonnes questions et quelques idées fausses. Essayons de les démêler.


J'ai aussi une idée des autres avantages (par exemple, les avantages de vitesse de HTTP / 2).

Un autre important one: Optimisation des moteurs de recherche puisque vous obtenez des GooglePoints pour avoir TLS. (ce qui alimente un peu votre point de vue selon lequel les webmasters ont besoin d'incitations externes ...)


Je suppose parce que je saurais aussi que le client avec lequel je traite est certifié et les informations que je leur envoie est crypté. ... Mais aucun client [sic] ne peut accéder à mon site Web avec des certificats auto-signés?

Oui et non, et oui, ... et non. Démêlons cela.

L'authentification client TLS (obligeant les clients à présenter des certificats) est quelque chose que vous voyez généralement sur les serveurs VPN, les points d'accès WiFi WPA2 d'entreprise et les intranets d'entreprise. Ce sont tous des systèmes fermés où l'administrateur système a un contrôle total sur l'émission des certificats aux utilisateurs, et ils l'utilisent pour contrôler quels utilisateurs ont accès à quelles ressources. Cela n'a aucun sens dans un paramètre de site Web public, et c'est certainement une configuration non standard pour un serveur Web HTTPS.

Cela dit, ce que vous gagnez est le suivant:

  Session TLS chiffrée | Le client charge la page de connexion | Le client envoie un nom d'utilisateur / mot de passe | Le client fait des "choses connectées"  

Ainsi, vous gagnez en confiance supplémentaire que l'utilisateur est ce qu'il prétend être car le nom d'utilisateur / mot de passe n'est plus envoyé en clair, donc plus possible pour un homme du milieu d'intercepter / modifier / voler.

Après cela, toutes les données que le client envoie au serveur, ou obtient du serveur, sont chiffrées de bout en bout au client. En général, vous avez raison: cela protège le client plus que le serveur, mais cela empêche les hommes du milieu d'injecter des éléments malveillants dans les fichiers que l'utilisateur télécharge, en injectant des commandes malveillantes à exécuter comme si elles provenaient de cet utilisateur. .


Mais aucun client ne peut-il agir de manière contraire à l'éthique et accéder à mon site Web avec des certificats auto-signés, etc., en prétendant être celui qu'il aime?

Un peu, oui. Pour un site Web public, n'importe qui peut ouvrir une connexion TLS. Si vous voulez que les utilisateurs s'authentifient, vous devez avoir un mécanisme de connexion en haut, TLS ne le fournit généralement pas pour vous (sauf si vous utilisez le mécanisme de certificat client mentionné ci-dessus).


Mais je me demandais récemment si le site Web bénéficiait de la même manière de cette transaction.

Fondamentalement, les avantages pour le serveur sont que toutes les données envoyées à l'utilisateur seront être vu uniquement par l'utilisateur prévu. Si, par exemple, vous leur envoyez des copies de leurs états financiers, vos avocats seront très heureux de l'entendre. Cela signifie également que toutes les données reçues de l'utilisateur proviennent en fait de cet utilisateur, et non d'un attaquant se faisant passer pour eux.

Si vos utilisateurs légitimes agissent de manière malveillante, eh bien c'est un problème différent, après tout, vous avez choisi de leur donner accès au système. Ce que fait TLS (+ votre propre cadre de connexion), c'est s'assurer que seuls les utilisateurs légitimes ont accès. Ce qu'ils font avec cet accès n'est pas le problème de TLS.

Merci, ceci était vraiment utile.Non seulement vous avez dissipé mes idées fausses, mais vous avez également répondu à ma question principale de savoir s'il existe des avantages de * sécurité * pour le serveur.
À la lecture de votre édition, je pense que l'OP a 2 grandes confusions: 1. il y a toujours un client-cert impliqué et 2. que vous ne pouvez pas contrôler la confiance pour les clients-certificats.
@JimmyJames En effet, et j'ai maintenant appris à comprendre les rares cas d'utilisation et la sécurité relative des systèmes qui utilisent * la * certification client.
Comme le souligne le dernier paragraphe, vous ne pouvez pas utiliser la technologie (HTTPS) pour résoudre un problème de personnes (utilisateurs sans scrupules).Vous ne pouvez utiliser la technologie que pour résoudre des problèmes de technologie / de processus (la capacité d'écouter / de modifier la conversation).Après cela, vous êtes seul.
En d'autres termes, il y a un énorme avantage de réputation.
"toutes les données reçues de l'utilisateur provenaient en fait de cet utilisateur, et non d'un attaquant se faisant passer pour eux" - bien, sous réserve d'une définition soigneuse du terme "utilisateur" signifiant "l'autre extrémité de cette session TLS".Que ce soit légalement équivalent à "l'être humain dont nous allons agir comme si les instructions venaient", c'est à la juridiction de votre juridiction de décider ;-)
#3
+21
Xiong Chiamiov
2017-09-14 00:47:12 UTC
view on stackexchange narkive permalink

L'un des principaux avantages pour un opérateur de site est la confiance accrue des utilisateurs ; nous espérons souvent qu'ils vérifient la présence de HTTPS avant de saisir les détails de la carte de crédit dans un site de commerce électronique, par exemple, et le "verrou vert" d'un certificat EV fournit une vérification supplémentaire que le site Web est géré par l'entité qu'ils prétendent être .

Quelle est l'ampleur de l'effet que cela a, je ne sais pas. Le projet Stanford Web Credibility contient une collection de recommandations pour rendre un site Web crédible et HTTPS n'apparaît pas dans la liste. Cependant, les articles cités ici ont tous entre 15 et 20 ans à ce stade. La technologie a beaucoup changé à l'époque, mais la vraie question est de savoir dans quelle mesure les gens ont changé.

#4
+8
Steffen Ullrich
2017-09-13 20:53:15 UTC
view on stackexchange narkive permalink

HTTPS protège uniquement le transport contre le sniffing ou la modification, c'est-à-dire contre un attaquant entre le client et le serveur mais pas contre un attaquant au niveau du serveur ou du client lui-même. Cela ne rend pas le serveur lui-même plus sûr comme par magie ni ne rend le client plus fiable envers le serveur. Cela signifie qu'un serveur protégé HTTPS peut par exemple servir des logiciels malveillants et qu'un client se connectant avec HTTPS peut toujours exploiter des problèmes de sécurité côté serveur comme l'injection SQL ou similaire.

#5
+5
TRiG
2017-09-14 03:48:19 UTC
view on stackexchange narkive permalink

De nombreux navigateurs (Firefox le fait très clairement) avertissent les utilisateurs de ne pas entrer leurs mots de passe sur des sites Web non sécurisés. Les propriétaires de sites Web ne veulent naturellement pas que leurs utilisateurs voient ces gros avertissements effrayants (qui, dans le cas de Firefox, rendent également les informations de connexion remplies automatiquement difficiles à utiliser), et la sécurisation de leurs sites est le seul moyen de s'en débarrasser.

Donc, si le site Web permet aux utilisateurs de se connecter, il y a une forte incitation à ajouter de la sécurité. Il s'agit d'une incitation externe, imposée par les fournisseurs de navigateurs.

#6
+3
Dan Landberg
2017-09-13 21:00:53 UTC
view on stackexchange narkive permalink

Une configuration SSL standard ne fournit aucun avantage de sécurité pour le serveur, en soi. Ils savent qu'ils en acheminent deux et depuis le point d'extrémité qui a fait la demande chiffrée n'a pas été manipulé en transit, mais il n'y a aucune garantie que le point d'extrémité qui a fait la demande ne sert pas de MITM.

Il est possible de configurer SSL de telle manière que vous puissiez valider les clients. La plupart des serveurs Web (Apache, nginx, IIS, etc.) vous permettront de configurer des authentifications basées sur des certificats clients, ce qui signifie que chaque client qui accède au site Web aura son propre certificat unique, et le serveur Web ne servira de pages à aucun client qui n'a pas de certificat valide. La distribution et la maintenance des certificats clients représentent une surcharge importante, ce type de configuration n'est donc généralement effectué que dans des environnements avec un nombre limité de clients, tels que des applications intranet, des API avec un petit nombre d'utilisateurs, etc.

#7
+2
Hrvoje Milković
2017-09-13 23:21:26 UTC
view on stackexchange narkive permalink

Bonnes réponses jusqu'à présent, je veux juste ajouter ce qui suit:

Tous les TLS (anciens SLL) n'ont pas le même niveau de sécurité, il est donc bon de le vérifier par rapport à https: //www.ssllabs. com / ssltest /.

Et TLSv3 a quelques vulnérabilités alors demandez à désactiver dans la configuration du serveur.

Je ne vais pas dire que TLS est à l'épreuve des balles par rapport à MitM comme nous savons que le décapage SSL et le contournement HSTS sont possibles, mais il est beaucoup plus difficile pour un attaquant de le faire car il doit être dans le même réseau que l'utilisateur.

Le plus grand avantage à côté d'une communication sécurisée est que vous obtenez meilleur classement SEO de Google, car les sites Web avec TLS sont plus faciles à atteindre, comme indiqué ici http://searchengineland.com/google-starts-giving-ranking-boost-secure-httpsssl-sites-199446.

Ensuite, en tant qu'entreprise, l'utilisateur final lorsqu'il voit le verrou dans le navigateur Web a un sentiment plus sécurisé, je sais que c'est un peu stupide car j'ai défini de nombreux sites Web statiques avec TLS / HTTPS où aucune donnée ne venait du serveur ou au serveur mais pour des raisons de référencement et d'expérience utilisateur final .

"... chaque TLS (ancien SLL) ...", ne voulez-vous pas dire "... (ancien SSL) ..."?
Il n'y a pas de TLSv3.Vous voulez probablement dire SSL 3.0 (SSLv3) qui a ensuite été suivi de TLS 1.0 (TLSv1), etc.
Oui Steffen désolé, j'utilise Nginx, donc à partir de la configuration, je me suis habitué à dire TLS. Miguel Je veux dire l'ancien SSL car TLS est le nouveau nom de SSL après SSLv3.1 plus d'informations ici: https://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https
#8
+2
Matija Nalis
2017-09-15 07:16:15 UTC
view on stackexchange narkive permalink

Pour jouer l'avocat du diable ici, activer TLS dans votre serveur Web si vous n'en avez pas besoin (c'est-à-dire qu'aucune information sensible n'est transmise entre le serveur et le client) pourrait en fait réduire la sécurité .

Pour la simple raison: cela ajoute beaucoup plus de code, et plus de code signifie plus de bogues et une plus grande surface d'attaque. Vous pourriez donc rencontrer des problèmes tels que Heartbleed, l'exécution de code à distance et d'autres problèmes que vous n'auriez pas autrement.

Bien sûr, le problème est sans objet - il y a certainement beaucoup plus bogues quel que soit le code qui exécute votre Web dynamique que dans la bibliothèque TLS de votre serveur Web, donc à moins que vous n'exécutiez un très petit serveur HTTP audité avec un contenu statique uniquement, la réduction de la sécurité est probablement négligeable.

Et HTTPS ( en plus d'être un bon référencement pour Google et ses amis) pourrait vous protéger de certains maux comme les attaques MitM (encore une fois, en raison d'échecs avec le modèle HTTPS CA, il s'agit principalement de "se sentir bien" "sécurité" car vous êtes obligé de "faire confiance" à des dizaines de CA auxquels vous n'avez absolument aucune raison de faire confiance de quelque manière que ce soit)

Bien sûr, si vous souhaitez éviter cela, vous devez vous assurer que le serveur Web n'héberge ** aucun ** contenu protégé SSL / TLS.Il ne s'agit pas de votre site ou de votre site;il s'agit de savoir si le code est là et en cours d'exécution ou non.
Veuillez être plus clair dans votre réponse que dans tous les cas pratiques, l'utilisation de TLS est une amélioration pour * toutes les parties impliquées *.Je sais qu'il est intéressant d'être contrarié de regarder dans ce genre de sections, mais les gens viennent sur ce site Web pour obtenir des conseils de sécurité et aussi pour justifier * de ne pas faire quelque chose *.Par conséquent, discuter de cas extrêmes comme celui-ci ne serait pas utile.Il est très probable que des personnes lisent uniquement vos deux premiers paragraphes et les laissent en place.
@DCKing J'ai spécifiquement souligné dans le 1er paragraphe que cela n'est applicable que si "vous n'en avez pas besoin (cryptage)" au cas où vous ne manipuleriez aucune information sensible.Les deux derniers paragraphes sont juste une explication supplémentaire que même si vous ** manipulez des informations sensibles **, HTTPS tel qu'il est implémenté aujourd'hui manque malheureusement pour assurer la sécurité du transport.
#9
+1
Micheal Johnson
2017-09-14 02:14:00 UTC
view on stackexchange narkive permalink

L'avantage pour le propriétaire du site Web? Leurs utilisateurs sont plus en sécurité. Il n'y a aucun avantage réel pour les propriétaires de sites Web à part cela, et c'est pourquoi beaucoup de sites Web n'ont toujours pas HTTPS / SSL (car la configuration de HTTP / SSL prend en fait un travail dont le propriétaire du site Web ne voit aucun avantage direct).

Assurer la sécurité des utilisateurs devrait être la priorité la plus importante des propriétaires de sites Web, mais malheureusement ce n'est souvent pas le cas.

#10
+1
Tijmen
2017-09-14 16:01:06 UTC
view on stackexchange narkive permalink

SSL garantit que les gens ne peuvent pas (facilement) prétendre être vous. C'est un plus. De plus, si vous traitez avec des informations personnellement identifiables (PII), SSL fournit une sécurité supplémentaire, ce qui permet d'éviter l'embarras de quelqu'un qui vole les informations de votre client. Dans de nombreux pays, vous êtes légalement tenu de prendre des mesures pour protéger les informations personnelles de vos clients, et SSL est l'une des façons dont vous pouvez le faire.

Si vous souhaitez que votre site Web soit trouvé via Google, SSL présente l'avantage supplémentaire de vous placer plus haut dans les résultats de recherche, bien que légèrement.

J'aime cet angle - que votre «sécurité» dans un sens différent dépend de la sécurité de vos utilisateurs ...
C'est absolument le cas.Si votre entreprise a la réputation de «ne pas se soucier de la confidentialité des clients», cela va être mauvais pour les affaires.Si les informations de carte de crédit de vos clients sont volées sur vos serveurs ou interceptées par une attaque MitM, vous pourriez même être traduit en justice civile.Protéger vos clients est aujourd'hui un must pour les entreprises.De plus, SSL est très bon marché (ou même [gratuit] (https://www.openssl.org/)) de nos jours, il n'y a donc vraiment aucune raison de ne pas l'offrir.(Je ne suis pas affilié à OpenSSL btw.)
#11
+1
Dan Esparza
2017-09-14 20:15:35 UTC
view on stackexchange narkive permalink

Comme d'autres l'ont souligné, SSL (ou TLS) augmente la confiance avec vos utilisateurs .

Unbounce l'a cité dans un article de blog récent:

Comme l'a découvert GlobalSign, un fournisseur de certificats de confiance Web, 84% des les visiteurs du site Web interrogés ont déclaré qu'ils abandonneraient un achat s'ils savaient que les données allaient être envoyées via une connexion non sécurisée .

En fait, cela affecte désormais plus directement les propriétaires d'entreprise: Google Chrome a commencé à marquer les sites non SSL comme "non sécurisés".

SSL / TLS réduit responsabilité envers le propriétaire du site . Le trafic n'est pas facilement usurpé ou intercepté. Vos clients les plus litigieux n'auront pas de raison de vous poursuivre pour négligence.

Vous obtenez un coup de pouce SEO dans les principaux moteurs de recherche , y compris Google. Voir https://moz.com/blog/seo-tips-https-ssl

Cela ne coûte pas cher . Avec des fournisseurs tels que letsencrypt et AWS certificate manager, les certificats SSL / TLS gratuits sont plus faciles que jamais à configurer



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...