alh

Je me permets de relancer le sujet, je n'ai rien vu dans votre communication qui donne une idée du déploiement d'IPv6. Merci

Mouais... j'ai jamais été convaincu par le "tout module" de WP, ca devient vite une usine à gaz...

OK. Merci pour la réponse. On peut importer un couple clef privée/certificat uniquement. Donc il faut générer manuellement son certificat Let's Encrypt, comme l'indique Aurélien

Oui, je parle bien de la génération de clefs pour des cert Let's Encrypt via iWal. J'ai d'autres certificats importés et fonctionnels (générés via Gandi) qui n'apparaissent d'ailleurs pas dans la section concernant les certificats importés. En effet, on peut très bien générer manuellement un cert Let's Encrypt en local, avec une taille de clef particulière, mais on perd le côté "automatisé" justement. Avoir une clef personnelle (avec un cert Let's Encrypt) permet par exemple d'utiliser HPKP, ce qui est impossible avec une clef générée "sans controle", car elle peut changer à tout moment.

Je viens de faire un test, c'est plutot simple en effet. Good. Par contre, dans les petits plus qui seraient intéressants : importation de sa clef (et donc CSR) si génération par iWal : choix de la taille de clef et du type (ECDSA ou RSA) lorsque Let's Encrypt le supportera (ETA : 1er Septembre 2017)

Bonne nouvelle. Dans ce cas, le support de DNSSec serait-il envisageable ? Je suppose que vous utilisez BIND. Dans ce cas, il faudrait ajouter OpenDNSSec. Ou alors faire le grand saut vers quelque chose qui m'attire de plus en plus : https://www.knot-dns.cz/

oui HTTP/2

Hello, Dans le cadre de la refonde du pool http01, serait-il possible d'envisager le support de h2 lors des connexions HTTPS. SI j'ai bonne mémoire, vous utilisez une base CentOS 6, qui ne propose pas Apache 2.4, mais l'utilisation d'un LB ngnix ou haproxy supportant H2 pourrait-il être envisagé ?

Et pour compléter, je recommanderais de rajouter ceci au .htaccess : # bloquer les attaques XSS Header always set X-XSS-Protection "1; mode=block" # activer le plus haut mode de rendu pour IE Header always set X-UA-Compatible "IE=Edge" # eviter le click hijacking ou le vol d'identifiant via des frame Header always set X-Frame-Options "SAMEORIGIN" # eviter que le client exécute du code malicieux dans des fichiers vérolés (js dans jpeg par ex) Header always set X-Content-Type-Options "nosniff" # préciser la gestion du referer: https://scotthelme.co.uk/a-new-security-header-referrer-policy/ Header always set Referrer-Policy" strict-origin-when-cross-origin" # Activation de HSTS (pour éviter les requetes en non chiffrées): https://hstspreload.org/ Header always set Strict-Transport-Security "max-age=63072000" # Content Security Policy (attention la config peut être casse-geule): https://www.w3.org/TR/CSP2/ et https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy Header always set Content-Security-Policy "default-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'self'; img-src 'self'; font-src 'self'; frame-ancestors 'self'" Il est possible de vérifier tout cela avec les sites suivants : https://www.ssllabs.com/ssltest/ https://tls.imirhil.fr/ https://securityheaders.io/ https://observatory.mozilla.org/ Et si on souhaite implémenter correctement la compression Gzip sur le site : SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI \.(?:bmp|bbaw|crx|cur|f4[abpv]|flv|gif|ico|jpe?g|m4[av]|mp4|oex|og[agv]|opus|otf|pdf|png|safariextz|svgz|swf|tt[cf]|web[mp]|woff2?|xpi)$ no-gzip dont-vary <FilesMatch "\.(appcache|css|htc|js|manifest|map|rdf|svg|txt|vcard|vcf|vtt|webapp|webmanifest|xloc|csv|xls|po|shtml|phtml|html?|atom|xml|rss)$"> Header set Vary Accept-Encoding Header append Cache-Control "no-transform" </FilesMatch>

Merci. Les rares foix ou j'utilise Let's Encrypt, c'est souvent sur des serveurs dédiés avec CertBot (https://certbot.eff.org/)

Arff, j'avais pas vu... faut juste charger le site en HTTPS et zou ?

Hello, Des nouvelles concernant l'éventuel support de certificats Let's Encrypt pour les hébergements ? C'est dans les tuyaux ?

Concernant HSTS, il y a plusieurs options possibles : juste pour le domaine/sous-domaine correspondant, pour le domaine/sous-domaine et les sous-domaines, avec preloading... Je ne pense pas que un HSTS du type Strict-Transport-Security: max-age=63072000 vous posera des problèmes pour les applis déjà accessibles par HTTPS, il n'y pas pas de preloading possible et il n'y a pas d'implication des sous-domaines... éventuellement un Strict-Transport-Security: max-age=63072000; includeSubDomains si tous les sous domaines HTTP de yulpa.io s(er)ont accessibles en HTTPS

Un autre truc "cool" serait de permettre la modification de l'ordre de préférence des courbes ECC pour ECDHE, mais j'en demande sans doute un peu trop...

Serait-il possible d'ajouter le support des enregistrements DNS CAA dans le manager : https://tools.ietf.org/html/rfc6844 https://fr.wikipedia.org/wiki/DNS_Certification_Authority_Authorization