GuiGui's Show

POODLE, tout comme Heartbleed en son temps, fait couler beaucoup d'octets dans les internets ces derniers jours. Je vais donner mon avis sur ce que je pense être un effet de mode et surtout, une précipitation.

Disclaimer :
    1) Je ne suis pas un security guru.
    2) Ce que je vais dire s'applique dans le cadre de petits serveurs (auto-hébergés ou non) sans trop de trafic et sans contrainte. J'veux dire que je ne tiendrais pas le même discours s'il s'agissait du site web d'une banque ou d'un site web d'e-commerce ou d'un site web à très fort trafic (sur la partie ECDSA versus RSA). On constate d'ailleurs que, dans ces contextes-là, la réalité est toute autre que celle que je vais décrire car il y a le côté opérationnel à prendre en compte : https://imirhil.fr/ssl.html ;)


Commençons par POODLE (voir, entre autres http://seenthis.net/messages/302666) : il s'agit d'une faille dans le protocole SSLv3, pas d'un bug dans une implémentation particulière (comme OpenSSL). Ça m'en touche une sans faire bouger l'autre dans le sens où TLSv1.0 c'est so 1999 et que SSL est déprécié depuis fort longtemps. C'est un problème humain (adminsys consciencieux) et opérationnel (gérer les vieux clients dans certains contextes comme banques/e-commerce, frilosité au changement, ...). Sur nos petits serveurs persos, ça devrait être désactivé sans soucis à moins que les parts de marché d'IE6, 3,8 % au niveau mondial et 0.8 % en France en septembre 2014 revendiquées par Microsoft (https://www.modern.ie/en-us/ie6countdown), la réalité doit être légèrement supérieure ainsi que des appliances/automates proprios désuets ne vous intéressent. Après si le raffut inutile de ces derniers jours permet des  prises de conscience, pourquoi pas ...




L'ennui, c'est que je vois, principalement sur IRC, des adminsys se questionner sur la conf' TLS de leurs logiciels serveurs, ce qui est une bonne chose comme je viens de le dire, mais en poussant le vice trop loin. Mon plus grand conseil sera le suivant : gardez la raison, ne faites pas n'importe quoi, n'affaiblissez pas vos confs en croyant les renforcer. La sécurité dans l'urgence ne marche jamais. N'écoutez pas aveuglément toutes les ressources sur le web, n'écoutez pas aveuglément un validateur quand bien même il est aussi bien foutu que celui de ssllabs (https://www.ssllabs.com/ssltest/) ! À ce sujet, voir, par exemple, l'illustration avec BEAST : https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat - « Unfortunately, the only way to mitigate the BEAST attack is to enforce the use of RC4 suites whenever TLS 1.0 and earlier protocols are used (which is most of the time at this point). I say "unfortunately", because very shortly after we had started requiring server-side mitigations, new research about RC4 came out and we found out that this cipher was much weaker than previously thought. The weaknesses were not of immediate concern, but it was clear that RC4 was on the way out. » :)


Parmi ces questionnements, on retrouve les questions liées au résultat du test (ssllabs ou autre) et des débats plus profonds : ECDSA ou RSA ? SHA-1 ou SHA256 pour condenser mon certificat ? Quelle liste d'algorithmes cryptographiques autoriser ? Je déploie DANE, HSTS et compagnie ? ... C'est un vice de raisonnement, à mon humble avis. La priorité, ce n'est pas de passer en ECDSA comme si RSA vivait ses derniers instants ou de passer immédiatement à SHA256 pour condenser son certificat ou de passer à RSA 4096 bits au lieu de 2048 bits parce qu'un validateur vous l'a *conseillé* (« When renewing, ensure [...] »). L'important à l'heure actuelle, à mon humble avis, et ça sera mon deuxième grand conseil, c'est de garder la confiance et pour ça, de ne pas générer d'erreurs du côté de l'utilisateur et pour ça, de ne pas casser vos certificats x509 et les configurations de vos logiciels serveurs. On corrige donc les failles bien actuelles comme Poddle et, si l'on en a la motivation, on durcit la conf' TLS de ses logiciels serveurs en douceur.


Je vais quand même donner mon avis sur ces questionnements, ça serait idiot de dénigrer au lieu de guider.
    - Courbes elliptiques (ECDSA) versus RSA : c'est un débat théorique qui amuse les cryptologues mais ça n'a aucune réalité pratique. Les limites de la cryptographie interviennent sur des choses beaucoup plus connes et concrètes (générateur de nombres pseudos aléatoires pas assez aléatoires, bug logiciel, cryptographie mal utilisée (de la crypto avec IE6 sous XP, comment dire ...), ...) Les deux procédés sont toujours d'actualité. Le seul argument de plus en faveur des courbes elliptiques est leur faible taille (à niveau de sécurité jugé équivalent) et des temps de traitement plus courts donc une montée en charge des sessions TLS avec de nombreux clients facilitée. Les algos ECDHE-* sont moins gourmands que leurs homologues DHE-*. Sur des serveurs persos, ce gain n'a pas d'intérêt. Ce n'est pas pour autant que je crache sur ECDSA. Quant à utiliser les courbes elliptiques dans les certificats x509, le gain est encore moins évident : la validation du certificat se fait au début de la session TLS, pas en continu et sur le client (usage standard). Ne cassez pas vos certificats actuels parce qu'on vous a dit que RSA c'est fini à cause de POODLE, ça serait contre-productif !


    - SHA-1 / SHA256 comme fonction de condensation dans les certificats x509. SHA-1 sera peut-être dans les prochains algos cryptographiques à tomber donc il faut préparer la migration vers mieux (SHA256) mais, pour l'instant, on n'a aucune attaque efficace et imminente contre SHA-1.  Alors oui, je sais, le méchant Google a annoncé qu'ils vont favoriser de pas beaucoup les sites web accessibles en HTTPS puis qu'ils vont virer SHA-1 à eux tous seuls (voir : http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html) ... Tout ça pour se racheter suite aux révélations de Snowden, ce qu'il ne faut pas faire. :)

        1) On ne panique pas et je ne suis pas seul à tenir ce discours :  https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know . De plus, Google vont pénaliser d'abord les certificats auto-signés, ne nous faisons pas d'illusions donc SHA-1 versus SHA256, ça se place là dans l'ordre des priorités quoi.
        2) Google est-il vraiment indispensable pour la survie de nos sites web persos pas monétisés ?
        3) On regarde les certificats des AC (oui, toute la chaîne de confiance doit être SHA256, pas que les certificats finaux, sinon c'est stupide) présents dans le magasin de certificats Debian (ça serait pareil avec celui de Mozilla, juste ce check s'automatise bien) et on voit que la messe est dite :
                Total : 960 - 100 %
                        md5 (/!\ depuis le temps que MD5 est *mort* ce qui n'est même pas encore le cas de SHA-1)  : 66 - ~ 7 %
                        sha1 : 744 - 77,5 %
                        sha256 : 114 - ~ 12 %
                        sha384 : 36 - 3,75 %

        Donc, passer à SHA256 lors du prochain renouvellement normal de votre certificat (car il va expirer), c'est une bonne idée, bien sûr. Dans le contexte actuel, crise/peur (avérée ou imaginée, ça revient au même), c'est une mauvaise idée pour si peu : maintenir la confiance est primordiale (surtout avec les certificats autosignés ou AC autosignée) comme je l'ai écrit plus haut.


    - Je pense le plus grand bien de DANE (voir http://shaarli.guiguishow.info/?y6WIyg) mais déployons déjà DNSSEC (qui est un pré-requis) convenablement, avec des procédures (roulement des clés) éprouvées et on pourra ensuite se mettre à DANE. Il n'y a aucun serveur/client dans sa branche stable (au sens Debian, lala :D) qui utilise ces enregistrements donc rien ne presse : le gain de sécurité ne sera pas imminent. Mais là encore, ajouter ça sur sa TODO des choses à faire à moyen terme est une bonne idée.


    - HSTS (voir : http://www.bortzmeyer.org/6797.html) est encore une bonne idée. Mais réfléchissez bien avant de déployer : la configuration doit être parfaite car la moindre erreur est bloquante et mise en cache quand on active HSTS ! Par ailleurs, les certificats autosignés génèrent des erreurs donc ça va plutôt mal se passer avec HSTS.


    - Faut-il tuner le cache des sessions TLS ? S'il n'y a aucun inconvénient à l'activer, Il faut mesurer le gain d'aller le tuner finement. Sur un service avec 10 connexions (css/images inclues pour un site web) par tranche de 30 mns, bof, le cache va pas servir des masses donc aller tuner ça comme pour un site à fort trafic, c'est sans grand intérêt, àmha, autant se reposer sur les paramètres par défaut des logiciels serveurs. Sur un serveur mail, avec la concentration des acteurs, l'abonnement à des ML, ... ça se justifie déjà plus mais stay relax quand même. :D




Pour les confs TLS de mes logiciels (elles sont disponibles à la fin de ce shaarli et valent ce qu'elles valent), je me base sur ces ressources déjà pointées dans d'autres de mes shaarlis :
    - Conf' « SSL/TLS » par Benjamin Sonntag à Il était une fois Internet. Les configurations présentées après un exposé plus général sont détaillées et expliquées. http://confs.fr/ssltls-benjamin-sonntag/
    - Pour des configurations clé en main de logiciels serveurs courants et une liste d'algorithmes à privilégier (attention, Mozilla, ça peut être biaisé pour garder la compatibilité avec les anciennes versions de Firefox/Thunderbird/autre) : https://wiki.mozilla.org/Security/Server_Side_TLS


Enfin, àmha, la priorité (en général, pas POODLE), ce n'est pas tellement nos petits serveurs web qui servent des sites web à contenu informatif (donc pas e-commerce / banque / dépôt de  données personnelles / contenu "sensible" où sensible se défini du point de vue du visiteur, pas du nôtre). Non, la priorité c'est nos serveurs mails (SMTP *ET* IMAP) et nos serveurs XMPP (C2S et S2S). C'est là qu'est le vrai contenu privé que l'on veut protéger. D'ailleurs, pour tester la conf' TLS votre serveur XMPP, voir : http://shaarli.guiguishow.info/?AKSlXA .

Donc, pour résumer : -SSLv2/-SSLv3, -RC4 (oui, je sais, BEAST mais sur nos petits serveurs persos, je pense qu'on peut ignore l'usage de TLSv1.0), +PFS (Perfect Forward Secrecy, confidentialité persistante, les échanges sécurisés précédant une compromission d'une clé privée ne sont pas eux-mêmes compromis et restent donc secrets. Donc Diffie-Hellman éphémère donc algos DHE-*, ECDHE-*) et on se relaxe. \o/




Les configurations TLS de mes logiciels serveurs :

ÉDIT DU 03/01/2016 À 23H00 : J'ai mis à jour ces configs avec les dernières directives de configuration disponibles dans les versions packagées dans Debian GNU/Linux Jessie. FIN DE L'ÉDIT.

Apache2 :
    SSLEngine on
   
    SSLCertificateFile    /etc/apache2/ssl/viki.crt
    SSLCertificateKeyFile /etc/apache2/ssl/viki.key

    SSLProtocol All -SSLv2 -SSLv3
       
    SSLCipherSuite ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    SSLHonorCipherOrder on

    # Par defaut
    SSLCompression off
    SSLSessionCacheTimeout 300

    # Parametres DH - Ils sont auto generes selon la taille de la cle
    # utilisee. Si l'on veut des dhparam personnalises, cela necessite
    # openssl 1.0.2 pas encore dans Jessie ou de les concat a la fin du
    # fichier contenant le certif x509 aka c'est crade...
    # SSLOpenSSLConfCmd DHParameters "/etc/apache2/ssl/dh_4096.pem"

    # Cache partages des sessions TLS : mod_socache_* sont necessaires
    # mais pas encore dispo dans Debian stable (01/02/2014)
    # Un cache partages des sessions TLS ne se justifie pas ici :
    # contenu simple : pas besoin de plusieurs connexions simultanees
    # et utilisateurs qui ne reviennent pas dans des delais brefs, en majorite




nginx :
    ssl on;

    ssl_certificate /etc/nginx/ssl/pokedex.crt;
    ssl_certificate_key /etc/nginx/ssl/pokedex.key;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_ciphers ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM;
    ssl_prefer_server_ciphers on;

    # Compression TLS desactivee par defaut dans nginx

    # Parametres DH
    ssl_dhparam /etc/nginx/ssl/dh2048.pem;

    # Par defaut
    ssl_session_timeout 5m;

    # Un cache partages des sessions TLS ne se justifie pas ici :
    # contenu simple : pas besoin de plusieurs connexions simultanees
    # et utilisateurs qui ne reviennent pas dans des delais brefs, en majorite




Dovecot :
    ssl = required

    ssl_cert = </etc/postfix/ssl/pokedex.crt
    ssl_key = </etc/postfix/ssl/pokedex.key

    ssl_protocols = !SSLv2 !SSLv3

    ssl_cipher_list = ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    ssl_prefer_server_ciphers = yes

    # Parametres DH. 4096 bits dans cet exemple car
    # ca correspond a la taille de ma cle
    ssl_dh_parameters_length = 4096

    # Dovecot ne propose aucune autre option




ejabberd :
    ## c2s (bloc listen)
    -
      port: 5222
      ip: "::"
      module: ejabberd_c2s
      max_stanza_size: 65536
      shaper: c2s_shaper
      access: c2s

      # TLS est obligatoire entre un client XMPP (gajim par ex) et le serveur
      starttls: true
      starttls_required: true

      # attention, il faut chainer le certificat x509 et la cle privee.
      # Exemple : cat pokedex.crt pokedex.key > pokedex.crt+key
      certfile: "/etc/ssl/mycert/pokedex.crt+key"
     
      protocol_options:
        - "no_sslv2"
        - "no_sslv3"
        - "cipher_server_preference"

      ciphers: "ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM"

      # Parametres DH. Pas avant ejabberd 15.06 qui n'est pas dans Debian Jessie
      # J'utilise des parametres de 4096 bits car en accord avec la taille
      # de la cle utilise dans mon certificat x509
      dhfile: "/etc/ejabberd/ssl/dh_4096.pem"

    [...]

    # s2s (pas de bloc specifique)

    # TLS est obligatoire entre deux serveurs XMPP. Attention, beaucoup de
    # serveurs XMPP ne supportent pas TLS (exemple : Google) donc ça peut
    # empecher de parler a des contacts. On peut mettre la valeur a optional
    # dans ce cas
    s2s_use_starttls: required

    # Voir la remarque ci-dessus pour certfile
    s2s_certfile: "/etc/ssl/mycert/pokedex.crt+key"

    # Voir la remarque ci-dessus pour protocol_options
    s2s_protocol_options:
      - "no_sslv2"
      - "no_sslv3"
      - "cipher_server_preference"

    s2s_ciphers: "ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM"

    # Voir la remarque ci-dessus pour dhfile
    s2s_dhfile: "/etc/ejabberd/ssl/dh_4096.pem"




Postfix :

ÉDIT DU 20/06/2020 : cette configuration est erronée. Voir la nouvelle ici : http://shaarli.guiguishow.info/?m68qkQ . FIN DE L'ÉDIT.

    # TLS - serveur
    smtpd_tls_security_level = may

    # On n'accepte pas d'auth si pas de TLS
    smtpd_tls_auth_only = yes

    smtpd_tls_cert_file = /etc/postfix/ssl/pokedex.crt
    smtpd_tls_dcert_file = $smtpd_tls_cert_file
    smtpd_tls_key_file = /etc/postfix/ssl/pokedex.key
    smtpd_tls_dkey_file = $smtpd_tls_key_file

    smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

    smtpd_tls_protocols = !SSLv2, !SSLv3

    smtpd_tls_mandatory_ciphers = medium
    tls_medium_cipherlist = ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    smtpd_tls_exclude_ciphers = aNULL, eNULL, EXP, RC4, 3DES, MD5, LOW
    tls_preempt_cipherlist = yes

    # Parametres DH. Oui, 1024 -> 4096 ... ça vient de la doc Postfix
    # J'utilise des parametres de 4096 bits car en accord avec la taille
    # de la cle utilise dans mon certificat x509
    smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dh_4096.pem

    # Cache partages des sessions TLS (expire au bout d'une heure par defaut)
    smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_tls_cache

    smtpd_tls_loglevel = 1


    # TLS - client
    smtp_tls_security_level = $smtpd_tls_security_level

    smtp_tls_cert_file = $smtpd_tls_cert_file
    smtp_tls_dcert_file = $smtpd_tls_dcert_file
    smtp_tls_key_file = $smtpd_tls_key_file
    smtp_tls_dkey_file = $smtpd_tls_dkey_file

    smtp_tls_CAfile = $smtpd_tls_CAfile

    smtp_tls_protocols = $smtpd_tls_protocols

    smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
    smtp_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers

    # Cache partages des sessions TLS (expire au bout d'une heure par defaut)
    smtp_tls_session_cache_database = btree:${data_directory}/smtp_tls_cache

    smtp_tls_loglevel = $smtpd_tls_loglevel




Quelques précisions :
    - Oui, je ne me fais pas chier avec une liste de ciphers longue comme le bras car c'est, àmha, trop chiant à maintenir pour un gain de sécurité pas évident du tout à mesurer par rapport à utiliser les groupements OpenSSL (ou GnuTLS, c'est bien pareil) et à exclure quelques suites d'algos. Du coup, je vire simplement les algos pourris (RC4, 3DES, MD5, ceux classés en LOW dans OpenSSL) ou inexistants (aNULL, eNULL) et j'utilise les algos classés comme HIGH puis comme MEDIUM. L'ordre sera celui du serveur : le client prendra la suite d'algos la plus forte qu'il supporte.

    - Vu que j'ai un seul certificat x509 par machine, les /etc/<logiciel_serveur_>/ssl/lala.(crt|key) sont des liens symboliques vers /etc/ssl/mycert/ . Factorisation toussa.

    - Oui, je ne fais pas encore le chaînage des certificats pour fournir une chaîne de confiance complète à mes visiteurs, c'est sur ma TODO pour le prochain renew des certificats.

    - Rappel des valeurs par défaut dans mes confs c'est juste pour m'en souvenir / retrouver facilement.