Compatibilité avec Android 4.1?

Bonjour,

Je souhaiterais savoir si yunohost est toujours compatible avec Android 4.1? Car mon serveur est injoignable avec cette version. Je crois me rappeler que j’avais passé il y a quelques temps la commande:

yunohost settings set security.nginx.compatibility -v modern

Par contre, je ne vois pas le rapport avec le mail, ceux-ci n’étant plus accessible sur ce téléphone. Y aurait-il malgré tout un rapport avec cette commande ou est-ce un renforcement de la sécurité sur Yunohost depuis les derniers mois?
L’application Nextcloud version android quant à elle fonctionne toujours mais pas la synchronisation du calendrier et des contacts.

Pour que l’on puisse t’aider il faudrait d’abord nous dire les messages que tu vois et qui te font conclure que ton serveur est “injoignale” ou “plus accessible”

Le client mail du téléphone renvoie:
"Impossible de se connecter au serveur"
L’ajout d’un nouveau compte renvoie:
"Impossible d'établir une connexion sécurisée avec le serveur. (java;net;ssl;SSLProtocolException: SSL handshake aborted: ssl=0x5cb26470: Failure in SSL library, usually a protocol error error:1407742E:SSL routines: SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version (external/openssl/ssl/s23_clnt.c:741 0x51450876:0x00000000))

Je sais que android 4.1 n’est pas compatible avec les versions de TLS supérieure à 1.0. Vu que le problème est apparu visiblement vers la mi-mai, je me demande si cela viendrait de certaines modifications que j’aurais pu effectuer dont la commande citée car je m’étais renseigné sur TLS à ce moment là, ou si c’est Yunohost lors d’une mise à jour qui a abandonné le support de TLS 1.0.

Effectivement la configuration Nginx a bougé dans la version 3.8 pour se mettre à jour avec la recommendation de Mozilla, qui du coup ne supporte plus TLS 1.0 et 1.1 mais seulement 1.2 (et bientot 1.3 une fois sous Buster) : https://github.com/YunoHost/yunohost/commit/f390f02077294cc1033977601071ba242da4bf85#diff-e308ce3a5afb0cee6fef77ccb3388a00

Ok pour Nginx mais pour les mails c’est Postfix, du coup ça ne devrait pas intervenir, sauf si la configuration de postfix a également été mise à jour.

Est-ce risqué de repasser sur une ancienne version avec les sauvegardes des conf. se trouvant dans /home/yunohost.conf/backup/ afin de pouvoir continuer à utiliser le smartphone avec le serveur?

Sinon une chose qui m’interpelle concernant la sécurité: l’application Nextcloud du téléphone accède bien au serveur. La sécurité serait moindre pour Nextcloud sur yunohost par rapport aux mails ou les accès web?

Oui la configuration pour les mails (en l’occurence dovecot, pas postfix, si l’on parle du relevé des mails par un client mail) a été mise à jour. Je ne conseille pas de remettre une ancienne conf mais plutôt de modifier la conf actuelle pour réactiver TLS1.0 / 1.1 si c’est ça le soucis.

Mouébof il peut y’avoir milles explications, ptete que ton client nextcloud embarque sa propre librairie de crypto et arrive à faire du TLS1.2 … M’enfin c’est de la spéculation, faudrait vraiment creuser pour savoir comment ça marche.

1 Like

Le souci semble bien venir de là, du coup pas trop le choix si je souhaite que le possesseur de ce téléphone puisse continuer à utiliser le serveur, je pense suivre tes recommandations.
Cependant, est-ce vraiment très risqué d’abaisser la sécurité des connexions SSL de la sorte? Est-ce que ça met le serveur Yunohost en danger?

Je ne sais pas trop quoi modifier pour la synchro contacts/calendrier de Nextcloud, as-tu une idée de quel fichier de conf s’agit-il? Pour Dovecot, c’est bon j’ai trouvé, plus qu’à faire le test dès que j’ai accès au téléphone en question.

C’est bon, j’ai eu accès au téléphone ce soir, ça fonctionne pour le mail (dovecot). Et si j’ai bien compris les autres utilisateurs continuent à utiliser du TLSv1.2 si ils le peuvent.
Par contre pour l’agenda Nextcloud en Webdav je ne sais pas où regarder. Est-ce du côté de Nginx? Ou ailleurs?

Logiquement pour l’agenda c’est nginx effectivement

Merci @ljf, je vais donc voir du côté de Nginx et faire comme pour dovecot.
Je ne voudrais pas faire de bêtises, peux-tu me confirmer que j’ai bien compris et que ça fonctionne comme je le pense ci-dessous? :
“Les connexions utilisent le protocole le plus haut si il est disponible et seul TLS1.0 sera utilisé par ce téléphone si j’ajoute son support dans la config Nginx. Du coup, la sécurité du serveur n’est pas compromise, seules les connexions de ce client sont fragilisées.”
Est-ce bien ça? Le risque est-il vraiment important pour ce client?

C’est un peu pénible ces évolutions qui ne sont pas/plus supportées alors que le téléphone est encore entièrement fonctionnel par ailleurs. Je ne comprends pas pourquoi ces évolutions ne sont pas portées sur des anciennes versions d’Android avec une mise à jour, hormis le fait de vouloir faire de l’obsolescence programmée et obliger à renouveler le matériel.

Oui c’est à peu près ça. Des mises à jour, il y en a. Sauf que les revendeurs de téléphones (ou bien genre opérateurs genre orange etc.) aiment bien mettre une surcouche à la con pleine de bloatware, et généralement la disponibilité des mises à jour est dépendante de leur bon vouloir. Donc pas d’upgrade. Donc obsolète quelques années plus tard car incompatible avec des trucs récents.

Cette pratique (ne pas permettre la mise à jour) devrait être rendu illégale compte tenu de l’impact écologique que ça a … Ou bien à l’inverse : pleins d’acteurs importants (genre banque, etc…) continuent de supporter des protocoles de sécurités connus pour être vulnérable juste parce que trop de gens ont encore des vieux trucs qu’ils peuvent pas mettre à jour.

1 Like

Le trucs c’est qu’il n’est pas exclue qu’il existe des techniques pour downgrade un client qui supporte TLS1.3 vers TLS1.0 si TLS1.0 est activé sur le serveur. C’est typiquement l’attaque POODLE qui fait ça (dans un contexte man in the middle, donc avec un wifi ouvert type bar ou alors ton opérateur réseau ou l’état avec les boites noires (peu probable mais c’est possible)).

Donc je dirais OUI activer un protocole plus faible côté serveur fait descendre la sécu même pour les dispositifs supportant aussi le protocole fort. C’est justement le problème des banques décrit par Aleks.

TLS1.0 a des failles de sécurité comme les failles BEAST, CRIME et d’autres qui peuvent aboutir au déchiffrement de tout ou partie de la communication. La plupart (toutes?) nécessitent en général d’être en position man in the middle, certaines avec la possibilité d’injecter des données dans le flux du client par un autre biais.
En général TLS1.0 est quand même assez sûr à moins d’avoir une personne qui veut vraiment déchiffrée ta communication ou se faire passer pour le serveur avec lequel tu communiques.

Plus d’info: Examples of TLS/SSL Vulnerabilities TLS Security 6: | Acunetix
Précision je ne travaille pas dans la sécurité, donc c’est juste un point de vue très partiel.

1 Like

Peut-être partiel mais suffisamment clair pour être abordable par les personnes comme moi qui s’intéressent mais ne maîtrisent absolument pas ces notions de sécurité. Je suppose que c’est le cas de beaucoup d’utilisateurs qui se tournent vers Yunohost justement pour pouvoir bénéficier d’une solution “clef en main” et pouvoir s’auto-héberger malgré tout.

Il s’agit d’un serveur familial et les connexions au serveur ne se font jamais à travers un wifi public, du coup je pèse le pour et le contre entre interdire l’accès à l’utilisateur et l’obliger à changer le téléphone s’il veut continuer à utiliser les services, ou activer TLS1.0. Je choisi la seconde solution en connaissance de cause. Malheureusement je perd les mises à jour automatiques pour Yunohost avec cette modification, dommage qu’il ne soit pas possible de l’activer avec par exemple une commande telle que:

yunohost settings set security.nginx.compatibility -v old 

Je me contenterai de forcer la mise à jour à chaque fois et de refaire les modifications manuellement.

Merci à tous les 2 pour la solution et vos explications. :slightly_smiling_face:

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.