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 :
Mais quand est-ce que tu as vu qu'un certificat sert à s'assurer de l'authenticité d'un site ? Et comment tu décides que www.tfun.fr est plus un site de phishing que www.m6.fr ?Envoyé par Farnsworse
Le but est de permettre des communications sécurisées, pas d'empêcher le phising.
Le but de HTTPS est en effet de protéger la communication entre un client et un serveur HTTP, identifié par un nom de domaine, nom présent dans l'URL. C'est la seule chose que garantit le navigateur.
Mais le certificat contient généralement d'autres informations que le seul nom de domaine, informations qui peuvent être vérifiées par l'utilisateur.
Les certificats SSL/TSL de Let’s Encrypt sont supportés par la majorité des navigateurs
Les certificats SSL/TSL de Let’s Encrypt sont supportés par la majorité des navigateurs
l’autorité avance dans son projet de sécuriser le Web
Avec le développement d’Internet, les attaques informatiques de tout genre ont connu une croissance phénoménale. En réponse, plusieurs solutions ont été mises en œuvre en vue d’annihiler les attaques des pirates.
Pour continuer dans ce sens et fournir à tous des moyens de protection efficaces, l’EFF en collaboration avec la fondation Mozilla, Cisco, Akamai, IdenTrust et des chercheurs de l’université du Michigan ont lancé en 2014, le projet « Let’s Encrypt ».
Ce projet a été initié afin de faciliter l’adoption des protocoles de sécurité TLS et SSL sur les sites web. Pour ce faire, Let’s Encrypt a mis à la disposition du public, un outil open source permettant de solliciter, recevoir et intégrer de manière automatique les certificats HTTPS émis par cette autorité pour des serveurs web.
Cela supprime automatiquement la validation d’e-mails, les configurations complexes de serveurs web ou encore l’embarras à cause de l’expiration de certificat. Concernant le dernier point, nous rappelons que Let’s Encrypt conserve les traces d’expiration du certificat afin de le renouveler automatiquement. Aussi, en plus d’éliminer les longues procédures fastidieuses pour l’intégration des certificats sur les serveurs web, Let’s Encrypt délivre ces certificats gratuitement.
Lors du lancement de ce projet, cette initiative a été saluée par tous, car elle permettrait à terme de démocratiser les certificats de sécurité pour les sites web, ce qui empêcherait indéniablement les attaques de types man-in-the-middle, man-in-the-browser ou toute autre attaque du genre.
Des mois s’étant écoulés depuis le lancement du projet, les choses semblent avancer dans le bon sens. En effet, il y a quelques jours, Let’s Encrypt a reçu le soutien d’IdenTrust, l’autorité de délivrance de certificats SSL.
Cela sous-entend que les certificats délivrés par Let’s Encrypt sont maintenant reconnus par la majorité des navigateurs. Cela induit également que les internautes qui vont ouvrir avec leurs navigateurs des sites web utilisant les certificats délivrés par Let’s Encrypt ne verront aucun message d’erreur ou d’avertissement concernant le certificat de sécurité Let’s Encrypt utilisé sur le site. Cette validation constitue une grande avancée dans son programme dont la date butoir a été fixée au 16 novembre prochain.
Mais déjà, certaines personnes peuvent effectuer des tests en utilisant le client ACME (Automated Certificate Management Environment) de Let’s Encrypt avec un serveur Apache 2.x, un serveur autonome ou un serveur Nginx (compatibilité en cours de développement).
Il faut également savoir que pour l’instant, seuls les systèmes d’exploitation Linux et BSD sont compatibles avec le client de Let’s Encrypt. Les utilisateurs Windows PowerShell devront encore attendre jusqu’au lancement officiel des services de Let’s Encrypt en espérant qu’une version compatible sera disponible d’ici là.
Télécharger le client ACME de Let’s Encrypt
Source : Let’s Encrypt
Et vous ?
Voir aussi
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
J'ai regardé il y'a 2 jours, Let’s Encrypt n'est toujours pas disponible, il le sera normalement fin 2015.
Je vais enfin pouvoir certifier mon site (actuellement je m'auto-certifie...).
https://helloworld.letsencrypt.org/ est considéré comme de confiance par 3 navigateurs installés sur ma machine.
On dirait que je suis le seul idiot à penser que faire confiance à Let's encrypt revient à faire confiance aux certificats auto signés...
Pour rappel, un certificat auto signé, ça donne ça (Normalement un gros warning du navigateur).
C'est pas beaucoup plus dur (Et pas plus cher) d'avoir un certificat Let's encrypt que d'avoir un certificat auto-signé.
Mais tout le monde à l'air de trouver ça normal.
Tous les pirates vont se jetter dessus.
Avoir un web encrypté -> sécurité.
Pouvoir créer des certificats de confiance gratuitement et presque sans vérification -> insécurité.
Ce serait peut être pas mal que les navigateurs affichent deux niveaux de sécurité.
1/ Encryption + certificat auto signé/Let's encrypt/autre fournisseur non regardant.
2/ Encryption + certificat par une autorité de confiance, qui fait payer ses certificats et qui vérifie les demandes minucieusement.
Mais tout le monde à l'air de trouver ça normal.
Tous les pirates vont se jetter dessus.
Avoir un web encrypté -> sécurité.
Pouvoir créer des certificats de confiance gratuitement et presque sans vérification -> insécurité.
Pas d'accord:
La plupart des internautes ne savent pas ce que c'est un certificat SSL. Ils pourraient utiliser amazon/ebay sans ssl, sa ne les choqueraient pas.
Le but ici c'est de crypter les messages qui transitent entre le client et le serveur sa apporte donc une bien meilleur sécurité.
Effectivement, mettre un cadenas vert sous prétexte que c'est du https c'est idiot, et inversement mettre un gros warning rouge si le certificat n'est pas certifier c'est tout aussi idiot.Ce serait peut être pas mal que les navigateurs affichent deux niveaux de sécurité.
1/ Encryption + certificat auto signé/Let's encrypt/autre fournisseur non regardant.
2/ Encryption + certificat par une autorité de confiance, qui fait payer ses certificats et qui vérifie les demandes minucieusement.
Il faut que les navigateurs revoie ce code de couleur.
Je pense que ce que rt15 voulait dire, c'est qu'en cas d'attaque MITM il suffit au pirate de demander un certif' à Let's Encrypt pour ne pas être détecté par le navigateur de l'internaute (à supposer qu'il puisse bel et bien obtenir un certificat pour le nom de domaine concerné).
dans un scénario de type MitM tu veux dire (le pirate se fait passer pour la destination en présentant un certificat légitime made in Let's Encrypt, sauf qu'il n'est pas détenteur du domaine), c'est bien ça ?
c'est le cas ? je suis pas allé voir Let's Encrypt, mais il semble évident que pour que ça marche il faudrait des vérifications minimum, s'assurer que le requester soit bien le détenteur du domaine et/ou à minima proscrire deux certificats qui ont le même OU/DNPouvoir créer des certificats de confiance gratuitement et presque sans vérification -> insécurité.
edit: pris de vitesse par xabufr :p
Bonjour, je me suis souvent intéresser à la certification de confiance pour comprendre les pirates et leurs façons de s'introduire sur le pc des Michu.
Ici on peut en avoir un gratuitement donc cela n'a rien de nouveau pour ceux qui le veulent.
Un certificat de class 3 plus dangereux à mon sens bien que l'on trouve des exploits déjà auto signé en class 3 par des AC toujours pas révoqué et bien accepter par nos navigateurs.
n'ayons pas un temps de retard sur la sécurité mettons nous à la place de ceux qui sont mal intentionné et devançons les ....
Il n'y a rien de nouveau avec letsencrypt à part l'automatisation.
Et dire que ça revient à de l'auto signé , c'est un peu abusé...
Letsencrypt utilise le protocole ACME pour vérifier que vous êtes bien le propriétaire du domaine , ce n'est pas différent des certificats gratuit de Class 1 que peut délivrer par exemple StartSSL.
Après c'est vrai qu'un certificat de Class1 est loin d’être aussi sécurisant qu'un certificats EV alors que les 2 afficheront le cadenas vert.
Les éditeurs de navigateurs devraient clairement revoir l'affichage des niveaux de certification d'un site web.
dans la continuité / pour info :
ça répond donc à la question que je posais plus haut
Bonjour,
Je reprend cette discussion un peu tard. Je vais essayer d'apporter un peu d'informations sur le sujet à propos du SSL.
En fait ce qu'il faut comprendre, c'est que pour la majorité des gens, SSL = cadenas = sécurisé mais il faut voir bien plus loin que ça.
Le certificat SSL a deux fonctions, la première que vous citez tous, c'est le chiffrement des données entre le client (navigateur) et le serveur pour éviter que celles-ci soient interceptées par une personne mal intentionnée.
Sur ce point, vous pouvez être d'accord, presque tous les certificats SSL se valent (à condition d'utiliser des tailles de clés et des algorithme de hash qui ne sont pas encore vulnérables).
Pour cela, la démocratisation des certificats restent une très bonne chose si cela permet de sensibiliser les néophytes sur l'utilisation du HTTPS et des certificats.
Il m'est arrivé plus d'une fois qu'un un amis me demande "tiens au fait, là depuis un mois je vais sur facebook mais il m'affiche toujours cette erreur de certificat, j'ai beau accepter, ça reviens toujours".
Oui, malgré le fait que le navigateur l'avertisse qu'il accède à un site non sécurisé, la possibilité d'usurpation, ect... ça ne l'a pas empêché d'accepter l'exception et de se connecter par identifiant/mot de passe sur son compte facebook (heureusement pour lui, juste un problème d'horloge et de mauvaise date qui rendait donc le certificat non valide). Ceci n'est qu'un cas parmi tant d'autres. Cela montre que les utilisateurs non sensibilisés, n'ont pas consciences des risques et des "dangers" qui pullulent sur le net.
La seconde fonction du certificat, c'est aussi d'apporter des informations sur le propriétaire du domaine. C'est sur cette deuxième fonction, je trouve que les navigateurs (où tous les magasins de certificats de confiance) tendent trop vers la simplicité.
Aujourd’hui il existe de nombreuses autorités de certifications (AC), qui délivrent différents types de certificats avec des fonctions de vérifications manuelles/automatique qui permettent d'apporter un degré plus ou moins élevé de confiance aux certificats que ces AC délivrent.
Sans rentrer dans les détails vous pouvez retrouver les niveaux suivants pour les certificats SSL Serveur (du plus light au plus "confiant" :
- Certificat délivré sans aucune vérification (certificat à la volé)
- Certificat délivré en vérifiant que vous avez accès au domaine (certificat DV : Domain validated; on vérifie que vous avez le "pouvoir" de placer un fichier sur votre serveur web)
- Certificat délivré en vérifiant le propriétaire du domaine (certificat OV : Organization validated; on vérifie que la personne physique/morale qui demande le certificat est bien le propriétaire du domaine. Cela passe par exemple par la fourniture de document d'identité, document d'inscription au registre du commerce et des société, ect ...)
- Certificat délivré en vérifiant encore plus le propriétaire du domaine (Certificat EV : Extended validation; OV + vérification de l'adresse physique, du ou des numéros de téléphone entre autre).
Aujourd’hui, à part les certificat EV, la fameuse "barre verte", rien ne permet de distinguer les autres types de certificats entre eux, et pourtant un certificat OV apporte plus de confiance pour l'internaute qu'un simple certificat à la volé ou DV.
je pense que c'est sur ce point que les acteurs du marché devraient travailler, c'est à dire pouvoir informer l'internaute du degré de fiabilité qu'il devrait accorder aux sites qu'il visite. Cela permettra alors de vraiment s'assurer que le web devienne un espace de confiance.
Pour aider nos chère navigateurs à faire cela, il y a déjà quelques briques de posées. Reprenons l'exemple des autorités de certification.
Pour être intégré dans un magasin de certificat, une autorité de certification doit en général montrer "patte blanche" et doit pouvoir attester que les certificats qu'elle délivre sont soumis à un certain nombre de contrôles (permettant d'éviter par exemple que n'importe qui puisse demander à intégrer son propre certificat comme certificat de confiance).
De cette manière, l'autorité de certification est automatiquement reconnue comme organisme de confiance, le navigateur peut donc de manière transparente lui faire confiance et se dire que les certificats qu'elle délivre sont valides et que l'internaute peut à son tour leur faire confiance (donc tout cela sous entend que l'internaute fait aussi confiance au navigateur qu'il utilise).
Pour aider tout ce petit monde à se faire confiance, un ensemble de règle à respecter on été définies. Ces règles sont établie sous forme de normes.
En France, nous disposons de la norme RGS (Référentiel Général de Sécurité, version 2.0 qui devrait entrer en vigueur en juillet 2016) définie par le SGMAP et l'ANSSI, pour assurer un espace de confiance en France (Norme qui est elle même basé sur la norme Européenne ETSI).
Cette norme définie un certain nombre de règles que les Autorités de certification doivent respecter pour se voir obtenir la qualification (à savoir que l'obtention de la norme à une durée effective d'un an, donc chaque année, l'AC doit à nouveau être examinée pour garantir qu'elle respecte toujours ses engagements initiaux, mais également, en cas de mise à jour des normes, qu'elle respecte aussi les nouvelles recommandations/obligations).
La norme RGS est elle même ensuite découpé en trois niveaux : RGS *(une étoile), RGS** et RGS***.
Plus vous montez en niveau, plus le certificat est qualifié. pour cela un exemple simple
- Un certificat SSL RGS* peut être délivré en ligne. Pour cela l'AC vérifiera que c'est bien le propriétaire du domaine qui effectue la demande de certificat, elle vérifiera également l'identité du demandeur. Le certificat pourra alors être simplement délivré sous forme d'un fichier logiciel par exemple (type PKCS12).
- Un certificat SSL RGS** disposera des même prérequis de vérification que le SSL RGS*, plus :
- L'obligation de stocker la clé privé sur un boitier cryptographique qualifié
- L'obligation de remettre le certificat en face à face au demandeur (permet de valider de visu l'identité du demandeur).
Nb : Pour les certificats de serveurs, le norme de définie pas de niveau trois étoiles qui est par contre appliqué pour les certificats à destinations des personnes physiques (signature électronique, chiffrement, authentification).
Nb2 : J'ai volontairement pris l'exemple du certificat SSL, même si en pratique, le SSL RGS** n'est quasiment pas commercialisés par les autorités de certifications au vu des difficulté et des coûts relatifs à la délivrance de ce type de certificat.
Donc, théoriquement, un site équipé d'un certificat RGS** devrait obtenir un degré de confiance plus élevé qu'un site équipé d'un SSL RGS*. Pourtant au niveau du navigateur, il n'y aura aucune différence.
Pour revenir au sujet principal de ce sujet, ajoutez à cela qu'il existe encore bien d'autres normes (chaque pays ayant un peu ses normes nationales), qui ont chacune leurs critères de "confiance", ça peut vite devenir un beau bordel pour gérer les magasins de certificats.
Imaginez en plus que chaque éditeur est libre de faire son propre magasin de certificat avec ces propre critères d'intégration. C'est comme cela par exemple que vous pouvez retrouver des site équipé d'un certificat SSL reconnu sur Firefox, et pas sur Internet Explorer ou Chrome (Mozilla utilise son propre magasin de certificat, Microsoft utilise son propre magasin, Adobe dispose de son propre magasin, ...).
Bon je commence à m’étaler sur le sujet alors que ce n'était pas mon envie initiale (on dérape vite quand on se lance à parler de chose qui nous intéressent ^^), je vais donc essayer de conclure simplement et rapidement.
Pour moi l'idée de letsencrypt est très bonne, dans le sens où cela va permettre de sensibiliser les éditeurs web dans la sécurisation de leurs données mais, également les internautes qui seront un peu plus souvent confrontés aux sites utilisant des certificats SSL.
Par contre, le point faible dans tout ça reste la gestions des listes de confiances, c'est à dire, pouvoir savoir à qui je peux faire confiance, qui peut m'assurer que le propriétaire du site est bien celui qu'il prétend être ?
je suis certain que ce problème pourrait être résolu en passant par un système de magasin globale qui définirait une seule liste d'autorité de confiance que toutes les plateformes, navigateurs, pourraient utiliser plutôt que de chacun faire sa propre tambouille dans son coin. Je ne dit pas que c'est simple (qui s'en chargerait, comment homogénéiser les critères d'acceptation, ...).
bref en quelques mots, "A qui puis-je faire confiance ?"
Ps : Pardonnez mes erreurs de frappes, il se fait tard et j'espère que tout ceci, une fois envoyé ne sera pas trop brouillon
------------
Lecture complémentaires pour ceux que ça intéresse (et les plus courageux ^^):
- Le RGS : http://www.ssi.gouv.fr/entreprise/re...-securite-rgs/
- Les normes européennes avec la parution "récente" du réglement EiDas piur harmoniser la confiance entre les pays européen : http://eur-lex.europa.eu/legal-conte...LEX:32014R0910 (remplacera les normes ETSI TS 102 042 et ETSI TS 101 456)
- Cabinet d'audit accrédité pour auditer les autorité de certification souhaitant obtenir les qualifications RGS : http://www.lsti-certification.fr/ind...ation-rgs.html
avec une liste de nombreuses AC qualifiée : http://www.lsti-certification.fr/ima...ste%20PSCe.pdf
Tout ce que tu dis est très intéressant, et ces précisions sont les bienvenues, mais pour moi le problème réside dans le fait que l'utilisateur doive valider ou non quelque chose en fonction d'informations plus ou moins complexes.
Il existe des extensions, comme ssleuth pour firefox (je ne sais pas si c'est disponible pour d'autres navigateurs, ni s'il existe des extensions similaires), qui te donnent une note pour un site, et te fournissent plus d'informations, mais le problème reste entier : l'utilisateur croit accéder à yyyyyyy.zzz, et il va cliquer sur tout pop-up ou n'importe-quoi qui va essayer de lui barrer la route.
Ce problème n'est pas nouveau : pour ceux qui se connectent en SSH sur des machines distantes, combien de fois avez-vous vu des "rsa fingerprint has changed, do you want to continue ?", et combien de fois avez-vous été regarder si la nouvelle empreinte était la bonne ?
On ne peut pas interdire à l'utilisateur de se connecter sur un site s'il clique "oui" lorsqu'on le prévient qu'il y a un danger. Comprend-il le danger pour autant ? Non.
NOUS ALLONS ENFIN POUVOIR AVOIR UNE CONNEXION CHIFFRÉ SUR DVP
T'en es sûr
sleon une édtue de l’Uvinertisé de Cmabrigde, l’odrre des ltteers dnas un mot n’a pas d’ipmrotncae, la suele coshe ipmrotnate est que la pmeirère et la drenèire lteetrs sinoet à la bnnoe pclae. Le rsete peut êrte dnas un dsérorde ttoal et vuos puoevz tujoruos lrie snas porblmèe. C’est prace que le creaveu hmauin ne lit pas chuaqe ltetre elle-mmêe, mias le mot cmome un tuot.
CQFD
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