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

Serait-il possible de déployer HSTS sur le manager (et éventuellement les autres services de la nouvelle galaxie yulpa.io : forum, travaux, site vitrine, blog, etc.) comme s'était le cas avec web4all.fr ? La cerise sur le gateau serait le support de HPKP (bien que parfois un peu casse geule)

Merci pour la réponse Aurélien, XP n'est plus supporté par Cro$osft depuis combien de temps maintenant, et en plus avec IE 6/7... C'est plus dramatique à ce niveau, c'est effroyable... Vista vient aussi de passer l'arme à gauche... Ils savent que Firefox sous XP leur offre TLSv1.2 ? Ils représentent quel pourcentage des visiteurs ces clients ? Vu que le manager n'est plus accessible (pas de SSLv3 sur my.yulpa.io et sur l'ancien manager), ça doit pas être une grande proportion. On peut donc avoir une IP dédiée pour un domaine ? Jusqu'à maintenant, tous les sites que j'ai utilise HTTPS via SNI uniquement et il n'est fait nulle part mention de la possibilité d'avoir des IP dédiées (à ma connaissance) lors de l'utilisation de HTTPS. Pour l'argument du "pas de SSL" est abscons : Faudra que l'on m'explique en quoi supprimer SSLv3 et des suites de chiffrements trouées va poser problème à un site qui n'utilise pas HTTPS ? Une option de compromis serait de permettre de modifier, par virtualhost, les protocoles et les suites de chiffrements (via une option dans le manager ou via SSH). Ainsi celui qui souhaite disposer de SSLv3 le peu, celui qui souhaite uniquement TLSv1.2 et AES-GCM le peu aussi.

On peu aussi faire du 2 facteurs avec SSH, mais c'est peut-être un poil trop geek ? https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Multi-Factor_Authentication_.28OpenSSH_6.3.2B.29

moi aussi je serai pas mal content si y'avait un serveur XMPP. SI possible en bonne place dans cette liste serait tip top : https://gultsch.de/compliance_ranked.html

Repost depuis l'ancien forum : https://forums.web4all.fr/topic/10335-suppression-de-sslv3-et-des-ciphers-vulnérables/ Une idée de la date de disparition de SSLv3 sur les hébergements mutualisés ? Tous les sites mutualisés en HTTPS utilise SNI, cependant SSLv3 ne le supporte pas, donc un client qui ne supporte que SSLv3 ne pourra de toute façon pas se connecter... Dans la même logique, supprimer les ciphers vulnérables (RC4, 3DES &Co) serait aussi un plus, puisse qu'ils ne sont utiles qu'avec les clients qui supportent uniquement des protocoles obsolètes. Idées pour la chaine de ciphers de mod_ssl SSLCipherSuite EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AESGCM:EDH+AESGCM:EECDH+AES:EDH+AES:EDH+CAMELLIA:CAMELLIA:!3DES:!aNULL:!MD5:!PSK:!SRP:!LOW:!ADH:!DSS:!RC4:!EXPORT:!eNULL:!DES SSLHonorCipherOrder on SSLProtocol all -SSLv2 -SSLv3 SSLStrictSNIVHostCheck On SSLCompression off Merci d'étudier la question.

Bonjour, Je reposte le même message de l'ancien forum : quid du support de l'IPv6 pour le cluster http01 ? Réponse obtenue à l'époque : "c'est à prévoir, mais c'est pas la priorité".

Bonjour à toute l'équipe, Je reposte ici une demande d'évolution concernant la config SSH (côté serveur) de ssh.web4all.fr (et qui concerne aussi sans doute tous les serveurs w4a utilisant SSH) qui était sur l'ancien forum. Première chose le bout de code à ajouter à /etc/ssh/sshd_config : HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_rsa_key KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com UsePrivilegeSeparation sandbox AuthenticationMethods publickey,keyboard-interactive:pam UsePAM yes Seconde, le constat : https://tls.imirhil.fr/ssh/ssh.web4all.fr:22 Comme le montre très bien CryptCheck, la config SSH est un peu faiblarde (particulièrement au niveau chiffrement et MAC). Maintenant le pourquoi du bout de code : pour renforcer sensiblement la sécurité et l'intégrité des données échangées avec les clients modernes qui supportent des chiffrements forts et laisser cependant les clients obsolètes se connecter tout de même sans souci. L'utilisation de clefs serveurs ed25519 et ecdsa ne devrait pas trop surcharger les serveurs, alors que RSA reste présent pour la compatibilité. Edit : c'est également dans les recommandations de Mozilla concernant la sécurité : https://wiki.mozilla.org/Security/Guidelines/OpenSSH Merci d'étudier la demande a l'occasion. Et je rajoute -- pour ceux que cela intéresse -- le pendant pour la config SSH client (Protocol 2 uniquement, évidement) : # Pour chaque Host, des règlages spécifiques, qui peuvent écrasés ceux défini de manière générale (cf. section Host *) : Host 10.0.0.1 IdentityFile ~/.ssh/id_ecdsa_key_example.org X11Forwarding no ForwardX11Trusted yes IdentitiesOnly yes Host myvnc.example.org User root IdentityFile ~/.ssh/id_ecdsa_key_example.org X11Forwarding no ForwardX11Trusted yes IdentitiesOnly yes Host ssh.example.net User xxx-w4a IdentityFile ~/.ssh/id_ecdsa_key_ssh.example.net IdentitiesOnly yes Host www.example.net User web IdentityFile ~/.ssh/id_ecdsa_key_web.example.net IdentitiesOnly yes Host xyz.example.com User username IdentityFile ~/.ssh/id_ed25519_example.com IdentitiesOnly yes Host 192.168.* IdentityFile ~/.ssh/id_ed25519_local_lan IdentitiesOnly yes Host *.biz User username IdentityFile ~/.ssh/id_ed25519_local_business_lan ForwardAgent yes IdentitiesOnly yes Host github.com User username MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-128-etm@openssh.com,hmac-sha2-512 IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yes # Config général pour tous les hosts et ceux non définis ci-dessus : Host * Protocol 2 # SSH v1 est à éviter absolument ! SendEnv LANG LC_* IdentitiesOnly yes HashKnownHosts yes StrictHostKeyChecking ask CheckHostIP yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication yes X11Forwarding no ConnectTimeout 30 HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256 KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com # Cipher ... est commenté puisse que ne concerne que SSH v1 # IdentityFile ~/.ssh/id_rsa aucune clef n'est proposée par défaut, elle doit être définie spécifiquement pour chaque serveur. Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr ServerAliveInterval 10 ControlMaster auto ControlPersist yes ControlPath ~/.ssh/socket-%r@%h:%p L'utilisation de IdentitiesOnly yes permet de limiter les clefs SSH envoyées pour l'identification aux seules clefs spécifiées pour le serveur en question. Cela évite à un serveur de récupérer le fingerprint de toutes les clefs (coucou le tracking des utilisateurs) alors qu'il existe une clef spécifiquement dédiée pour celui-ci