"""
Android versions >= 4.1/4.2 and < 5.0 support TLS 1.1 and TLS 1.2, but these (newer and more secure) TLS versions are disabled, while only SSLv3 and TLSv1 stay enabled by default.
"""

Le développeur de davdroid a trouvé la parade: http://blog.dev001.net/post/67082904181/android-using-sni-and-tlsv1-2-with-apache-httpclient
en attendant: sur ttrss, owncloud, le client munin pour ne citer que ces 3 là: je me tape un
"""
javax.net.ssl.SSLException: SSL handshake aborted: ssl=0x1cc160: I/O error during system call, Connection reset by peer
"""

Je suis donc obligé d'activer TLSv1 niveau serveur..

C'est corrigé dans android 5: http://developer.android.com/about/versions/android-5.0-changes.html#ssl
"""
TLSv1.2 and TLSv1.1 protocols are now enabled,
AES-GCM (AEAD) cipher suites are now enabled,
MD5, 3DES, export, and static key ECDH cipher suites are now disabled,
Forward Secrecy cipher suites (ECDHE and DHE) are preferred.
"""

Origine de ma découverte: http://stackoverflow.com/questions/20741405/javax-net-ssl-sslexception-ssl-handshake-aborted-connection-reset-by-peer-while/20745624#20745624

Mozilla's SSL config generator pour apache, nginx et haproxy.

Cette page wikipedia montre la matrice de compatibilité de TLS, dans ses différentes versions, avec les navigateurs.
On peut constater que IE6 est compatible TLS en 1.0 uniquement mais ce support est désactivé par défaut.
Cela veut dire que si vous désactivez sslv3 (#poodle), vous privez les monsieurs/madames michu qui sont encore sur ce navigateur préhistorique.

Oui, car sslv1 et sslv2 sont également troués et que ça doit faire longtemps que vous les avez viré des protocoles à utiliser.
ssl est mort, vive tls.

"""
Does HTTP/2 require encryption?

No. After extensive discussion, the Working Group did not have consensus to require the use of encryption (e.g., TLS) for the new protocol.

However, some implementations have stated that they will only support HTTP/2 when it is used over an encrypted connection.
"""
tiens tiens, le chiffrement est passé de requis à facultatif...

Cette news ne m'étonne pas.
il n'y a qu'à se rendre sur l'interface web de son compte client orange (oui je suis chez sosh.. ne m'en voulez pas) pour comprendre.

Suivant les pages bourrées de pubs et dont le design forment un beau patchwork, on a des technos différentes: cgi, php, etc. Bienvenue en 2014.

Il y a du TLS/SSL sur le POST qui permet de se connecter mais après c'est intermittent suivant les pages... C'est parfait pour des attaques en MITM comme celles de SSL striping.
http://www.thoughtcrime.org/software/sslstrip/

Et donc là on a Stéphane Richard qui met en danger la sécurité de ses clients et qui se permet de demander à Google de moins chiffrer. WTF?!

ordre:

• clé privée au format PEM
• certificat au format PEM
• certificat intermédiaire au format PEM

Cloudflare offre le chiffrement ssl/tls sur son CDN.
Il faut juste garder à l'esprit que tout le traffic est déchiffrable au niveau de leurs serveurs car ils possèdent la clé privée....
Indépendemment de ça, c'est encore un truc qui centralise le traffic. c'est donc mal.

Ah j'oubliais, cloudflare bloque tor… demande parfois de saisir des captchas… utilise du cookie et du javascript… et fait des appels externes vers google.

Soyez indépendant, utilisez startssl et générez votre clé privée ssl/tls chez vous.

une page qui recense le niveau de sécurité SSL/TLS de différents sites français.
elle montre que des particuliers sécurisent mieux leurs serveurs webs que des sociétés qui brassent bcp de pognon, comme des banques. normal..

vous aussi, mettez du tls correct en suivant ce tuto: https://www.jeveuxhttps.fr/%C3%89tape_1_Installer_HTTPS_sur_le_serveur,_pour_informaticien
prévenez @aeris (https://blog.imirhil.fr/) pour qu'il ajoute votre site (de préférence avec note A+)

plein d'outils pour tester du SSL / TLS

• mail servers test
• web server test (voir aussi le très bon https://www.ssllabs.com/)
• liste de quelques hébergeurs de mail avec indication de la façon dont SSL / TLS est implémenté
• un outil pour tester la délivrabilité des mails et pour identifier comment est réalisé la connexion (securisée ou pas, avec quels protocoles et quels algo de chiffrement): https://ssl-tools.net/mails

L'auteur parle de techniques, dont j'avais déja parlé ici (https://jeekajoo.eu/links/?zEE0mA), pour renouveler[1] un certif startssl sans frais avant expiration.

Pour ma part, j'utilise actuellement un cert valable pour xxx.fralef.me (ne cherchez pas, y'a rien à cette adresse les coquinous) et fralef.me.
Au lieu d'en fabriquer un autre sur le même modèle (sous domaine bidon), je vais pouvoir récupérer mon premier certif valable pour www.fralef.me (et fralef.me) que j'avais créé avant la faille heartbleed, et qui expire à la fin de ce mois.

Je pourrais donc avoir un certif tout beau tout neuf en SHA-2 et avec un sous-domaine plus conventionnel, et gratuitement toujours.

[1] je dis ça pour simplifier mais il ne s'agit pas de renouvelement. il s'agit de créer un nouveau certif également valable pour le domaine cible, en laissant l'ancien expirer.

pour vérifier si votre certif utilise SHA-1: https://shaaaaaaaaaaaaa.com/
le cas échéant il faut regénérer le certif en utilisant le flag -sha256 lors de la création du CSR (Certificate Signing Request).
edit: ne pas oublier d'utiliser un certificat intermédiaire en SHA-2 lui aussi. https://shaaaaaaaaaaaaa.com/ en liste quelques uns.

j'aime beaucoup le passage suivant:
"""
For companies, certificates are generally obtained for as long as possible, stuck wherever, and forgotten about until it's time to panic.
"""
pas mieux.

pour vérifier si votre certif utilise SHA-1: https://shaaaaaaaaaaaaa.com/
le cas échéant il faut regénérer le certif en utilisant le flag -sha256 lors de la création du CSR (Certificate Signing Request).
edit: ne pas oublier d'utiliser un certificat intermédiaire en SHA-2 lui aussi. https://shaaaaaaaaaaaaa.com/ en liste quelques uns.

j'aime beaucoup le passage suivant:
"""
For companies, certificates are generally obtained for as long as possible, stuck wherever, and forgotten about until it's time to panic.
"""
pas mieux.

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

• Firefox vérifie la validité des certificats via des requêtes OCSP synchrones (avec soft-fail par défaut).
• Chrome vérifie la validité en consultant une base locale nommée CRLSet qu'il met à jour de manière asynchrone.

Pensez à vérifier que vous utilisez une version récente de CRLSet en allant sur chrome://components/.
A ce jour, la dernière version est 1599.
CRLSet est censé se mettre à jour automatiquement mais ce n'est pas toujours le cas.
Comme le montre ce bug report debian, il peut arriver que la base CRLSet ait une vingtaine de versions de retard.

Ces 2 sites devraient provoquer une erreur:
https://www.cloudflarechallenge.com/ (certificat révoqué assez récemment)
https://revoked.grc.com/

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.

Après avoir bien galéré pour tenter d'associer mon nouveau certif à un point de distribution cloudfront:
"InvalidViewerCertificateException: Status Code: 400, AWS Service: AmazonCloudFront, AWS Request ID: ec9e6070-c17a-11e3-b4c8-5dba0fa26705, AWS Error Code: InvalidViewerCertificate, AWS Error Message: The specified SSL certificate doesn't exist in the IAM certificate store, isn't valid, or doesn't include a valid certificate chain."

J'apprend au fin fond d'un compte twitter (https://twitter.com/peksa/status/441713269309706241, confirmé ici http://stackoverflow.com/questions/17537498/having-trouble-associated-ssl-cert-with-amazon-cloudfront) que cloudfront n'accepte pas les certifs dont les clés ont une taille supérieure 2048 bits.
Cela alors qu'awscli n'a pas gueulé à l'import de mes clés qui font 4096 bits (via l'API, car pas d'autres options).

Doc AWS merdique!
VDM.

ref doc officielle: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

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.