mais non, cadeau: http://www.iletaitunefoisinternet.fr/ssltls-benjamin-sonntag/

:)

Je l'ignorais mais Firefox et Chromium (et bientôt IE, mais on s'en fou) font du HSTS preloading.
Cela signifie que pour une liste de sites (http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json) le navigateur va envoyer des headers HSTS pour garantir que la première connexion (du moins celle du serveur vers le client) et le reste des communications se feront en TLS de manière obligatoire.
Cela permet de se prémunir des attaques dites de "SSL stripping" dont voici un PoC: http://www.thoughtcrime.org/software/sslstrip/. C'est une sorte attaque MITM qui est faite avant que la connexion soit chiffrée.
Source de l'info: https://www.imperialviolet.org/2014/07/06/newtlds.html

article très intéressant.
dans un précédent shaarlink j'avais dit que par défaut les navigateurs ne vérifiaient pas les listes de révocation; c'est faux. ils le font mais s'ils ne parviennent pas à contacter les serveurs ocsp, ils valident le certificat. C'est ce qu'on appele le soft-fail et cela évite le SPOF des serveurs ocsp qu'on ne peut pas joindre (wifi hotel) ou qui sont down...

super, merci pour l'info!
en tout cas leurs certifs SSL n'a pas bougé.... (créé le 14/01/2014)

Hum j'avais zappé de mettre le certificat intermédiaire class1 de startssl (sub.class1.server.ca.pem) à la suite du certif que je présente à nginx pour mon site.
Or certains navigateurs (ou OS, suivant l'implémentation des certifs) ne l'ont pas par défaut. Du coup ça gueulait car la chaine de certification était rompue.

Contrairement à ce que dit l'article il n'est pas nécessaire d'inclure le root ca (ca.pem) dans le chain:
$ cat example.com.pem sub.class1.server.ca.pem (((ca.pem))) > example.com_chain.pem

Ah, et sinon l'auteur conseille cette directive:
add_header X-Frame-Options DENY;
Je ne l'utilise pas car roundcube et cozycloud (pour ne citer que ces 2 là) cessent de fonctionner correctement avec. Donc attention.

Pour renouveler un certif class1 startssl à l'identique il faut passer par la case révocation et c'est 25$.. (https://jeekajoo.eu/links/?KQxECQ)

La technique que j'ai trouvé consiste à créer un autre certif sur un cname différent. Dans mon cas j'avais un certif dont le cname était www.fralef.me avec altname (obligatoire) fralef.me. Là je viens d'en créer un nouveau avec fralef.me en cname et xxx.fralef.me en altname car je n'avais le droit de reprendre www.fralef.me et que je me tape de ce sous-domaine...

Reste un probleme non résolu: la révocation de l'ancien certif... cela dit les navigateurs ne vérifient pas les listes de révocation par défaut. donc même en le révoquant je ne suis même pas sur qu'il ne pourra pas être réutilisé par un tier jusqu'à son expiration (https://jeekajoo.eu/links/?QPGHqQ).

Enfin il y a le perfect forward secrecy que j'ai mis en place depuis un moment, et qui est censé me garantir que même si on a collecté des données chiffrées avec ma clé qui a potentiellement été leakée avant que je patch: on ne pourra pas les déchiffrer. Bon je ne dis pas que je me sens pour autant à l'abris des NSA et consorts. Ça serait extrèmement prétentieux et hautement improbable, car l'histoire a montré qu'ils avaient toujours un coup d'avance.

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

Site permettant de vérifier la conf TLS de son serveur smtp.

J'obtiens 82.25% avec mon serveur (https://starttls.info/check/fralef.me).
La directive "smtpd_tls_ask_ccert" (http://www.postfix.org/postconf.5.html#smtpd_tls_ask_ccert) m'a permis de résoudre le problème suivant:
"Anonymous Diffie-Hellman is accepted. This is suspectible to Man-in-the-Middle attacks."
Comme le dit la documentation, cette directive peut ammener quelques problèmes avec certains clients mais moi j'm'en bas les c.
Voir aussi https://groups.google.com/forum/#!topic/mailing.postfix.users/ouXKCofURDc

Ma conf postfix est à l'origine largement forkée depuis celle de Benjamin Sonntag: https://confs.fr/ssl-tls.html. Merci à lui.

recommendations TLS par mozilla

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é.

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.

Avoir son serveur xmpp c'est vraiment symbolique... en tout cas pour moi.. car 95% des gens auquels je parle sur xmpp utilisent un compte gtalk.
Comme si cela ne suffisait pas, Google n'autorise pas TLS pour les communications de serveur à serveur (s2s)...

Logs de mon serveur xmpp quand il essaie de communiquer en TLS vers google :
I(<0.2729.0>:ejabberd_s2s_out:1203) : Trying to open s2s connection: fralef.me -> gmail.com with TLS=true
I(<0.2772.0>:ejabberd_s2s_out:365) : Connection established: fralef.me -> gmail.com with TLS=false

De là à dire que c'est fait exprès pour faciliter les interceptions, il n'y a qu'un 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)