Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
SSL/TLS n'a jamais garantie que ton interlocuteur ne fera pas n'importe quoi avec les données que tu lui envoie.Envoyé par Farnsworse
Pour reprendre ton exemple, facebook a un certificat SSL, ça l'empêche pas de revendre tes données.
SSL/TLS te garantie qu'aucune autre personne que ton interlocuteur ne pourra lire les données transmises.
On est bien d accord que c'est bénéfique pour renforcer la sécurité de l'internet mondial.SSL/TLS te garantie qu'aucune autre personne que ton interlocuteur ne pourra lire les données transmises.
Idem que certains, je suis très sceptique...
N'importe qui peut faire un certificat aujourd'hui, c'est facile et gratuit.
Mais "personne" ne peut créer un certificat signé par une authorité de certification.
Il faut demander à cette authorité de faire le certificat et payer pour ça.
Un certificat est considéré comme de confiance par un navigateur seulement si il a été signé par une authorité de certification considérée comme "de confiance" par le navigateur.
Le boulot de cette authorité est de ne pas délivrer n'importe quoi à n'importe qui et de précieusement conserver ses clés de signature privées.
Par exemple quand l'authorité de certification comodo a été hackée, il y a eu génération de certificats signés par comodo non délivrés par comodo.
Et du coup les navigateur considéraient ces certificats comme "de confiance" alors que c'étaient des certificats générés par des pirates.
Si des certificats délivrés gratuitement (Donc a priori sans contrôles ou presque) sont émis par une authorité considérés comme "de confiance" par la majorité des navigateurs, le web sera MOINS sécurisé qu'aujourd'hui.
Délivrer des certificats gratuitement d'accord.
Mais il ne faut pas que ces certificats soient considérés par les navigateurs comme émis par une personne de confiance.
Sinon le phishing va vachement mieux marcher dans pas longtemps.
Bonjour,
Il ne faut pas oublier que pour le TLS/SSL, il faut que le client récupère la clé publique.
TLS/SSL va nous assurer que les paquets reçus ont bien pour origine le site visité à condition d'avoir récupéré la bonne clé publique.
La question qui se pose alors c'est "où héberger ma clé publique" ?
Il me paraît évident qu'on ne peut pas héberger notre clé publique sur notre propre site, sinon, comment s'assurer que la clé reçue par le client est bien la nôtre ?
C'est un des rôles majeur des organismes de certifications d'héberger nos clés publiques.
Or, tout le monde ne peut ou ne veut pas nécessairement payer plus de 50€/ans.
Des certificats, on peut en générer gratuitement sans aucun problème, le principal obstacle, c'est de le faire reconnaître par un organisme de certification afin d'éviter d'affoler nos visiteurs avec les messages "certificats auto-signés" mais aussi afin d'éviter le problème de sécurité que j'ai évoqué plus haut.
Après si les informations du certificats ne sont pas toutes vérifiées, ce n'est au final pas si grave à partir du moment où on fera une petite distinctions (ex. cadenas bleu pour les "gratuits", cadenas vert pour les "vérifiés").
Il faut comprendre que pour un bête forum, on a pas forcément besoin de faire vérifier la localisation du siège social par exemple.
Pour le pishing, rien n'empêche un utilisateur d'avoir un site faceboook.com et de le faire "vérifier".
Le plus difficile étant ensuite de "disparaître" ou de frauder la "vérification". Mais le pishing est toujours possible.
Mais pourquoi s'enquiquiner à mettre du https ? Si l'utilisateur ne vérifie pas l'url, va-t-il vérifier si la page est bien en https ?
L'argument du pishing ne me paraît donc pas pertinent.
Après, je n'ai pas regardé en détails, mais il serait peut-être possible de vérifier si un domaine avec certificat "gratuit" ne ressemble pas un peu à un domaine avec certificat "payant" avant de valider le certificat "gratuit".
Bien sûr que si, ils fournissent exactement les mêmes garanties de sécurité, modulo les mêmes hypothèses.
Je ne vois pas le rapport.
Pourrais-tu argumenter ?
Bon j'aurais peut-être dû mettre "héberger" entre quotes ou le remplacer par "garantir la validité de notre clé".
C'est vrai que j'aurais dû être plus clair.
http://www.securite-informatique.gou...article19.html
Pour cela, l’autorité de certification signe avec sa propre clé privée un message contenant entre autres, l’identité du propriétaire de la clé, la clé publique, l’usage possible de la clé, selon une politique de certification définie. Ce message particulier est appelé certificat de clé publique et est normalisé par le format X.509v3.
Les pirates pourront envoyer des mails avec des liens vers des sites avec un cadenas sans warning du navigateur sur l'identité du site. Le cadenas est considéré par beaucoup comme un gage de sûreté (Certaines banques entre autres ont communiqué sur le cadenas) et l'utilisateur risque donc de encore moins contrôler l'URL.
Moi oui, mes logiciels plus rarement!
Si j'utilise un signet (bookmark) ou l'historique pour aller directement sur https://mabanque ou https://monfai je sais que je suis sur le bon site, parce qu'il n'y pas la place pour une faute de frappe.
Et ensuite j'enregistre mes mots de passe, donc le navigateur les remplit pour moi. Donc je ne peux pas être victime d'un autre site.
Si je reçois un courriel non demandé, et que je clique sur un lien sans vérifier, et que je fais confiance au site sans vérifier, là par contre...
Sur Firefox et Google Chrome tu peux voir dans les infos du site si tu as régulièrement visité le site, c'est une bonne indication en cas de doute. Bref il n'est pas très difficile d'éviter ce genre d'arnaque.
En gros tu préfère laissée les sites sans sécurité juste parce que quelque personnes risquent de l'utilisée a des fins frauduleuse ?liens vers des sites avec un cadenas sans warning du navigateur
Si j'applique ton raisonnement on aurait pas fait grand chose en informatique.
D'autant plus que le problème que tu soulève ne vient pas du https mais juste de l'interface graphique de certain navigateur.
Je ne vois pas à quel problème d'interface tu fais allusion.
Le cadenas vert c'est purement visuel.Je ne vois pas à quel problème d'interface tu fais allusion.
Exact.
Alors il faut leur expliquer à quoi sert à un cadenas, ce qu'est une session sécurisée, etc. Ce n'est pas bien compliqué.
Il suffit de ré-informer les gens. Les gens ne sont pas stupides (pour la plupart), juste mal informés.
Certaines banques (la plupart?) disent et font n'importe quoi.
En plus elle déconseillent (ou interdisent explicitement) le plus efficace moyen d'éviter dans tous les cas le phishing : enregistrer le mdp dans le navigateur.
Parce que tu crois qu'un utilisateur incompétent (au point de gober les inepties sur le cadenas-qui-garantit-qu'il-n'y-a-pas-de-risque) a une chance de faire la différence entre le bon domaine et un nom de domaine vaguement similaire?
ma-banque.fr
mabanque-secure-login.fr
mabanque.ru
mabanque-secure-login.ru
mabanque.secure-banking.ru
mabanque.secure.banking-service.ru
etc.
Beaucoup de messages de phishing sont consternants de bêtise.
Votre bank SFR veu vous remboursé de l'argen mai elle a besoin de votre numero de compte banquère.
Si les gens se font prendre malgré les indices flagrants, ce n'est pas la distinction HTTP/S qui va faire une différence!
Tu voudrais quoi à la place?
Le vert + un cadenas donne trop confiance, peut être un peu surligner le faite que le site soit en https ?Tu voudrais quoi à la place?
De toute façon le cadenas l'utilisateur incompétent s'en fou complètement, il ne sait pas ce que c'est donc avec ou sans cadenas sa change rien.
La différence entre :
https://www.mabanque.com et http://www.mbanque.com (la faute et fait exprès) que se soit vers ou pas sa change rien.
Donc je préfère que 1000 personnes se fassent avoir (de leur faute) plutôt que 100000 personnes se fassent pirater parce que la connexion avec le site n'est pas cryptée (ce qui ne sera pas de leur faute, mais du site web parce qu'il n'a pas envie de payer 80$/ans)
Je ne comprends pas ce qui change ni le rapport entre "satisfaire des exigences" et SSL/TLS. Quand est-ce que HTTPS a eu un "niveau d'exigence" (autre que concernant la crypto lors de la connexion) et "une PSSI stricte"?
Tu as l'air de penser que la généralisation de HTTPS est un souci. La généralisation de la crypto solide entre clients et serveurs me semble une très bonne chose.
HTTPS est un protocole reposant sur la cryptographie qui a pour but de protéger des communications, des données échangées entre deux logiciels. C'est un simple outil.
On ne peut pas demander à un protocole plus que ce pour quoi il est conçu.
Ok, je comprends ce que tu voulais dire.
En effet un certificat, pour être reconnu par les navigateurs, doit être authentifié par une "Autorité".
Où tu as vu qu'un certificat coûtait minimum 50 €?
C'était peut être le cas il y a 5 ou 10 ans, mais aujourd'hui les autorités de certification font des certificats basiques "low cost" (pas de garantie financière, pas de joker).
Il n'y a pas de différence technique entre un certificat gratuit et un payant, il y a des différences entre certificat "de base" et "EV".
J'ai dû mal m'expliquer, un web tout en httpS why not! bien au contraire, si on pouvait utiliser des brides SSL pour tout le web ça ne contrarierait que les gros netspy et autres bourrepif ;]
Mais quand on s'adresse à un site sensible, institutions, banques,
espace de transactions, ce sont des domaines qui doivent répondre à des exigences fortes, plus conformes au domaine d'activité, au contexte.
On sait très bien qu'un site même un httpS ne garantit pas une politique de sécurité stricte sur l'ensemble complet du site, et encore moins si cette politique est maintenue, alors, on oppose à ces entités un httpS avec signature, vérifié et signé par une autorité de certification.
Après un audit de sécurité du site?
Comme le navigateur afficherait cette information essentielle? Avec une interface inspirée des certificats "EV"?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager