Question:
Un site devrait-il avoir SSL s'il n'a pas de formulaire de connexion?
MyMichelle
2013-07-12 18:25:08 UTC
view on stackexchange narkive permalink

Nous avons un site au travail qui est utilisé pour ce qui suit:

  1. Notre page d'accueil, qui ne contient que quelques informations et coordonnées.
  2. Les candidatures sont également traitées sur notre site.

Il n'y a pas d'endroit où vous pouvez vous connecter.

J'ai dit à la direction, vu que nous sommes une entreprise qui fait du génie logiciel, cela ferait une meilleure impression sur les clients potentiels si notre site avait un certificat SSL et si nous appliquions SSL automatiquement sur le navigateur de toute personne qui visite le site.

De plus, même si nous utilisons Gmail professionnel de Google, nous utilisons toujours le même domaine nom de notre site Web tel que nous l'utilisons pour le courrier électronique. En d'autres termes, [email protected] et notre site est company.com. En d'autres termes, les clients potentiels auraient également une mauvaise impression s'ils réalisaient que nous n'avions pas de certificat SSL, car ils penseraient que notre serveur de messagerie n'envoie pas via TLS.

Devrions-nous avoir un certificat SSL même si aucune donnée "sensible" ou "importante" qui doit être chiffrée ne sera envoyée ou récupérée sur notre site?

Vos formulaires de candidature ne nécessitent aucune information personnelle?
Je suis d'accord avec apsillers. Les informations sur une candidature sont des données sensibles et importantes et elles DOIVENT être cryptées.
Le nom et l'adresse seuls sont des informations personnelles.
Il est également plus facile en termes de politique et de développement d'exiger SSL globalement sur le site au cas où vous étendriez les capacités.
De même, l'utilisation de SSL empêche les proxys / routeurs intermédiaires d'ajouter des scripts à la page, comme c'est le cas avec le [upside-down-ternet] (http://www.ex-parrot.com/pete/upside-down-ternet. html)
Les formulaires de candidature à un emploi prennent en effet des données personnelles. La direction ne pense pas que quelqu'un serait intéressé par les données personnelles de nos candidats, mais je pense autrement. Je suis également d'accord avec le commentaire sur SSL empêchant l'ajout de scripts à la page, j'ai lu à propos de nombreux FAI qui commencent à injecter toutes sortes d'informations, même des publicités avec des scripts qui s'ajoutent aux pages qui sont servies via http.
Oubliez les e-mails. SSL / TLS n'améliore PAS la sécurité des e-mails de manière significative. Ce qu'il fait, c'est fournir une certaine protection pour votre nom d'utilisateur / mot de passe en accédant au serveur imap / smtp. La plupart des serveurs de messagerie n'utilisent PAS de cryptage entre les serveurs et vous n'avez aucun contrôle ou connaissance des serveurs par lesquels un message électronique passe dans son itinéraire d'un serveur à un autre. Le courrier électronique est essentiellement non sécurisé, sauf si vous cryptez manuellement les données vous-même et utilisez quelque chose comme PKI
J'utiliserais toujours TLS uniquement pour la vérification d'identité (bien que le système CA actuel soit profondément endommagé).
Voir aussi: [Que dois-je faire si un site utilise le cryptage ou non si je n'échange aucune donnée sensible?] (Http://security.stackexchange.com/q/53980/12139)
Huit réponses:
#1
+29
Adi
2013-07-12 18:57:25 UTC
view on stackexchange narkive permalink

Tout dépend de ce que vous essayez d'atteindre et / ou d'atténuer avec l'utilisation de SSL. Des personnes aléatoires sur Internet ne peuvent pas évaluer les informations de votre entreprise. Vous devez donc garder cela à l'esprit: tout dépend du risque, de la probabilité du risque et de la mesure dans laquelle vous iriez pour atténuer ce risque.

@apsillers apporte un bon point sur vos formulaires de candidature à un emploi, car les candidats potentiels soumettront des informations personnelles avec la certitude qu'ils iront au destinataire prévu. Je suis également d'accord avec le point sur l ' apparence d'un site Web sécurisé et une attitude plus professionnelle lors du clignotement de ce cadenas à un client potentiel, surtout si votre entreprise informatique propose des conseils de sécurité, alors cela pourrait être une bonne idée pour utiliser HTTPS.

Personnellement, je penche toujours vers l'utilisation de HTTPS, même pour un site Web Hello Kitty.

Je suis d'accord. Je n'utiliserais SSL que si le site ne prend aucune donnée du tout.
Mes données sur Hello Kitty sont très sérieuses.
De plus, si vous appliquez SSL, le site serait difficile à usurper car vous auriez besoin d'effectuer une attaque SSL MITM avec quelque chose comme SSLStrip. Mais si le site est uniquement sur le port 80, alors l'arp spoofing fonctionnerait. (Corrigez-moi si je me trompe.) Cela pourrait être une grande menace, par exemple si quelqu'un usurpait notre site et disait à tout le monde que notre entreprise n'existe plus.
@PsudeoReality D'accord. Je placerais la barre sur "si votre site Web n'a aucun formulaire, à l'exception d'une barre de recherche, il est probable que vous n'utilisiez pas SSL." Sinon, il devrait être utilisé.
Actuellement, `https: // hellokitty.com` génère une erreur SSL car il utilise un certificat auto-signé qui a également expiré depuis 2011. [Le site Web de la société américaine] (https://www.sanrio.com/) utilise l'état- TLS 1.2 de pointe avec ECDHE-RSA - comme il se doit. Mais le site Web de [la société principale japonaise] (https://www.sanrio.co.jp) n'est que partiellement chiffré: de nombreuses images sont inutilement référencées par des URL http explicites. En outre, il utilise l'algorithme RSA le plus faible sans secret de transmission.
#2
+21
apsillers
2013-07-12 19:16:04 UTC
view on stackexchange narkive permalink

Le fait que votre site Web puisse contenir des formulaires de demande d'emploi est une raison suffisante pour avoir SSL. En particulier, les utilisateurs s'attendent à saisir des informations personnelles sur votre site Web, mais ils ne savent pas précisément quelles informations.

Laisser une personne indiscrète lire le le contenu d'une demande d'emploi est mauvais, mais il empire. Même si votre formulaire de candidature ne contient pas d'informations extrêmement sensibles (nom, adresse, informations publiques sur le CV), un attaquant actif pourrait réécrire votre formulaire pour le rendre beaucoup plus complet. Peut-être que vous ne demandez pas de numéro de sécurité sociale sur votre formulaire, mais vos utilisateurs ne le savent pas. Ils pourraient être parfaitement heureux de remplir un formulaire modifié par un attaquant avec des demandes de données légèrement plus intrusives.

Si vous ne gérez pas les candidatures directement sur votre site, mais que vous ne fournissez qu'un numéro de contact pour votre service RH, c'est assez mauvais aussi: un attaquant pourrait facilement réécrire vos informations de contact sur son numéro de téléphone portable et prendre les informations personnelles de la victime par téléphone. (Bien sûr, la suppression de SSL peut rendre SSL moins utile ici. Alors qu'un utilisateur peut hésiter à envoyer des informations personnelles via une connexion non sécurisée, même un utilisateur raisonnablement contentieux peut ne pas réfléchir à deux fois avant d'accepter un numéro de téléphone fourni via une connexion non sécurisée. Vous pouvez atténuer Suppression de SSL en utilisant HTTP Strict Transport Security, qui indique au navigateur de l'utilisateur de ne jamais accepter les connexions non sécurisées d'une source particulière.)

En résumé, les informations sensibles fonctionnent dans les deux sens:

  • Toutes les informations sensibles que les utilisateurs envoient à votre site doivent être chiffrées. Les «informations sensibles» peuvent inclure des formulaires de connexion et des cookies de session, mais elles peuvent également inclure des informations personnelles ou même quelles pages ils choisissent de demander à votre site. (Par exemple, la recherche de ressources d'aide fiscale auprès de l'IRS pour des sujets sensibles particuliers peut révéler des informations sur les achats récents importants, les événements majeurs de la vie, etc.)

  • Toutes les informations que votre site envoie à vos utilisateurs doivent être cryptées, si la modification de ces informations peut causer un préjudice important. En particulier, donner aux attaquants la possibilité de réécrire les numéros de contact est un risque important, comme décrit ci-dessus. Peut-être que le seul cas où cette exigence ne s'applique pas est si votre site Web ne contient pas d'informations utiles et que l'utilisateur ne sera probablement pas amené à penser que c'est le cas.

De plus, si un attaquant vient de compromettre un réseau et essaie de découvrir qui est sur le réseau, reniflant le trafic et trouve une candidature non chiffrée sur le fil, il sera très heureux. Vous n'obtiendrez peut-être pas le SSN, mais vous obtiendrez probablement au moins le nom, l'adresse et le numéro de téléphone. Cela suffirait à l'attaquant pour appeler la victime comme si l'attaquant travaillait pour votre entreprise et lui demander son SSN, lui proposer un emploi et peut-être même obtenir des coordonnées bancaires pour «configurer le dépôt direct».
#3
+16
Scott Pack
2013-07-12 23:00:09 UTC
view on stackexchange narkive permalink

SSL offre plusieurs avantages non seulement la confidentialité des données. En présentant un certificat SSL correctement signé, vous avez l'assurance que le serveur auquel vos clients se connectent est le vôtre (supposons que les autorités de certification ne soient pas négligentes).

SSL assure l'intégrité des données. Pour chaque chaîne de texte, livre blanc, image, patch, quoi que ce soit, l'utilisateur peut avoir l'assurance que les informations qu'il voit sont réellement celles que vous présentez (supposons que votre serveur n'a pas été piraté).

L'identifiant visuel d'une session SSL dans votre navigateur fournit un indicateur de niveau PR que votre entreprise se prend au sérieux. Qu'ils veulent que leur message soit entendu correctement. Il y a une implication que l'entreprise sera également tout aussi prudente avec ses données client / client.

S'il est évident que tout site Web qui accepte des informations sensibles doit être crypté , il y a d'autres avantages qui peuvent en valoir la peine.

Personnellement, je suis d'avis que le cryptage SSL est assez bon marché, à ce stade, il n'y a presque aucune raison ne pas de l'activer par défaut. Au moins, si vous modifiez votre modèle commercial et commencez à prendre des informations en ligne, vous n'aurez rien à modifier.

#4
+8
Casey
2013-07-12 22:13:04 UTC
view on stackexchange narkive permalink

Je suis fan de SSL partout. Vous ne transmettez peut-être rien de sensible maintenant, mais vous ne savez jamais si cela pourrait changer.

À mon avis, il n'y a vraiment aucune bonne raison de NE PAS utiliser SSL.

En ce qui concerne les commentaires ci-dessous sur les certificats SSL gratuits, l'EFF a lancé son Let's Programme Encrypt, qui fournit des certificats SSL fiables et gratuits.

Je suis d'accord, vous pouvez même obtenir un certificat SSL gratuit de CACert.org et selon leur article wikipedia, leur certificat racine est distribué avec la plupart des distributions Linux mais pas avec Windows cependant, il agira donc comme un certificat de monopole "réel" / verisign si vous êtes sous Linux.
Aussi d'accord. De nos jours, il existe peu de raisons légitimes de ne pas simplement utiliser SSL. D'après mon expérience, des failles de sécurité se trouvent souvent dans les sites avec des configurations mixtes SSL et non SSL en raison d'une erreur de configuration ou d'une erreur de configuration accessible à partir du site non SSL par erreur. Lorsque SSL représentait une surcharge de traitement importante, il valait la peine de répartir le contenu entre SSL et non SSL. Cependant, cela est moins justifié et étant donné que vous avez déjà des informations sensibles (applications de travail), SSL aurait du sens.
@MyMichelle CACert ne fait confiance à personne d'important, mais [StartCom] (https://www.startcom.org/) offre des certificats SSL gratuits qui fonctionnent
Ajout d'un lien vers le programme EFF Let's encrypt qui propose également (bientôt) des certificats SSL gratuits.
#5
+4
DeepSpace101
2013-07-14 01:29:48 UTC
view on stackexchange narkive permalink

Oui, votre site doit avoir SSL.

  • SSL et ses certificats ne sont pas très chers pour le moment. Bien sûr, vous POUVEZ acheter des certificats très chers, mais le niveau d'entrée est assez bas
  • Vous collectez des informations personnelles côté client et les transmettez au serveur (pourquoi quelqu'un au milieu devrait-il en être informé?)

La valeur par défaut doit être "SSL", sauf si vous avez une raison valable du contraire (par exemple: aucune donnée client ne revient, toutes les données entre le serveur et le client seraient acceptées si elles étaient publiées sur la première page New York Times, etc.)

#6
+2
dprogramz
2013-07-12 21:22:39 UTC
view on stackexchange narkive permalink

Il y a une énorme idée fausse que SSL est une sorte de pare-feu ou quelque chose du genre, ce n'est tout simplement pas vrai. SSL sert à protéger contre les attaques de type Man-in-the-middle ou si le trafic de la passerelle est surveillé lorsque l'hôte ou le client envoie des informations sensibles.

Les plus grands risques que vous courez sont:

  • Les informations de votre site semblent modifiées si la connexion du client est compromise
  • Les clients recommencent à être interceptés
  • Réception du CV du client modifié

Je ne vois pas cela comme votre problème.

SSL n'arrête pas les attaques XSS ou par injection, une bonne programmation le fait.

"" Je ne vois pas cela comme étant votre problème. "" - Vous ne pensez pas que c'est leur problème s'ils manquent des embauches potentielles? Ou pensez-vous que les éléments que vous avez énumérés ne se produiront tout simplement * pas *, que cela * puisse * (par exemple, parce que l'entreprise est trop petite pour une cible)? Ou voulez-vous dire autre chose?
@apsillers Appelez-moi sans cœur, mais personnellement, je ne voudrais pas embaucher quelqu'un avec une connexion compromise, donc je ne manquerais rien.
@dprogramz: Comment vérifiez-vous votre FAI / université / employeur / hôtels / cafés / ... (en supposant qu'ils utilisent le WiFi crypté ET qu'il n'y ait pas d'usurpation d'ARP) pour les failles de sécurité? Traiter avec des connexions ouvertes est une réalité (par exemple - mon FAI est en panne, je dois donc utiliser un café pour naviguer sur votre site Web) et il est relativement sûr si le site utilise SSL / TLS.
#7
+2
Python Novice
2014-04-11 10:26:06 UTC
view on stackexchange narkive permalink

Non seulement vous devez implémenter HTTPS, mais il doit être activé par défaut. Cela me rappelle une citation de l'EFF qui ressemblait à ceci: "dans un monde idéal, chaque requête Web serait envoyée via SSL / TLS." La sécurité et la confidentialité doivent être activées par défaut. Cela ne peut pas être facultatif. Et pour que la confidentialité ne soit pas suspecte, chacun doit faire sa part. Comme d'autres l'ont déjà dit, vous êtes en train d'acquérir des données sensibles (informations personnelles), alors faites attention à vos utilisateurs.

À propos de votre nom d'utilisateur: [http://python.org/ (http://python.org/) vous redirige vers un site HTTPS.
#8
-2
Paarth
2013-07-12 18:32:53 UTC
view on stackexchange narkive permalink

Je ne pense pas qu'il soit utile d'en avoir un si vous ne transférez aucune information sensible dessus. De plus, si vous êtes au point où les gens comprendront le courrier électronique sécurisé, ils comprendront également que les mécanismes du site et les mécanismes du courrier électronique peuvent être très différents. Je ne m'attends pas à ce que quiconque le remarque, honnêtement.

Ne pas voter parce que je pense que les candidatures sont des informations sensibles.
Vous faites des hypothèses. MyMichelle a spécifiquement dit "même si aucune donnée" sensible "ou" importante "à chiffrer ne sera envoyée ou récupérée sur notre site?" J'ai pris l'affiche au mot et leur ai donné des conseils pertinents à ce sujet. Vous et moi ne savons pas quelles informations ils collectent, et jusqu'à ce que nous fassions ce qu'il est injuste de décider en fonction de cela.
Cette réponse montre une confusion concernant le courrier électronique sécurisé (qui est de toute façon un oxymore)


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