On parle beaucoup de self-hosting par ici et une question me turlupine à laquelle je n'ai jamais vu de réponse : comment sécuriser l'accès aux applications auto-hébergés ?
Si je passe par du HTTP "en clair", n'importe-quel hébergeur d'applications cloud sera mille fois plus sécurisé.
Si j'installe un certificat "maison", j'aurai des tas d'alertes dans tous les navigateurs et très peu de moyens de vérifier que c'est le bon certificat serveur qui me répond.
Est-ce que ça veut dire que pour s'auto-héberger il faut obligatoirement se payer un "vrai" certificat HTTPS (c'est à dire pas un machin CACERT reconnu nulle-part) ? Combien ça coûte ?
Combien ça coûte de faire installer ce genre de certif chez un hébergeur (genre Gandi/OVH/Online/…) ?
# StartSSL
Posté par Seb . Évalué à 8. Dernière modification le 06 novembre 2013 à 10:51.
hello,
en ce qui me concerne j'ai pris mon certificat chez startSSL : https://www.startssl.com/
c'est pas un très haut niveau de certification, mais c'est gratuit et ça me suffit largement, et c'est reconnu par tous mes navigateurs.
Gandi propose des certificats pour 12€/an
pour l'installer, à toi de jouer avec les services que tu veux sécuriser. (je l'ai installé sur apache, et dovecot / postfix.)
Seb
[^] # Re: StartSSL
Posté par Elwood_Blues . Évalué à 1.
Pareil, j'utilise startSSL. Le problème c'est juste qu'il faut le refaire chaque année. Sinon c'est parfait !
[^] # Re: StartSSL
Posté par Thom (site web personnel) . Évalué à 1.
le certificat est délivré par gandi pour mon site.
C'est un poil long, mais rien d'insurmontable.
Après, je n'ai eu aucun mal à le faire passer sous nginx.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
# c'est quand meme le tien
Posté par NeoX . Évalué à 4.
dans le certificat il y a une "empreinte"
si cette empreinte change, c'est que tu n'es pas sur le bon serveur.
mieux, si tu es auto-herbergé, tu te connectes à ton serveur la premiere fois, en local de chez toi,
donc il y a toi et le reseau local.
tu recuperes le certificat, tu valides l'exception sur l'autosignature.
quand tu te connecteras de l'exterieur, le certificat est le meme, ta machine le reconnait.
s'il change et que tu sais pertinemment n'avoir rien fait, alors c'est que ta machine est compromise, ou que quelqu'un se fait passer pour toi.
[^] # Re: c'est quand meme le tien
Posté par Adrien . Évalué à 0.
Stop aux arguments foireux : tu peux vouloir te connecter depuis… plusieurs machines : boulot, smartphone, copains, etc. Et pire, un inconnu qui vient sur ton site perso n'aura aucun moyen de vérifier que c'est le bon.
Donc non, le certificat auto-signé n'est pas la bonne solution, c'est une plaie qu'il faut éviter.
[^] # Re: c'est quand meme le tien
Posté par NeoX . Évalué à 3.
pourtant SSH fonctionne avec des clef auto-generées/signées.
et de la meme maniere, lors de la premiere connexion on te demande si tu veux faire confiance à ce serveur.
et cela marche tres bien,
tu peux exporter l'empreinte, la communiquer à qui tu veux…
[^] # Re: c'est quand meme le tien
Posté par Adrien . Évalué à 2.
Le problème n'est pas tout à fait le même : une connexion ssh se fait en général sur une machine « de confiance » (un serveur qu'on connait, etc.), tandis qu'un site web est bien souvent pas de confiance.
Ensuite ce n'est pas parce que le voisin fait les choses pas forcément nickel qu'il faut faire pareil.
Enfin question simple : comment vérifier la validité d'un certificat auto-signé sur internet simplement ? Ben il me faut contacter le propriétaire, avec un moyen sécurisé (hors email donc), pas simple…
Du coup quel est l'avantage du certificat auto-signé par rapport à un certificat valide gratuit ?? Perso je n'en vois aucun, au contraire : on habitue les gens à négliger les erreurs SSL, ce qui est dévastateur.
On peut être d'accord ou pas avec le modèle de sécurité SSL, mais avoir des certificats valide améliore quand même la sécurité du web.
[^] # Re: c'est quand meme le tien
Posté par delio . Évalué à 1. Dernière modification le 06 novembre 2013 à 15:06.
Un certificat auto-signé, c'est comme une clef ssh. Il faut la vérifier lors de la première connexion, ou juste accepter un petit risque. La clef est enregistrée sur le poste client.
Ensuite, à chaque connexion, le client vérifie que la clef n'a pas changé et on est certain d'être prévenu si la clef change: ssh refuse la connexion. C'est ce qui est le plus important: savoir que dans la durée on parle toujours au même serveur.
Au contraire, le comportement des navigateur internet (firefox en tête) avec les certificats ssl n'est pas sain du tout:
- ils font confiance à la place de l'utilisateur en tout un tas d'autorités de certifications, dont certaines filent des certificats comme des petits pains
- ils ne levent pas (par defaut) d'alerte quand un certificat (pas auto-signé) change!! Tout certificat signé par une autorité de confiance est réputé valide. Pratique pour un homme du milieu!.
Avec un certificat auto-signé, si on a recupéré et enregistré le bon certificat à la première connexion, il est impossible d'être victime de l'homme du milieu.
[^] # Re: c'est quand meme le tien
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
Euh, si, si le MITM pousse un certificat d'une AC reconnue tu as le même soucis
[^] # Re: c'est quand meme le tien
Posté par Adrien . Évalué à 3.
D'où la dernière phrase de mon commentaire. Le modèle est très loin d'être parfait, n'empêche qu'actuellement à mon avis il vaut très probablement mieux ce mauvais système qui marche (c'est à dire avec des certificats validés par des autorités de certification contestées) que de foirer le système avec des certificats non valides et habituer les utilisateurs à « clicker sur OK tout le temps ».
[^] # Re: c'est quand meme le tien
Posté par Adrien . Évalué à 2.
Je re-répond sur le petit risque : en fait dans une navigation normale, c'est un risque majeure : tu va sur un site qui utilise un certificat auto-signé, hop tu valides… et le certificat ne sert plus à grand chose. Le risque n'est pas petit puisque la plupart des gens ne comprendront pas les implications derrières le message de firefox.
[^] # Re: c'est quand meme le tien
Posté par Ellendhel (site web personnel) . Évalué à 4.
Non, mais il y a des gens qui travaillent dessus pour permettre la vérification de certificats via des enregistrements DNS : DNS-based Authentication of Named Entities (DANE). Ce n'est pas encore officialisé, et cela requiert DNSSEC pour être vraiment utile. Il faudra être patient. Et pour le coup, si cela est déployé de manière large et supporté par différents clients, cela pourra inverser la balance entre "certificat auto-signé" versus "certificat officiel" (je reste optimiste, je me doute que les autorités de certification actuelles voient cela d'un mauvais œil…).
Et il existe à peu près le même principe avec les enregistrements SSHFP (SSH Fingerprint) expliqué sommairement ici et là.
[^] # Re: c'est quand meme le tien
Posté par Zylabon . Évalué à 5.
Une plaie qu'il faut éviter ce sont les gens qui font confiance aveuglément à leur machine sans rien biter à ce qu'elles font. Et assertions idiotes à l'emporte pièce.
Un certificats auto-signé offre une sécurité SUPÉRIEURE à celle d'un certificat signé par un tiers dans le cas d'un service mis en place pour soit-même et quelques potes, pour les raisons que d'autres ont évoqué avant moi (les autorités de certifications qui font de la merde, ou obéissent pourquoi pas simplement à une décision de justice).
Ensuite, il n'y a pas nécessairement besoin que le serveur soit authentifié pour qu'une connexion sécurisée offre un intérêt. Rien que le fait de compliquer le travail de celui qui voudrait faire de la surveillance massive à l'échelle d'une population vaut le coup à mon sens. Ça vaut aussi quand je me connecte à un wifi ouvert, etc.
Please do not feed the trolls
[^] # Re: c'est quand meme le tien
Posté par Adrien . Évalué à 0.
je vois pas vraiment pourquoi c'est si supérieure : Si tu ne fais pas confiance aux autorités de certification, tu peux toujours les virer dans ton système non ? Et donc du coup, tu vérifieras les certificats au coup par coup.
Par contre dans le cas d'un certificat auto-signé, tu forces ceux qui font confiance aux autorités de certification (c'est à dire l'immense majorité des internautes) à accepter des exceptions, qui en pratiques ne sont pas vraiment validées de façon satisfaisantes, ce qui laisse une porte bien ouverte aux espions.
S'il y a un biais dans mon raisonnement, je serais heureux de savoir où il se trouve.
[^] # Re: c'est quand meme le tien
Posté par Zylabon . Évalué à 3. Dernière modification le 07 novembre 2013 à 12:14.
Là :
;-)
(dans ce cas on peut communiquer le certificat directement, ou son empreinte par un moyen super sûr : IRL)
Please do not feed the trolls
[^] # Re: c'est quand meme le tien
Posté par Adrien . Évalué à 2.
Effectivement, la nuance est subtile :-) Du coup effectivement, le moyen de vérification (et de prévention auprès des utilisateurs) est assez simple.
Dans ma tête auto-hébergement ne voulait pas du tout dire « pour soi ou son entourage », mais bien un truc accessible par beaucoup de gens : un dépot mercurial, un blog, des photos libres, etc.
[^] # Re: c'est quand meme le tien
Posté par dinomasque . Évalué à 4.
Si c'est pour rester sur la même machine, c'est même plus la peine d'installer un serveur ;)
BeOS le faisait il y a 20 ans !
[^] # Re: c'est quand meme le tien
Posté par NeoX . Évalué à 2.
tu peux avoir un serveur chez toi (autohebergé)
et avoir la machine client chez toi aussi (portable, tablette, telephone)
# Re:
Posté par Tonton Benoit . Évalué à 3.
Auto-hébergé ou pas, à partir du moment ou tu a ton nom de domaine personnel (qui coûte lui-aussi quelque € par an, au passage) il te faut un certificat si tu veux faire du ssl.
T'a bien fait le tour de la question, auto-signé, communautaire (CACERT), ou commercial.
Après si un certificat monodomaine, coûte quasi queud (voir gratos chez starssl) aujourd'hui c'est loin d'être le cas d'un multi-domaines ou d'un wildcard, hors le XMPP est gourmand de ce genre de certificat (et c'est un reproche que je fait à ce protocole)
# DANE
Posté par tetraf . Évalué à 5.
Il y a une alternative qui n'est pas encore très implémentée mais plutôt prometteuse : DNS-based Authentication of Named Entities.
Si tu es intéressé par SSL/TLS, il y a une conférence sympa de Benjamin Sonntag, ici : http://data.confs.fr/ssl-tls-sonntag/.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.