Erreurs SSL/TLS sur les très vieux navigateurs se connectant à Discourse

Soutien
1

Après avoir configuré mon instance Discourse avec le support Let’s Encrypt par défaut, j’ai reçu des rapports de certains de mes utilisateurs indiquant que leur navigateur ne parvient pas à établir une connexion sécurisée vers Discourse. Une capture d’écran que j’ai reçue d’un utilisateur pointe clairement vers une erreur SSL/TLS. Il s’agit d’une erreur côté navigateur, et les utilisateurs ne voient même rien provenant de Discourse.

Au vu du contexte, ces utilisateurs semblent avoir des systèmes d’exploitation ou des navigateurs quelque peu anciens. J’ai d’abord soupçonné que le support de TLS 1.2 était en cause, mais l’utilisateur que j’ai vérifié utilise Safari 10.1.2 sur macOS (version inconnue) et, selon Can I use... Support tables for HTML5, CSS3, etc, Safari devrait prendre en charge TLS 1.2 depuis la version 7.

Existe-t-il une autre raison, autre que TLS 1.2, qui pourrait amener un navigateur ou un système d’exploitation à échouer lors de l’établissement d’une connexion sécurisée vers une installation Discourse par défaut utilisant le support TLS par défaut via Let’s Encrypt ? J’essaie de déterminer quelles questions poser à mes utilisateurs pour identifier leur problème et savoir de quel côté la correction doit être apportée.

En solution de contournement : À ma connaissance, la configuration par défaut consiste à rediriger le trafic vers http vers https. Existe-t-il un moyen d’effectuer une vérification préalable, quelque chose comme « uniquement si le navigateur prend en charge TLS 1.2 » ou « uniquement si le navigateur/le système d’exploitation est supérieur à une certaine version », sinon rester sur http ?

Voici l’URL, au cas où vous auriez une idée pour vérifier si quelque chose est mal configuré : https://forum.stadtteilgenossenschaft-wik.de

2

Vous pouvez tester votre site en utilisant le Test du serveur SSL. Les résultats du test contiennent une section nommée « Simulation de poignée de main » qui devrait vous indiquer les combinaisons navigateur/système d’exploitation qui fonctionnent ou non.

Avec la dernière image Docker, je constate la configuration TLS suivante :

image
image1035×597 26.1 KB

image
image1039×1060 95.2 KB

Vous pouvez envoyer vos utilisateurs sur https://www.ssllabs.com/ssltest/viewMyClient.html pour obtenir plus d’informations sur leurs versions de navigateur et de système d’exploitation, ainsi que sur les versions TLS prises en charge.

3

Merci pour cette réponse détaillée !

J’ai lancé le test SSL Server et je ne trouve rien d’anormal dans les résultats :

Ils sont identiques à ceux de votre publication, à ce que je vois.

Les seules échecs concernent les anciennes versions de Safari (8 et 9) sur des systèmes d’exploitation obsolètes, ainsi que les anciennes versions de Windows avec IE 11. Ce dernier point m’inquiète un peu : IE 11 ne devrait-il pas être pris en charge par Discourse et supporter TLS 1.2 par défaut ?

Le test ne semble pas inclure de test pour Safari 10 sur le système d’exploitation le plus ancien encore pris en charge, il est donc possible que cela échoue également…

4

Pour les utilisateurs sur d’anciennes versions de Windows, vous devrez probablement activer les chiffrements CBC :

image
image792×252 60 KB

La prochaine chose à faire est d’envoyer ces utilisateurs à

pour obtenir des informations sur ce que leur navigateur prend en charge. Le moyen le plus simple de partager leur résultat est probablement de leur demander d’imprimer en PDF et de vous l’envoyer.

5

Merci, j’ai eu une réponse de mon utilisateur. Il utilise un très vieil iPod Touch :

Capacités SSL/TLS de votre navigateur
User Agent : Mozilla/5.0 (iPod; CPU iPhone OS 6_1_6 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B500 Safari/8536.25

Prise en charge des protocoles

Votre agent utilisateur a une bonne prise en charge des protocoles.

Votre agent utilisateur prend en charge TLS 1.2, qui est la version de protocole recommandée pour le moment.

Donc, même si c’est ancien (et je sais que cela est loin du système d’exploitation et du navigateur minimum pris en charge par Discourse), j’aimerais au moins lui permettre de se connecter au site et de voir comment son navigateur gère le HTML et le JavaScript modernes.

Voici le rapport détaillé sur la prise en charge de TLS :

Fonctionnalités des protocoles

130×100 755 Bytes

Protocoles

TLS 1.3 Non
TLS 1.2 Oui
TLS 1.1 Oui
TLS 1.0 Oui
SSL 3 Oui
SSL 2 Non

130×100 709 Bytes

Suites de chiffrement (par ordre de préférence)

TLS_EMPTY_RENEGOTIATION_INFO_SCSV ( 0xff ) -
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ( 0xc024 ) FAIBLE 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ( 0xc023 ) FAIBLE 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ( 0xc00a ) FAIBLE 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ( 0xc009 ) FAIBLE 128
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA ( 0xc007 ) INSECURE 128
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ( 0xc008 ) FAIBLE 112
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ( 0xc028 ) FAIBLE 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ( 0xc027 ) FAIBLE 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ( 0xc014 ) FAIBLE 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ( 0xc013 ) FAIBLE 128
TLS_ECDHE_RSA_WITH_RC4_128_SHA ( 0xc011 ) INSECURE 128
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ( 0xc012 ) FAIBLE 112
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 ( 0xc026 ) FAIBLE 256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 ( 0xc025 ) FAIBLE 128
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 ( 0xc02a ) FAIBLE 256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 ( 0xc029 ) FAIBLE 128
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA ( 0xc004 ) FAIBLE 128
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA ( 0xc005 ) FAIBLE 256
TLS_ECDH_ECDSA_WITH_RC4_128_SHA ( 0xc002 ) INSECURE 128
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ( 0xc003 ) FAIBLE 112
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA ( 0xc00e ) FAIBLE 128
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA ( 0xc00f ) FAIBLE 256
TLS_ECDH_RSA_WITH_RC4_128_SHA ( 0xc00c ) INSECURE 128
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA ( 0xc00d ) FAIBLE 112
TLS_RSA_WITH_AES_256_CBC_SHA256 ( 0x3d ) FAIBLE 256
TLS_RSA_WITH_AES_128_CBC_SHA256 ( 0x3c ) FAIBLE 128
TLS_RSA_WITH_AES_128_CBC_SHA ( 0x2f ) FAIBLE 128
TLS_RSA_WITH_RC4_128_SHA ( 0x5 ) INSECURE 128
TLS_RSA_WITH_RC4_128_MD5 ( 0x4 ) INSECURE 128
TLS_RSA_WITH_AES_256_CBC_SHA ( 0x35 ) FAIBLE 256
TLS_RSA_WITH_3DES_EDE_CBC_SHA ( 0xa ) FAIBLE 112
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 ( 0x67 ) FAIBLE 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 ( 0x6b ) FAIBLE 256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA ( 0x33 ) FAIBLE 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA ( 0x39 ) FAIBLE 256
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA ( 0x16 ) FAIBLE 112
TLS_ECDHE_ECDSA_WITH_NULL_SHA ( 0xc006 ) INSECURE 0
TLS_ECDHE_RSA_WITH_NULL_SHA ( 0xc010 ) INSECURE 0
TLS_ECDH_ECDSA_WITH_NULL_SHA ( 0xc001 ) INSECURE 0
TLS_ECDH_RSA_WITH_NULL_SHA ( 0xc00b ) INSECURE 0
TLS_RSA_WITH_NULL_SHA256 ( 0x3b ) INSECURE 0
TLS_RSA_WITH_NULL_SHA ( 0x2 ) INSECURE 0
TLS_RSA_WITH_NULL_MD5 ( 0x1 ) INSECURE 0
(1) Lorsqu’un navigateur prend en charge SSL 2, ses suites spécifiques à SSL 2 ne sont affichées que lors de la toute première connexion à ce site. Pour voir les suites, fermez toutes les fenêtres du navigateur, puis ouvrez directement cette page exacte. Ne rafraîchissez pas.

130×100 511 Bytes

Détails du protocole

Indication du nom de serveur (SNI) Oui
Renégociation sécurisée Oui
Compression TLS Non
Billets de session Non
Épinglage OCSP Non
Algorithmes de signature SHA384/RSA, SHA256/RSA, SHA1/RSA, SHA256/ECDSA, SHA1/ECDSA
Groupes nommés secp256r1, secp384r1, secp521r1
Négociation du prochain protocole Non
Négociation du protocole de la couche application Non
Compatibilité de la poignée de main SSL 2 Non

Gestion du contenu mixte

130×100 529 Bytes

Tests de contenu mixte
Images Passif Oui
CSS Actif Oui
Scripts Actif Oui
XMLHttpRequest Actif Oui
WebSockets Actif Oui
Frames Actif Oui
(1) Ces tests peuvent provoquer un avertissement de contenu mixte dans votre navigateur. C’est normal.
(2) Si vous voyez un test échoué, essayez de recharger la page. Si l’erreur persiste, veuillez nous contacter.

Désolé pour le formatage, l’utilisateur a copié-collé le code HTML du texte enrichi pour moi et une partie se perd lors du collage dans Discourse. Je vais essayer de trouver comment corriger le formatage plus tard.

Comme je l’ai dit, j’aimerais lui permettre d’établir au moins une connexion sécurisée afin qu’il puisse voir quelque chose, et cela devrait être possible puisque le navigateur prend en charge TLS 1.2. Mais je suppose que je devrais activer une configuration moins sécurisée pour TLS 1.2 afin que son navigateur soit pris en charge. Je ne connais pas assez les détails de TLS pour faire correspondre la sortie de ce rapport à ce que le serveur prend en charge et ce que je devrais modifier. Pouvez-vous me dire ce qui manque et ce que je devrais changer ?

6

J’ai une vague idée de ce que vous voulez dire, mais je ne sais pas comment faire. Pouvez-vous m’orienter vers une documentation qui explique comment modifier la configuration TLS du conteneur Docker de Discourse pour activer ceux-ci ?

7

Je ne pense pas que Safari 6 fonctionnera, même si vous résolvez les problèmes TLS en ajoutant des suites de chiffrement supplémentaires.

Vous pouvez ajouter les suites de chiffrement manquantes en remplaçant le fichier de configuration nginx. Ajoutez l’extrait suivant (non testé, mais il devrait fonctionner) dans la section hooks de app.yml et modifiez la valeur de ssl_ciphers selon vos préférences.

  after_ssl:
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /ssl_ciphers .*/
        to: ssl_ciphers <votre_liste_complète_de_chiffrement>;

Au passage : j’essaie d’ajouter la prise en charge des certificats à courbes elliptiques à Discourse, ce qui le rendrait compatible avec IE11 dès la sortie de la boîte.

8

iOS 6 ?! La dernière version de celle-ci a été publiée au début de l’année 2014 ! Cela remonte à plus de 5 ans !

9

Je sais, j’étais aussi surpris que vous. Je ne m’attends pas à ce que vous le supportiez, mais j’aimerais que l’utilisateur obtienne au moins un peu de HTML et voie ce qui fonctionne et ce qui ne fonctionne pas.

10

Merci @gerhard, j’ai apporté la modification que vous avez décrite à /var/discourse/containers/app.yml (j’espère qu’il s’agissait du bon fichier app.yml), puis j’ai exécuté /var/discourse/launcher rebuild app comme indiqué dans les commentaires de app.yml.

J’ai ensuite relancé le test sur ssllabs.com, mais il semble que le résultat n’ait pas changé : https://www.ssllabs.com/ssltest/analyze.html?d=forum.stadtteilgenossenschaft-wik.de&s=68.183.214.228&hideResults=on

Je ne sais pas comment vérifier si la modification de configuration a réellement fonctionné (mais elle n’a pas influencé le résultat du test) ou si la modification de configuration n’a pas fonctionné.

11

Oh, je n’ai pas bien lu votre message, @gerhard. Si je comprends bien, la configuration que vous avez fournie rend les chiffrements utilisés explicites, mais la valeur que vous avez employée est essentiellement la même que celle par défaut, n’est-ce pas ? Je devrais donc tout de même l’étendre avec d’autres chiffrements susceptibles d’être pris en charge par les navigateurs plus anciens.

12

Oui, exactement. Je ne voulais pas publier de solution pour ajouter des chiffrements faibles à la configuration. Vous devrez régler cela vous-même. :wink:

Mais si vous apportez ces modifications, surveillez la pull request que j’ai mentionnée plus tôt. Si elle est fusionnée, IE11 fonctionnera immédiatement sans configuration supplémentaire.

13

Je vois, vous ne voulez pas rendre trop facile pour quelqu’un de rendre sa configuration non sécurisée. Je le respecte et je ne posterai pas non plus le code complet.

Voici ce que j’ai trouvé jusqu’à présent : j’ai identifié les suites de chiffrement manquantes pour prendre en charge les anciens navigateurs/systèmes d’exploitation en consultant par exemple Qualys SSL Labs - Projects / User Agent Capabilities: Safari 6 / iOS 6.0.1 (et pour les autres également). Comme les suites de chiffrement du client sont listées par ordre de préférence, j’ai simplement toujours choisi la première et m’assuré de la prendre en charge, en supposant que si le serveur prend en charge l’une de la liste, cela devrait suffire. Voici les chiffrements que j’ai identifiés :

  • ECDHE-ECDSA-AES256-CBC-SHA384 pour Safari 6-8
  • ECDHE-RSA-AES256-CBC-SHA384 pour IE 11 sur Win 7/8.1/Phone 8.1 Update (selon @supermathie)
  • ECDHE-RSA-AES128-CBC-SHA256 pour IE 11 sur Win Phone 8.1

J’ai pris ces valeurs et les ai ajoutées à la fin de la liste des ssl_ciphers, séparées par des deux-points, en supposant que « fin de la liste » signifie « moins préférée, ne sera utilisée que si le client ne prend en charge rien d’autre ». J’ai ensuite exécuté /var/discourse/launcher rebuild app pour appliquer la nouvelle configuration et relancé le test sur SSL Server Test (Powered by Qualys SSL Labs) après avoir vidé le cache. Mais les résultats n’ont pas changé.

Je m’attendais à ce que cela fonctionne maintenant aussi bien pour les tests IE 11 échoués que pour Safari 6-8, mais l’établissement de la connexion échoue toujours. Je dois donc manquer quelque chose.

De plus, l’un de mes utilisateurs utilise un iPhone avec iOS 9/Safari 9 et pour eux, la connexion échoue également. Mais selon les résultats des tests de SSL Labs, cette connexion devrait déjà fonctionner par défaut (comme le montre également le résultat de @gerhard ci-dessus).

Je dois donc manquer deux choses :

  1. Pourquoi la connexion ne fonctionne-t-elle toujours pas après avoir ajouté le support des chiffrements ?
  2. Pourquoi SSL Labs indique-t-il que cela fonctionne pour iOS 9 + Safari 9 alors que cela ne fonctionne pas réellement pour mon utilisateur ?

Concernant le point 1 : je ne suis toujours pas sûr d’avoir appliqué la configuration correctement. Outre le test SSL Labs, existe-t-il une autre méthode pour vérifier les chiffrements pris en charge par le serveur afin de voir si ma modification de configuration a bien été appliquée correctement ?

14

Après avoir examiné de plus près les résultats de SSLLab, je pense que cela ne fonctionne pas.

Voici le résultat que je vois sur SSLLabs pour mon serveur après avoir appliqué la configuration et reconstruit :

33
331730×234 48.1 KB

À ma connaissance, il devrait en lister beaucoup plus, car la configuration contient de nombreuses options supplémentaires. Cela signifie-t-il que ce changement de configuration n’a pas fonctionné ?

15

Je pense que les noms des chiffrements que vous avez choisis sont incorrects. Mapping OpenSSL cipher suite names to IANA names est une excellente ressource pour faire correspondre les chiffrements listés par le test SSL Server aux noms utilisés par OpenSSL (nginx).

Dans mes tests, j’ai ajouté :ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA et, après une reconstruction, le test ressemble à ceci :

image
image955×362 15.3 KB

image
image899×1270 114 KB

Peut-être y a-t-il un bug dans le test ? :man_shrugging: Je n’ai pas une version aussi ancienne de Safari pour tester. Nous ne prenons en charge que Safari 10 et supérieur. Êtes-vous certain que l’échec est toujours dû à une erreur TLS ?

16

Merci, je vais essayer ça !

J’ai examiné un peu plus les fichiers de configuration de Discourse et j’ai trouvé templates/web.ssl.template.yml. Quelle est la différence entre apporter ce changement aux chiffrements via le fichier app.yml et modifier directement la liste des ssl_ciphers dans templates/web.ssl.template.yml ?

17

Le modèle est sous contrôle de version, tandis que le fichier app.yml ne l’est pas. Vous rencontrerez des problèmes lors de la mise à jour du dépôt si vous modifiez le modèle.

18

Merci, c’était bien le problème. Corriger les noms permet à la poignée de main de fonctionner pour tous les navigateurs testés dans la liste de SSLLabs. Merci beaucoup pour votre patience !

Maintenant, je suis curieux de savoir ce que voient mes utilisateurs une fois qu’ils ont dépassé l’erreur HTTPS avec leurs anciens navigateurs. :smiley: