Au boulot on a un extranet accessible de l’exterieur pour avoir accès au mail ( “web mail exchange” je sais pas si ça se dit)
Pour y accéder on passe par une page en https … ou le navigateur nous informe que le certificat de sécurité n’est pas valide.
C’est normal ca fait partit de la procédure , on accepte quand même et on peut consulter nos mails.
Mais ce certif non valable ca m’intrigue …
C’est quoi les conséquences possible ( théoriques et réelles )?
Ca vous choques ou c’est souvent comme ça ?
c’est quoi l’interet du https sur le http sur le coup ?
Il n’y a pas d’intérêt à faire du https si le certificat n’est pas valide tu n’as aucune garantie que ton interlocuteur est bien celui qu’il prétend être.
[quote]Les certificats auto-signés sont des certificats à usage interne. Signés par un serveur local, ce type de certificat permet de garantir la confidentialité des échanges au sein d’une organisation, par exemple pour le besoin d’un intranet. Il est ainsi possible d’effectuer une authentification des utilisateurs grâce à des certificats auto-signés.
Les certificats signés par un organisme de certification sont nécessaires lorsqu’il s’agit d’assurer la sécurité des échanges avec des utilisateurs anonymes, par exemple dans le cas d’un site web sécurisé accessible au grand public. Le certificateur tiers permet d’assurer à l’utilisateur que le certificat appartient bien à l’organisation à laquelle il est déclaré appartenir.[/quote]
La différence (en bref) … le prix
(Sinon, d’un côté, c’est le site lui-meme qui dit « je suis bien celui que tu crois que je suis » et de l’autre, c’est une autorité reconnu qui dit "le site là, il est bien celui qu’il dit être, en gros)
[quote=“Lukkant, post:1, topic: 50697”]Alors j’explique ma question :
Au boulot on a un extranet accessible de l’exterieur pour avoir accès au mail ( “web mail exchange” je sais pas si ça se dit)
Pour y accéder on passe par une page en https … ou le navigateur nous informe que le certificat de sécurité n’est pas valide.
C’est normal ca fait partit de la procédure , on accepte quand même et on peut consulter nos mails.
Mais ce certif non valable ca m’intrigue …
C’est quoi les conséquences possible ( théoriques et réelles )?
Ca vous choques ou c’est souvent comme ça ?
c’est quoi l’interet du https sur le http sur le coup ?[/quote]
Probablement que le certificat a été généré par la boite, mais pas certifié par une autorité de certification (ce qui coute un peu de sous). C’est souvent comme ça. Ensuite, ça change rien au fait que les échanges sont chiffrés.
Le certificat n’est pas reconnu par ton navigateur parcequ’il n’est pas signé par une authorité de certification, donc il te le signale. �?a ne change rien au procédé crypto qu’il y a derrière, il y a juste que potentiellement en cas de piratage (par exemple de ta connec, où tu crois te connecter sur ton serveur de ton taf), tu es sensible à une attaque de type Man In The Middle.
En gros, je te redirige vers ma machine, tu crois que c’est ton taf, je te balance un certif bidon, que tu acceptes, tu me file ton mot de passe, que du coup j’ai en clair, et moi je me connecte à ton taf avec ton mot de passe, et te transmets les infos comme un proxy, sauf que dans l’affaire, j’ai chopé ton mot de passe.
Si tu es “sûr” que tu as le bon certificat tu peux l’accepter définitivement, et si celui-ci change (exemple du pirate) ton nav va te ressortir le warning. (à confirmer).
Pour en être sûr : tu peux demander un fichier de signature du certificat aux sysadmins (par un vecteur sécurisé :D) pour le comparer avec celui que te file ton navigateur, pour être “sûr” que c’est le bon qui t’es proposé.
Pour revenir au coût, oui et non. Avant il fallait payer un peu cher pour avoir un certificat “all browser compliant”. Maintenant, gandi et ovh (et d’autres je suppose) proposent à bas prix un certificat SSL qui passe 99% des navigateurs (d’après ce que dit) gandi.
Edit rapide pour le “ça vous choque ou c’est souvent comme ça”: en fait, depuis firefox3 (et ses potes chrome et ie ont emboités le pas) il te met une grosse page “ATTENTION CE CERTIFICAT IL PUE!!!” pour éviter le fishing en masse dont étaient victimes … les victimes. �?a se désactive d’ailleurs, voir about:config.
En cas si ils sont libres de choisir, tu peux leur toucher deux mots à propos de StartCom Free SSL Certification Authority, je sais pas ce que ca vaut mais à en croire ce qui est dit ca a l’air ma fois très sympa … et gratuit
C’est un peu rapide …
L’interet premier du https, c’est de crypter le flux de donnée http qui passe sur le net entre le site et le navigateur.
Le certification officiel de ton certificat ne sert qu’a enregistrer ton site parmis une liste de site « officiel ». Cette certification compte bonbon.
Donc tu t’en cogne du « le certificat n’est pas valide ». Il te dis juste que ton site est pas dans la base des sites payants.
Mais tu beneficies de tout l’encryptage malgres tout.
Donc si, il y a un interet certain a utiliser le https …
Oui. C’est pour ca que si tu es susceptible d’etre la cible d’un MITM, tu fais certifier ton certificats
Sauf que pour 99% des sites « internes », c’est inutile. Le https, c’est juste pour eviter que n’importe quel blaireau avec un sniffeur recupere les logins / mdp de l’intranet de ta boite.
C’est un pas suffisant pour securiser ton site, sans surcout, juste avec de la conf.
Et tu evites 99,99% des pb.
Entre lancer ethereal pour recuperer un mdp, et dupliquer un site pour faire croire que c’est le site original, c’est pas le meme investissement, ni le meme niveau de connaissance qui est demandé.
C’est pour ca que je dis « c’est un peu rapide ». Mais dans l’absolue, vous avez raison, seul le https avec un certificat approuvé te couvre à 100%. En pratique, le https seul suffi pour les sites sans grosses visibilités et pas trop sensible.
[quote=“Lukkant, post:1, topic: 50697”]C’est quoi les conséquences possible ( théoriques et réelles )?
Ca vous choques ou c’est souvent comme ça ?
c’est quoi l’interet du https sur le http sur le coup ?[/quote]
Salut
J’ai vu ton post hier soir, mais étant occupé avec un certain IBM (hihi) je n’ai pas pris le temps de répondre, ce qui est mal.
Imaginons que ton serveur Exchange s’appelle EXCH et que le site internet pour accéder s’appelle webmail.danone.fr.
Si le navigateur pleure parce que le certificat de sécurité n’est pas valide cela peut être pour plusieurs raisons :
Cas d’un certificat “auto-signé” (en gros c’est le serveur Exchange “EXCH” qui dit “oui oui,je certifie que “webmail.danone.fr” c’est bien moi”)
[indent]a. Cas de l’adresse du webmail qui est pas/mal certifiée
Généralement, la boulette faîte par le ou les administrateur(s) Exchange c’est de générer un certificat qui identifie LE serveur Exchange EXCH et pas le serveur EXCH et l’adresse webmail.danone.fr.
Du coup, quand tu entres l’adresse webmail.danone.fr, ton navigateur compare le certificat qui y est associé, et celui-ci certifie que “EXCH” c’est bien lui mais ne certifie pas l’adresse du webmail.
Dans ce cas tu te prends le message qui te dit : “tu es sur que tu veux y aller ?”.
b. Cas du certificat autosigné non reconnu par le navigateur
C’est assez simple. Si EXCH s’est “autosigné” un certificat, cela veut dire que EXCH admet avoir l’autorité de dire : “OUI ! Moi je suis bien EXCH”.
Mais ceci n’engage que lui :D).
C’est pour cela que les administrateurs Exchange doivent “déclarer dans ton navigateur” que le serveur “EXCH” est “un bon gars a qui l’on peut faire confiance” en exportant le certificat racine du serveur EXCH dans ton PC. Si ils ne font pas cela, ton PC ne fera jamais confiance au serveur “EXCH”, ce qui est bien normal, sinon ce serait trop facile de contourner un système HTTPS.
[/indent]2. Cas d’un certificat public
[indent]Une autorité de certification publique est une société qui est reconnue par plein d’autres (Microsoft, les pingouins, etc…) comme étant quelqu’un de fiable.
Par défaut, Microsoft en connait une floppée (VeriSign, CA, …).
Quand un administrateur Exchange ne veut pas se prendre la tête et a un peu de sous de coté, il “achète” une certification de son serveur EXCH et de son adresse webmail.danone.fr auprès de cette autorité de certification.
Ainsi, comme chaque navigateur a déjà confiance en l’autorité de certification publique, le navigateur accepte l’adresse sans broncher.
Il est fort possible qu’en achetant le certificat, l’administrateur ait fait une boulette en déclarant les adresses et noms des serveurs a certifier. Comme c’est chiant et mal documenté, ben, cela peut arriver souvent.
[/indent]
Je rajoute mon grain de sel : il est également possible (ça m’est déjà arrivé) que le certificat ne soit pas auto signé, mais qu’il soit mal adapté ou mal renseigné, ou encore que la date de validité soit dépassée.
Par exemple si tu te connectes à une adresse du genre “mail.maboite.fr” et que le certificat est renseigné avec le CN “maboite.fr” ben ton navigateur doit en principe t’alerter sur la possibilité d’un risque de sécurité.
C’est sûr que ça fait pas hyper sérieux, mais la sécurisation des données n’est pas remise en question, c’est plutôt le niveau de confiance avec le serveur d’en face qui diminue.
A mon tour de rajouter mon opinion: La politique actuelle des navigateurs concernant les certificats non signés est un truc d’une stupidité sans nom.
Pour faire simple, à la base on a le protocole https qui permet d’avoir des échanges de données cryptées entre un navigateur et un serveur web. �?a, c’est bien, et c’est suffisant pour 99% (statistique made in moi) des utilisations.
A côté de ça, https permet également l’utilisation de certificats, un système permettant de confier à un tiers de confiance (l’autorité qui a délivré le certificat) de certifier que le serveur web est bien le serveur web avec qui on veut communiquer. A la base ça part d’une bonne intention, en pratique ça a surtout foutu plus de merde qu’autre chose.
Le problème principal, c’est lorsqu’on veut utiliser https pour le cryptage des données parce que c’est toujours une bonne idée de pas laisser se balader des mots de passe en clair dans la nature, mais qu’on se fout du certificat parce que les risques liés à une attaque de type MITM ne justifient pas le cout / les procédures liées à l’achat d’un certificat (parce que les données ne sont pas secret-défense-nucléaire, qu’on est déjà sur un réseau interne relativement sécurisé, ou tout autre raison qui fait que le niveau de paranoia n’est pas assez élevé. Peut-etre que c’est pas la peine de mettre des murs de 5m avec barbelés et miradors autour de son jardin pour éviter de se faire voler son tuyau d’arrosage et son barbecue).
Dans ces cas là, on fait un certificat auto-signé: on a un niveau de sécurité moins élevé qu’avec un certificat signé, mais déjà largement plus qu’avec du bête http de base.
Le problème, c’est que les navigateurs n’aiment pas les certificats auto-signés. Ils mettent une grosse fenetre d’alerte, avec une icone rouge et du texte avec des points d’exclamation, et ça fait peur aux utilisateurs. Alors les utilisateurs ils vont pas sur le site.
Alors le propriétaire du site, comme il en a marre de faire chier ses utilisateurs et que se payer un certificat ne se justifie toujours pas, il passe le site en http. Les utilisateurs n’ont plus le message d’alerte “attention ce site va venir chez vous tuer vos femmes et violer vos chiens”, donc ils ont confiance et reviennent sur le site. Qui est moins sécurisé que quand il leur faisait peur.
Parallèlement à ça, il y a les méchants, ceux dont à la base on veut se protéger en mettant du https. Ils se divisent en deux catégories:
Ceux qui sniffent les communications pour chopper des mots de passe. eux n’ont rien a foutre qu’un certificat soit valide ou signé ou pas. Si on est en https, les infos sont cryptées il ne peuvent pas faire grand chose.
Ceux qui font du phishing: ils font une copie de la page de login du site et essaient d’envoyer les gens dessus pour qu’ils croient etre sur le site et mettent leurs mot de passe.
Eux, la présence d’un certificat signé ne change rien à leur mode opératoire: ils se basent sur la stupidité des utilisateurs qui vont se rendre sur leur faux site à partir d’un lien envoyé par e-mail ou un autre moyen. Si un utilisateur se fait avoir par ce moyen, c’est déjà qu’il est pas très secure-aware, donc il ne va jamais aller vérifier s’il est en https ou pas à la base. Donc le malfaisant met son site en http sans cryptage ni rien, l’utilisateur piégé rentre son mot de passe sans se soucier d’histoire de certificats et se fait voler ses infos.
Bref, les messages d’alertes utilisés par les navigateurs pour avertir les utilisateurs de la présence d’un certificat non signé rendent globalement le web moins sécurisé. Et ça, c’est le mal.
Heu sans vouloir etre mechant c’est ce genre d’explication qu’est “d’une stupidité sans nom”. Je me mets dans n’importe quel web cafe et je chope tous vos mots de passe de compte en banque en dix minutes pour n’importe qui qui se logue si les certif “ca sert qu’a la crypto et on s’en fout pour n’importe quelle autre application”. C’est d’ailleurs toujours faisable si les gens ont pas l’intuition de verifier que ils voient bien la page de login en HTTPS…
Pourvoir faire confiance qu’on se connecte bien a l’endpoint qu’il faut est absoluement primordial a tout le systeme de securite et la crypto ne vaut absoluement rien sans. C’est bien gentil de pas pouvoir lire ce qui passe sur le fil, mais si tu peux faire croire au mec au bout du fil qu’il a qu’a crypter les trucs avec ta clef a toi et tu fais juste suivre, autant envoyer les trucs en clair, ca revient absoluement au meme… Tu oublies completement toute une categorie d’attaque, super faciles a mettre en place par n’importe quel script kiddie qui fout en l’air tout ton argument. Je fais une demonstration laptop en main quand tu veux: repondre a une requete ARP plus vite qu’un petit routeur wireless avec un PC moderne, c’est tellement facile que ca en est pas drole…
Pour ce qui est de ressources internes à une entreprise ou à public limité ou défini :
Les admins n’ont qu’a PUBLIER LEUR CERTIFICATS au lieu de faire n’importe quoi !
Monter une PKI avec openSSL (ou autre authorités de certifs MS ou autre), il n’y a rien de plus simple. (Le plus compliqué est plutôt de faire respecter les pratiques de délivrance de certificats en interne), et ca coute rien.
Ensuite, il suffit de distribuer le certificat racine sur les machines des utilisateurs …
Une fois le certificat racine installé sur les machines utilisateur, tous les servers (imaps, smtps, https, …) dont le certificat aura été généré par la PKI seront immédiatement acceptés.
La distribution peux se faire automatiquement (via Active directory ou autres scripts) pour les machines internes et/ou managées par le SI, ou manuellement (sur les machines persos des utilisateurs) en donnant les instructions détaillées.
Dans un contexte aux nombre d’utilisateurs limités, rien empeche l’utilisation de certificats, sans avoir des avertissements constamment.
Le seul soucis est que RIEN n’est fait pour encourager les administrateurs pour monter des PKI. (Solutions payante et usine a gaz coté MS, pas de GUI de ce nom coté libre).
Une authorité de certif openssl, ca tiens sur une clé USB (faut juste pas se la faire voler).
Ce qui n’est absolument pas mon propos, lequel était que différents niveaux de sécurité sont nécessaires pour différentes applications, et que si d’un côté je ne conçois pas qu’une banque ne fasse pas du https avec un certificat valide (et pour toutes les pages servies une fois connecté, pas seulement pour la connexion en elle-même comme on le voit trop souvent y compris sur des sites à contenu confidentiel), de l’autre je pense qu’il est légitime que tout un chacun puisse mettre en place un système de cryptage cryptage pour la connexion à son blog, au forum de son clan duck hunt, ou à son site de photos de papier tue-mouche sans pour autant avoir besoin de se payer un certificat qu’il lui faudra renouveller tous les ans.
Problème que j’ai souligné dans ce que je disais, et qui est à la base de mon propos: un utilisateur lambda a plus confiance en une page en http qu’en une page https avec un certificat auto-signé. Et ça, c’est stupide.
C’est valable partout : http://sial.org/howto/openssl/ca/
C’est écrit « small CA », mais c’est valable aussi pour un gros (l’es juste conseillé de rajouter une interface plus pratique la dessus si on veux générer et gérer plusieurs dizaines de certifs).
Je l’utilise pour une vingtaine de certificats, autant pour les différents services de mon dédié et mon home-nas (http, imap, smtp), que pour mon authentification WIFI (WPA2-EAP-TLS).
Pour la distribution automatique, aucune idée sous linux, mais ca peux se faire manuellement.
J’avais idée de créer un GUI .net, mais j’ai abandonné faute de temps. Y’a tout ce qu’il faut dans mono. Sinon, il en existe quelques unes en GTK ou java, mais rien que j’ai trouvé pratique.
Merci à tous pour ces réponses qui 'mont permis de mieux comprendre ce qu’était le https
Si je résume ce que j’ai compris c’est pas terrible de pas avoir de certif , mais se serait pire en http
