ce document présente dans quel ordre il faut présenter les certificats dans un pem de certificats intermédiaires par exemple.

Revoquer un certificat permet normalement de s'assurer que personne va pouvoir continuer à l'utiliser à votre place et usurper ainsi votre identité.
C'est particulièrement important par rapport à la faille heartbleed qui a potentiellement permis la récupération des clés privées pour deux serveurs sur trois.
Sauf que par défaut les navigateurs (en tout cas Chrome/Firefox) ne vérifient pas les listes de révocation. Ooops.
Vivement qu'on passe à autre chose.. genre DANE (DNSSEC)

Startssl ne permet pas de régénérer de nouveaux certificats gratuitement par rapport à la faille Heartbleed.
Pour cela, il faut payer... contrairement à chez gandi, par exemple.

bastards!

bon celà dit je ne paye RIEN aujourd'hui et j'imagine que mettre en place un système de renouvellement (révocation+recréation) a un coût non négligeable pour cette entreprise... mais pour ceux qui payent, c'est moyen de ne faire aucun geste.

oui mais pour info:
"If your certificate authority is CACert.org then there is an extra surprise in store for you. CACert.org has changed their hash to SHA-512 recently and some client/server connections silently fail to authenticate with this hash."
http://danielpocock.com/double-whammy-for-cacert.org-users

"private information accessible to anyone [...] change your passwords everywhere"
sauve qui peut!! cela montre bien que c'est du sérieux et qu'au delà de patcher, il faut révoker et recréer de nouveaux certifs SSL sans trop tarder.

""""
L'ANSSI sait pertinemment d'où sort l'info de google.
C'est certaines versions de Chrome qui fayotent (valablement) à Google en cas de certificat signé par la mauvaise autorité, on appelle cela du "certificate pinning"
""""

via commentaire de BenjaminSonntag sur http://m.pcinpact.com/news/84830-blocage-certificats-par-google-interview-patrick-pailloux-anssi.htm

@Pogo: en fait, la grande majorité des shaarlis n'ont pas de certificat du tout, et ils sont sur un hébergement ovh dont le certificat par défaut est pour sslX.ovh.net.

On retrouve principalement 2 types d'erreurs:

• Le certificat a été créé pour un domaine mais vous l'utilisez pour un autre.
• Le certificat a expiré.

Liste des shaarlis concernés:
https://www.mypersonnaldata.eu/shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)
https://orangina-rouge.org/shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)
https://links.kevinvuilleumier.net/: CURLE_PEER_FAILED_VERIFICATION (51)
https://bajazet.fr/shaarli/: CURLE_SSL_CACERT (60)
https://liens.effingo.be/: CURLE_SSL_CACERT (60)
https://bleu-pale.fr/links/: CURLE_PEER_FAILED_VERIFICATION (51)
https://links.hoa.ro/: CURLE_SSL_CACERT (60)
https://id-libre.org/shaarli/: CURLE_SSL_CACERT (60)
https://qosgof.fr/fosteb/: CURLE_PEER_FAILED_VERIFICATION (51)
https://foualier.gregory-thibault.com/: CURLE_PEER_FAILED_VERIFICATION (51)
https://adrian.gaudebert.fr/feed/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.nothing-is-3d.com/links/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.olissea.com/mb/links/1/: CURLE_PEER_FAILED_VERIFICATION (51)
https://ithake.eu/shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.korezian.net/liens/: CURLE_PEER_FAILED_VERIFICATION (51)
https://ex0artefact.eu/ahpuch/: CURLE_PEER_FAILED_VERIFICATION (51)
https://shaarli.bananium.fr/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.dadall.info/links/: CURLE_SSL_CACERT (60)
https://dinask.eu/shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)
https://sinon.org/links/feed.rss: CURLE_SSL_CACERT (60)
https://nexen.mkdir.fr/shaarli/: CURLE_SSL_CACERT (60)
https://eownis.myds.me/shaarli/: CURLE_SSL_CACERT (60)
https://links.khrogos.info/: CURLE_PEER_FAILED_VERIFICATION (51)
https://stuper.info/shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)
https://mescanefeux.com/link/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.tribuleblanc.com/shaarli/: CURLE_SSL_CACERT (60)
https://sykius.fr/shaarli/: CURLE_SSL_CACERT (60)
https://shaarlo.fr/shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)
https://shaarli.cafai.fr/: CURLE_SSL_CACERT (60)
https://liens.quaternum.net/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.la-pub-dans-les-films.fr/shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)
https://la-vache-libre.org/shaarli-lavachelibre/: CURLE_PEER_FAILED_VERIFICATION (51)
https://fchaix.eu/shaarli/: CURLE_SSL_CACERT (60)
https://www.margaux-perrin.com/serendipity/: CURLE_PEER_FAILED_VERIFICATION (51)
https://pixelcafe.fr/links/: CURLE_PEER_FAILED_VERIFICATION (51)
https://sammyfisherjr.net/Shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)
https://florian1.tk/shaarli/: CURLE_SSL_CACERT (60)
https://shaarli.guiguishow.info/: CURLE_SSL_CACERT (60)
https://deleurme.net/liens/index.php5: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.mygaia.org/shaarli/: CURLE_SSL_CACERT (60)
https://chichelinux.be/favoris/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.ventredudiplodocus.fr/liens/: CURLE_PEER_FAILED_VERIFICATION (51)
https://tiphainebuccino.com/links/index.php5: CURLE_PEER_FAILED_VERIFICATION (51)
https://erucipe.net/links/index.php: CURLE_SSL_CACERT (60)
https://links.nekoblog.org/: CURLE_PEER_FAILED_VERIFICATION (51)
https://shaarli.gamerz0ne.fr/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.rakforgeron.fr/shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)
https://b.xuv.be/: CURLE_PEER_FAILED_VERIFICATION (51)
https://shaarli.zertrin.org/: CURLE_SSL_CACERT (60)
https://links.yome.ch/: CURLE_PEER_FAILED_VERIFICATION (51)
https://shaarli.amaury.carrade.eu/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.bioshi.ch/liens/: CURLE_SSL_CACERT (60)
https://bookmarks.cdetc.fr/: CURLE_PEER_FAILED_VERIFICATION (51)
https://www.tolima.fr/shaarli/: CURLE_PEER_FAILED_VERIFICATION (51)

Légende:
CURLE_PEER_FAILED_VERIFICATION (51) = The remote server's SSL certificate or SSH md5 fingerprint was deemed not OK.
CURLE_SSL_CACERT (60) = Peer certificate cannot be authenticated with known CA certificates.
source: http://curl.haxx.se/libcurl/c/libcurl-errors.html

Making-of:

#!/bin/bash
wget -q https://nexen.mkdir.fr/shaarli-api/feeds?format=opml --no-check-certificate -O /tmp/shaarlis.opml
#apt-get install xml2
xml2 < /tmp/shaarlis.opml | grep htmlUrl | cut -d"=" -f2 | grep ^https > /tmp/shaarlis_url.txt
for url in $(cat /tmp/shaarlis_url.txt);
do
    curl -s $url >/dev/null
    curl_exit=$?
    if [ "$curl_exit" == "51" ]; then
        echo "$url: CURLE_PEER_FAILED_VERIFICATION (51)"
    else
        if [ "$curl_exit" == "60" ]; then
            echo "$url: CURLE_SSL_CACERT (60)"
        fi
    fi
done

C'est un peu comme ssllabs (serveurs web) mais pour les serveurs XMPP.
Le test est focalisé sur la sécurité DNS et TLS. On peut tester les connexions s2s (server to server) comme les connexions c2s (client to server).

Le but avoué de cet observatoire est bien entendu d'améliorer la sécurité autour de XMPP. Aujourd'hui le bilan est mauvais, un peu comme SMTP. En vrac:

• starttls optionnel voire absent
• ciphersuites pourries des serveurs ou clients xmpp. la derniere maj sécu de ejabberd a corrigé ce problème pour ma part.
• mauvaise configuration au niveau certificat
• ...
  Ces problèmes sont en grandes parties liées à la méconnaissance / l'incompétence des administratreurs de ces serveurs xmpp. D'où la nécessité d'informer.
  Voir aussi ce manifesto à signer si vous êtes admin d'un serveur xmpp public: https://github.com/stpeter/manifesto/blob/master/manifesto.txt

Exemple de résultats avec mon serveur XMPP "privé": http://xmpp.net/result.php?domain=fralef.me&type=client http://xmpp.net/result.php?domain=fralef.me&type=server

edit: un peu déçu de voir les scores aussi pourris du CCC... http://xmpp.net/result.php?domain=jabber.ccc.de&type=server
edit: ils ont daigné updater leur ejabberd. corrigé.

+1...
On trouve aujourd'hui 1832 CA trustées dans nos navigateurs. A part 7 d'entre elles, ces CA peuvent signer des certificats pour n'importe quels domaines, que ce soit google.com ou cequetuveux.fr. Donc pour un gouvernement, il est facile et possible de taper sur l'une de ces CA pour émettre un certificat bidon.

Source des chiffres: http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf

Benjamin Sonntag a partagé ses (très bonnes) configurations SSL/TLS.
J'ai adopté celle de nginx qui me permet d'obtenir la note globale de A sur ssllabs avec un certificat gratuit class1 de chez startssl: https://www.ssllabs.com/ssltest/analyze.html?d=fralef.me
Voilà voilà, en attendant que DANE (http://www.slideshare.net/Deploy360/introduction-to-the-dane-protocol) soit adopté bientôt, pour une sécurité accessible à tous...

Vidéo/slides de la conf SSL/TLS qui a eu lieu le vendredi 20 septembre. J'y étais, il faut que je fasse un compte rendu dès que j'ai le temps.

@skhaen monte une video telechargeable avec slides propres, debut de semaine prochaine!
je créérai un torrent si y'en a pas.

"We observed 3,788 browser-trusted signing certificates between April 2012 and August 2013 of which 1,832 were valid on March 22, 2013. All but seven of these signing certificates can sign a valid browser-trusted certificate for any domain."

En gros, on trouve aujourd'hui 1832 CA trustées dans nos navigateurs. A part 7 d'entre elles, ces CA peuvent signer des certificats pour n'importe quels domaines, que ce soit google.com ou cequetuveux.fr

document via Benjamin Sonntag dans sa conférence (https://confs.fr) qui était ce soir.

"Today, according to the Trustworthy Internet Movement’s data, nearly 33% of the top 200,000 sites are using weak cipher suites and very few have deployed suites that offer Perfect Forward Secrecy (PFS), a mechanism that protects sessions from later key compromise."
Dire que SSL/TLS est troué, c'est pas totalement vrai je pense. Il est surtout hyper mal implémenté et il repose sur un système de certification hasardeux.
via https://www.globalsign.com/blog/trust-the-math-choose-your-friends-wisely.html

La chaîne de confiance des PKI pour la délivrance de certificats SSL est trouée, l'histoire l'a montré. Google a donc lancé une initiative pour améliorer la transparence autour de cette certification. Il s'agit d'un framework open-source (Apache License 2.0) qui permet de monitorer et d'auditer les certificats SSL émis en temps réel. Faut voir..

se passer d'une AC avec DNSSEC :
"Le principe est, plutôt que d'introduire un nouvel acteur, de réutiliser une infrastructure existante, le DNS avec des identificateurs existants, les noms de domaine. Le certificat est publié dans le DNS et signé avec DNSSEC (je schématise : lisez plus loin pour une description complète) et le client TLS peut alors le vérifier."

très bon article!
merci Gopi (https://perso.ens-lyon.fr/guillaume.aupy/shaarli//?beL3yQ)

flux rss = http://wiki.cacert.org/InclusionStatus?diffs=1&show_att=1&action=rss_rc&unique=0&page=InclusionStatus&ddiffs=1
vivement l'inclusion dans firefox..

pour l'installer sur firefox android, il y a juste à le télécharger et un popup apparait après le téléchargement.
à noter qu'installer ce certificat racine, installe aussi le certificat class 3 (http://www.cacert.org/certs/class3.crt)

Juste pour rappeler que, pendant le handshake TLS, le serveur envoie son certificat en clair. Ce dernier contient l'adresse du service web demandé par l'utilisateur.
Donc même avec du chiffrement, un programme d'écoute comme XKeyScore peut connaitre les sites que vous visitez. En revanche pour connaitre les pages visités sur ces sites, il faudra passer par du déchiffrement, une attaque MITM ou autre chose (PRISM).