Cher journal,
Toi aussi tu trouves que la gestion des certificats, c'est compliqué (enfin, moi je ne trouve pas mais il parait que c'est le cas), tu trouves que les certificats, c'est trop cher, tu ne savais pas quoi répondre au sondage sur le prochain certificat de linuxfr.org. Alors réjouis-toi, l'EFF et Mozilla ont trouvé que les associations australiennes n'étaient pas terribles, et ont fondé leur propre association qui veut être une autorité de certification reconnue et qui va (…)
Après quatre ans et trois mois, et pas moins de 26 versions de développement, la version réputée stable de HAProxy devient la 1.5. Même si HAProxy est avant tout un répartiteur de charge HTTP et TCP, les possibilités offertes par la version 1.5 en font le véritable couteau suisse du Web à haute charge.
Il est utilisé, entre autres, par de nombreux sites d’audience mondiale, tels que Twitter, Instagram, GitHub, Reddit… Cette version apporte de nombreuses nouveautés, dont la très attendue prise en charge de l’offloading SSL.
La version 1.5.0 a été rapidement suivie de quelques versions correctives. Nous en sommes à la 1.5.3, disponible depuis le 25 juillet dernier.
POODLE signifie Padding Oracle On Downgraded Legacy. Il s’agit d’une vulnérabilité permettant via une attaque de l’« homme du milieu » (MIM, Man In the Middle), en se plaçant entre le navigateur Web et le serveur Web, de déchiffrer les informations chiffrées.
POODLE affecte les anciennes normes de chiffrement, notamment Secure Socket Layer (SSL) version 3.0. Il n’affecte pas le mécanisme de chiffrement plus récent, et standardisé, appelé Transport Layer Security (TLS).
Pour atténuer cette vulnérabilité, désactivez SSL 3.0 en forçant l’utilisation de TLS, tout en vérifiant la compatibilité des navigateurs clients devant y avoir accès.
Bonjour,
j'ai besoin d'ajouter des certificats de sécurités pour une poignée de sites sur mes serveurs.
Certains certificats permettent d'authentifier tous les sous-domaines d'un nom de domaine.
D'autres semblent ne pas prendre en compte les sous-domaines.
J'ai des nom de domaines différents, et aussi des sous-domaines différents.
Est ce qu'avec une seule IP je pourrait m'en sortir? Dois-je aussi lourer des Ip supplémentaires?
Et en IPv6?
Merci
G
En testant linuxfr.org sur https://www.ssllabs.com, j'obtiens un résultat assez inquiétant. Rapidement ça dit que le site est exposé à la faille CVE-2014-0224. Du coup, le https ne sert pas à grand chose sur linuxfr.org.
Je ne suis pas très familier avec ces histoires mais j'imagine qu'il faudrait corriger la situation au plus vite.
Salut les jeunes,
Vous n'êtes pas sans savoir qu'OpenSSL, la librairie plus ou moins standard implémentant les protocoles SSL/TLS, a récemment fait beaucoup parler d'elle pour un bug extrêmement grave. La librairie n'en était pas à son premier coup, elle a déjà fait parler d'elle à plusieurs reprises par le passé par sa piètre qualité (j'ai pas vu moi-même, je ne fais que rapporter ce que j'entends sur la toile).
Une vulnérabilité dans l’implémentation de l’extension heartbeat (RFC 6520) d’OpenSSL a été découverte conjointement par une équipe de chercheurs en sécurité (Riku, Antti and Matti) à Codenomicon et Neel Mehta de Google Securité. On retrouve ici un vieux bogue des familles : le read overrun.
OpenSSL 1.0.1, jusqu’à 1.0.1f inclus, et OpenSSL 1.0.2-beta1 sont affectés. Ce sont les versions utilisées dans la plupart des distributions.
Cette dernière permet la lecture de 64 Kio dans la mémoire des clients et serveurs affectés (mais l’attaque peut être rejouée à chaque heartbeat), autorisant la lecture de données comme les clés privées et, bien sûr, les données échangées une fois ces dernières retrouvées (et ce, même en mode hors ligne s’il n’y avait pas de forward secrecy utilisé).
Il est difficile, voire impossible, de faire une détection post‐mortem d’infiltration, l’attaque ne laissant pas d’entrée suspecte dans le journal système.
Passer à OpenSSL 1.0.1g, redémarrer tous les services utilisant libssl et remplacer l’intégralité de ses certificats (la clef privée étant vulnérable) est donc nécessaire.
Bonjour à tous,
Depuis le scandale de la National Security Agency en juin 2013 et les révélations sur le programme PRISM, la cryptographie a connu une explosion d'intérêt dans le monde entier. Les médias de masse s'en sont emparés, tout le monde s'est mis à en parler, et comme à chaque fois que l'on donne un sujet technique à Mme. Michu, d'énormes absurdités en sont ressorties, et on a enregistré un pic de popularité du mot "cryptocalypse".
J’espère ici (…)
Depuis quelques temps j'ai eu pas mal de lecture sur le fonctionnement de SSL et notamment des articles sur les conséquences de l'utilisation de certains algorithmes de chiffrement (cipher) et sur les défauts de certains. Comme je pense que ça pourrait intéresser quelques personnes dans le coin, je vous fais donc part de tout ceci.
Tout d'abord, en entrée, je vous propose un article du Monde qui parle de travaux pour imposer un contournement possible des algorithmes SSL aux éditeurs (…)
Bonjour à tous,
Je souhaiterais générer un certificat ssl pour l'ensemble de mes sous-domaines, actuel et surtout futur.
J'ai lu qu'il était déconseillé de générer un certificat (cacert.org) pour le CN *.domain.tld
Ma question est donc, comment dois-je m'y prendre pour permettre de certifier tous mes (prochains) sous-domaine ?
Bonjour à tous.
Je suis nouveau sur le forum et novice en Linux également. Je suis actuellement en formation professionnelle "réseau, exploitations, etc…" (je passe sur le titre il importe peu ici).
Bref j'ai découvert Linux au début de ma formation il y a 6 mois, je suis actuellement en stage (pour deux mois).
Je vais essayer de ne pas vous noyer dans une logorrhée inutile. Et m'en tenir à l'essentiel.
Je dois monter un Open Ldap (avec SSL) dans (…)
Les serveurs utilisent des certificats TLS (ex SSL) pour permettre des échanges chiffrés avec les navigateurs (éviter les écoutes, les modifications, protéger la vie privée, sécuriser des échanges financiers, permettre de vérifier que le serveur est le bon, etc.). Et donc soit on auto-certifie son propre certificat, soit on passe par une autorité de certification (ou une chaîne d'autorités).
Côté client, les autorités acceptées sont gérées soit par le navigateur (Firefox, Chrome, Opéra, un navigateur basé sur java…) et c'est alors spécifique au navigateur , soit le navigateur délègue ça au système (rekonq, konqueror, iceweasel…) et c'est alors spécifique au système.
LinuxFr.org utilise un même certificat sur les différents domaines gérés, dont les serveurs de production et de test, le serveur cache des images, ainsi que le gestionnaire de listes de diffusion. Ce certificat doit être mis à jour sous peu (le 7 juin). Et comme à chaque mise à jour, les mêmes questions vont revenir, c'est donc l'occasion de faire le point sur le sujet (dans la seconde partie de la dépêche).
Bonjour Nal,
Récemment un ami m'a demandé de l'aide, car son client mail affichait un message d'erreur inquiétant:
Vérification du certificat SSL pour imap.free.fr :
(…)
Signature : MAUVAIS
N'étant pas sur place, je lui ai demandé de faire appel au support de Free, leur réponse est assez étrange:
Nous vous informons qu'il n'est pas utilisé d'authentification SSL par défaut avec un logiciel de messagerie pour un compte mail FREE.
Si votre ordinateur dispose des outils de protection importants tels (…)
The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software par Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh et Vitaly Shmatikov
Une excellente étude sur les vulnérabilités des applications utilisant TLS (autrefois nommé SSL), à l’exclusion des navigateurs Web. Des tas d’applications parfois peu connues et discrètes (par exemple pour réaliser la mise à jour des logiciels d’un système) utilisent, comme les navigateurs Web, TLS pour se protéger contre un méchant qui essaierait (…)
Les First Jeudi sont une réunion bi-mensuelle, organisée par l'association Parinux dans le cadre convivial d'un restaurant ou d'un bar, pour discuter des problématiques du libre et passer un bon moment ensemble. La prochaine réunion se tiendra le Jeudi 6 Décembre 2012 de 19h30 à 23h00 au Père Tranquille.
À cette occasion, des accréditeurs CAcert.org seront présents pour échanger et vous offrir une certification croisée. CAcert diffuse des certificats X.509 gratuits et organise un cercle de confiance entre utilisateurs (WoT Web Of Trust). Les certificats X.509 permettent de signer des emails, de se connecter à des VPN et de mettre en place des sites Web sécurisés par HTTPS. Environ 253.000 utilisateurs ont rejoint CAcert.org.
Si vous souhaitez vous faire certifier à l'occasion des First Jeudi :
L'adresse du Bon père tranquille:
Père Tranquille
16 rue Pierre Lescot
Paris 75001
France
48° 51' 43.4736" N, 2° 20' 53.9196" E