Bonjour Math.hdr.
Et merci de ton intérêt pour
1fichierfs.
Réponse courte : oui !.. ('tout chiffrer" est le comportement par défaut)
Protocoles https pour tout ce qui est en http (appels à l'API et lecture des fichiers), et ftp sécurisé pour tout ce qui est ftp (upload/ quand tu écris sur le montage).
1fichierfs utilise exactement les mêmes accès que ce que tu ferais "à la main" en téléchargeant tes fichiers avec ton navigateur et en uploadant avec ftp (filezilla par exemple).
Réponse longue :
- les appels à l'API sont TOUJOURS chiffrés car l'API fonctionne exclusivement en https.
- pour les accès aux fichiers, en réalité cela dépend...
de ce que tu veux toi !..
Développons...
Le mode
"par défaut" chez 1fichier.com est d'utiliser https, c'est à dire une communication chiffrée. Cependant le chiffrement a un impact sur les performances. Par exemple, sur mon Raspberry Pi 4, je peux faire du 100Mo/s en http non chiffré, mais je plafonne à 45 ou 50Mo/s en https (chiffré). Donc pour des raisons de performance, l'utilisateur peut avoir envie de ne rien chiffrer du tout.
Pour cela il existe un
paramètre global dans ton interface web sur 1fichier.com, à la rubrique "Paramètres" qui s'appelle "Forcer le téléchargement non SSL".
Si tu coches ce paramètre, tous les liens présentés par 1fichier seront en http simple et donc non chiffrés, que tu utilises simplement ton navigateur sur l'interface de 1fichier.com, ou que tu utilises 1fichierfs.
Ce paramètre s'applique à
TOUT ton stockage puisqu'il est géré au niveau du serveur.
Si tu crains d'être en "non chiffré", vérifie bien que tu n'as pas coché cette case !..
Ensuite il peut y avoir d'autres cas où tu n'as pas besoin du chiffrement. Dans mon cas par exemple, j'ai certains fichiers "personnels" qui sont stockés sur mon compte et ils sont chiffrés à partir de mon PC avec
encfs.
encfs est monté "par dessus"
1fichierfs, et ça marche parfaitement !.. Plus amusant, dans la partie chiffrée j'ai des ISO, je peux aussi les monter par simple clic, donc "empiler" 1fichierfs/encfs/montage_ISO... De la sorte ce qui est stocké sur la partie géré par encfs est un fichier déjà chiffré, et le nom du fichier est également chiffré. Ainsi, le fournisseur de stockage (DStorage/1fichier.com) ne peut pas voir ce qu'il y a dans mes fichiers. Il voit juste des fichiers avec des noms étranges contenant des suites d'octets sans signification. Cela prévient une fuite chez le fournisseur : employé indélicat, failles ou attaques du fournisseur, injonction d'organismes officiel de communiquer des fichiers, etc...
Comme ces fichiers sont déjà chiffrés en contenu et en nom, il devient alors inutile d'utiliser https pour ces fichiers là puisque cela ferait du "double chiffrement". On ne fait que perdre de la performance.
Plus simplement tu peux avoir des fichiers qui n'ont pas besoin d'être chiffrés, comme par exemple si tu stockes des images ISO des tes distributions Linux favorites (fichiers totalement publics !).
Pour gérer ces deux cas (et sans doute d'autres) il existe une façon de dire à 1fcihierfs de ne pas chiffrer
seulement pour certains répertoires (et leurs descendants).
Il s'agit de l'option
--no-ssl
Tu peux consulter le manuel qui est inclus dans le package pour cette option :
$ man 1fichierfs
(...)
--no-ssl=chemin
Par défaut, les téléchargements se font avec ou sans SSL/TLS selon le réglage no_ssl de chaque fichier individuel. Indépendamment de ces réglages, spécifier cette option force la désactiva‐
tion de SSL/TLS pour toute l'arborescence sous chemin. Utiliser cette option évite d'avoir à régler individuellement le paramètre no_ssl de chacun des fichiers de toute l'arborescence sous
chemin.
Cette option peut apparaître plusieurs fois pour spécifier différents chemins.
Usage typique : quand les fichiers et noms de fichiers sont déjà chiffrés, lorsqu'une machine peu puissante est utilisée et que SSL/TLS est lent (au détriment de la sécurité/vie privée).
Exemple pratique, tu as
- Un répertoire où sont stockés des fichiers déjà chiffrés : Crypt
- Un répertoire où sont stockés des fichiers complètement publics (ISO d'Ubuntu !) : Public
Tu peux alors lancer 1fichierfs avec
1fichierfs --api-key="ta_clé_api" /path/to/mountpoint --no-ssl=/Crypt --no-ssl=/Public
Ainsi, tout sera chiffré sauf le contenu des deux répertoires ci-dessus (et de leurs éventuels sous répertoires de façon récurrente).
Signalons aussi pour être complet qu'on peut changer l'attribut SSL au niveau de chaque fichier... au travers de l'API, mais je n'ai pas trouvé la façon de le faire via l'interface web standard.
Donc si tu as mis "no-ssl" sur certains fichiers en appelant l'API qui convient (toi-même, car 1fichierfs ne se permet pas de changer cet attribut du fichier !), ces fichiers là seront bien en no-ssl (non chiffrés) qu'ils aient été spécifiés sur la ligne de commande 1fichierfs ou pas, à l'image du non-chiffrement global par le paramètre "Forcer le téléchargement non SSL".
En complément, l'
upload (tu peux aussi "écrire" sur ton montage, avec les limitations classique indiquées dans le manuel !) se fait toujours en FTP
sécurisé, sauf pour les répertoires que tu as explicitement déclarés en --no-ssl
Dans ce dernier cas, la non-sécurisation concerne bien sûr uniquement la partie "données" du fichier, le préambule de connexion à FTP est lui toujours chiffré, sinon on pourrait voir ta clé d'API en clair !..
Résumé :
En espérant que ces explications sont claires... tu peux retenir la réponse "oui",
si tu as bien vérifié que tu n'avais pas coché "Forcer le téléchargement non SSL" dans les paramètres de ton compte !..
P.S.: merci pour la question, je vais clarifier le manuel car mentionner l'option no_ssl au niveau de chaque fichier n'est pas le plus essentiel car faisable uniquement si l'utilisateur est déjà familier avec l'API !.. Il vaut donc mieux que je mentionne le "paramètre global". Je vais aussi rajouter un bref mot sur l'upload, car le texte date de l'époque où l'écriture n'était pas encore développée.
