Ph Husson a écrit 2699 commentaires

Oula malheureux, surtout pas !
Si tu fais ça, un attaquant peut faire le distingo entre 0000000000 et 6632056564 parce que le premier prendra moins de place que le second. Y a eu une attaque publiée récemment, pas mal de services sécurisés ont désactivé la compression suite à ça.

Après, quelque soit l'algo de compression tu risques d'avoir le problème, mais un algo qui fait compression + chiffrement sans donner trop d'infos ça parait complexe

En fait, d'un côté je suis d'accord
D'un autre, si un attaquant fait du MITM avec un certificat non certifié, tu vas dire à l'utilisateur "c'est bon c'est presque safe" ?
Si on en est arrivé à ces messages d'erreurs ignobles, c'est bien parce que PEBKAC…

Je suis pas chez F-Droid, donc je peux être à côté de la plaque, mais:

Cette application promeut des extensions privatrices

Pour moi ça fait référence au marketplace Firefox, qui effectivement, littéralement, promeut des extensions non-libres.
Maintenant, la question est plutôt de savoir si c'est pertinent ou non de l'afficher. (moi je trouve ça plutôt bien, bien qu'un peu violent (mais c'est le but du terme "privateur"))

Cette application épie et rapporte votre activité

J'avoue que celle là me fait ticker…
Potentiellement elle fait référence aux bookmarks centralisés ?
Ou alors au fait que le simple fait d'avoir un navigateur web, fait que les sites webs en face peuvent t'identifier ?

Sinon, pourquoi forcement CyanogenMod ?
CyanogenMod est une des ROMs alternatives les moins libres à l'heure actuelle ! (https://plus.google.com/+GuillaumeLesniak/posts/L8FJkrcahPs est assez convaincant pour en tout cas ne pas vouloir rester chez eux)
Ok elle a pas les applis Google, mais c'est plus par problème légal que par volonté politique.

Du coup on transfert le problème de CA à .com en fait ?

C'est pour ça que tu peux (en fait sur https://www.bortzmeyer.org/7469.html c'est marqué DOIT) mettre plusieurs certificats.
Un mois avant l'expiration, tu rajoute ton nouveau certificat, que t'utilise pas encore, et le jour de l'expiration tu changes de certificat, et c'est bon.

Je me suis déjà demandé comment se déploie DNSSEC, cette fois je me suis motivé à sortir mon wikipedia adoré:

La clé peut être récupérée via le DNS lui-même (ce qui pose un problème d'œuf et de poule) ou bien par un autre moyen (diffusée via le Web et signée avec PGP par exemple).

et

Contrairement à d'autres protocoles comme SSL, il ne sécurise pas juste un canal de communication mais il protège les données, les enregistrements DNS, de bout en bout.

J'en déduis que pour chaque site que je visite il faut que je le whitelist ?

Ça parait trop aberrant, donc ça doit être autre chose. Il a une notion de CA ?

Et du coup il y a même problème de pining au niveau de DNSSEC, soit c'est piné par le client, soit ça utilise un CA ?
Et comment est géré le MITM qui supprime les enregistrements DNSSEC ?
On fait confiance au cache des DNS, donc il faut systématiquement un serveur DNS local à la machine ?

Ils datent d'avant la première release des coeurs ARM armv8.
Wikipedia me dit qu'il est même basé sur un cortex-a50, qui n'a jamais existé publiquement.

(pour ceux qui auraient la flemme de faire le calcul, à fréquence et nombre de coeurs égaux, en supposant que les tests sont en turbo speed, ça fait 15%, sinon, 25%)

Le X-gene n'est pas un coeur ARM, il n'a que les instructions ARM.
C'est comme dire que intel c'est pourri, parce que un via en x86 est nul. (sauf que les instructions ARM sont à ARM et les x86 pas à intel, soit)

Nan mais ferme-là : MS a inventé le système qui permet de bloquer les autres OS, et se permet de faire une exception sur un segment sur lequel il est en situation de monopole depuis 20 ans… et tu veux qu'on les remercie de cette exception ? Juste ta gueule.

Tellement, que le terme consacré à cette discussion est la tivoisation
Et l'interdiction de booter d'autres OS, c'est bien les x86 à être les dernier à le permettre !
Toutes les autres architectures ont pu le faire bien avant de l'x86…

En JS/web, j'ai déjà parsé des fichiers .zip de 700Mo (ok pas encore 1Go), qui contenaient des boot.img (format d'encapsulation kernel + initramfs venant d'Android), initramfs qui contient des fichiers init.rc, et ait analysé ces-dits init.rc (entre autre hein, j'analyse plein de trucs dans le .zip)
Avec des temps de travail tout à fait raisonnables comparé à l'équivalent en script shell (qui utilise unzip et autres outils prévus pour).
Par contre effectivement, fallait au moins 4Go de RAM de dispo… (assez probablement parce que je sais pas coder en JS, le fichier est pas censé être chargé en entier en mémoire)

Sinon la notion du "web" fait que les calculs/accès sont principalement cachés (aux sens hidden et cached) côté serveur. Pour la recherche dans mes mails, j'ai pas réussi à trouver mieux que gmail…
Vu comme ça, y a que les cas où:
- ton desktop est une bête de course, et tu veux faire des calculs peu parallélisables
- tu as de gros fichiers locaux à gérer

Où le web ne peut pas gagner.
Tout le reste (notifications, push, UI, intégration, etc.) n'est qu'une question d'API disponible, et avance à grands pas. cf les modifs de Chrome 42 par exemple, même si celles là sont plus pour les mobiles, elles permettent qu'une appli Web ait les même capacités qu'une appli Android "normale"

CyanogenMod les empêche d’accéder aux contacts ou à la localisation par exemple (en demandant à chaque fois ou en activant/désactivant définitivement).

Comme n'importe quelle ROM Android, même les ROM stocks avec les applis root quivontbien©, pas besoin d'être sectaire.

Et de toutes façon faut commencer par essayer de faire sauter le clavier Androïd, qui a accès à toutes les données, contacts, fichiers, géolocalisation … normal pour un clavier …

L'appli clavier que j'utilise (Minuum), mais je suppose qu'ils sont tous plus ou moins pareil, il a besoin de:
- voir les contacts (normal pour être capable de reconnaître les noms des personnes…)
- accéder à internet. C'est discutable, mais il faut bien qu'il mette à jour ses dictionnaires
- accéder aux mots du dictionnaire
- accéder à la carte SD j'imagine que c'est pour stocker ses données

Je vois rien de bien scandaleux là dedans…
Il n'accède pas à ma localisation, et probablement pas aux fichiers. (hélas Android était mal fait, et pour question de rétrocompatibilité la permission reste…).
Évidemment ça ne donne aucune garantie sur ce qu'il fait de ce qu'il arrive à récolter, mais stop la parano. (ok c'est la mauvaise news pour ça)

Est-ce que savoir où est stocké jquery est important ?
(Ok on peut vouloir rajouter des signatures de sécurité.)
Les vraies données, le contenu, restent chez toi.

J'y connais pas grand chose en CDN, mais cloudflare ?

Alors, pour ce genre de problèmes, y a une solution assez universelle, qui est le CDN.
Tu pourrais mettre tout ton site derrière un CDN, mais je suppose que dans le cadre de l'auto-hébergement, tu ne souhaites pas le faire.
Tu peux au moins le faire pour certains morceaux.
Tu dis que une page "sans rien" fait 66ko… Ça matche pas ma description de "rien".
Si parmi ces 66ko, tu as des bibliothèques bien connues (entre autre tu mentionnes jquery), tu peux utiliser des CDNs publiques pour ces bibliothèques ! (cf https://code.jquery.com/ ou https://developers.google.com/speed/libraries/devguide )
Tu pourrais aussi imaginer utiliser un CDN pour tes images (je crois que imageshack le fait ?)

Déjà, c'est une connexion par répertoire surveillé. Ensuite, mon expérience avec IDLE sur quelques clients mails que j'ai pu tester, c'est qu'ils relancent des synchro régulières, parce qu'ils sont vraiment pas sûrs de la connexion. (y a pas de keep-alive sur l'idle?)

Sinon le WiFi sans activité ça consomme plus rien de nos jours (mais ça consomme plus quand y a de l'activité). Par contre pour le GPS ça m'étonne, en général ça tire beaucoup. Genre t'enregistre ta position en continue pendant 2 jours ?

Pour info, cette fonctionnalité est apparue dans Android 4.3 et disparue dans 4.4.2 et s'appel(ait) appops.
Potentiellement ils l'ont enlevé, parce qu'en l'état elle est très loin d'être user-friendly (mais dans ce cas ils l'auraient amélioré plutôt que de l'enlever je pense..)

Certains constructeurs (mediatek entre autre) l'ont laissé, mais l'expérience utilisateur est vraiment mauvaise.
Potentiellement, elle est meilleure sur Cyanogen.

Ça pour le coup, je le mets pas vraiment dans les fonctionnalités qui font que F-Droid rend le tout plus sûr, à moins que ce soit détecté automatiquement
Mais ça reste une fonctionnalité intéressante

Faut faire confiance à F-Droid ;-)

Plus sérieusement, quel travail font-ils précisément ?
Ils recompilent eux-même le code ?

À moins que t'ai une preuve qu'au moment où t'as installé l'appli, elle n'était pas corrompue, la différence n'est pas énorme.

Après, ça dépend de contre quel type d'attaques t'essaie de te défendre. Je t'avoue que dans ce genre de discussions, je suppose qu'on est en mode parano absolu et qu'on veut se protéger des gouvernements. Par contre, contre des petits hackers qui veulent juste se faire de l'argent, effectivement le problème est plus présent.

Par contre, ces services gèrent le OAuth, donc ont tous une authentification révocable, limitée au mail, et aucunement lié au mot de passe. (mais ils conservent effectivement tes mails)

Le problème existe aussi pour k9-mail, du moins celui que tu pointes:

Il pointe vers le playstore, donc le binaire.

En gros, tu dis qu'une appli de gestion de mails, a accès… à tes mails ?

Bon, sans troll, ton problème c'est qu'ils stockent les mots de passes chez eux.
Mais pour moi, que les mots de passes soient effectivement stockés dans leur cloud ou non ne change pas grand chose,
Le jour où une appli se fait corrompre, l'attaquant à juste à rajouter 3 lignes de code qui forwardent les identifiants vers l'attaquant. Elle se fera mettre à jour toute seule comme une grande par le Play Store, et voilà, l'attaquant a tout les mots de passes.

Le problème existe aussi pour k9-mail, du moins celui que tu pointes:
Même s'il est opensource et le code source est vérifié, rien ne prouve que le binaire ne corresponde.
Et même s'il correspond à un instant t, ça sera pas forcement le cas de la prochaine mise à jour.

De ce que je comprends, son besoin c'est d'avoir accès direct au bus usb ou sdio lui-même, sans intermédiaire.

Je sais pas si c'est très courant, mais aucun téléphone Archos n'a de bootloader verrouillé à ma connaissance.
Certains ont même un bootloader opensource (et pour les autres j'ai surtout pas cherché.)
Après, c'est le bootloader application, pas radio, mais vu qu'on parle de Linux, c'est bon.

Et les smartphones ont des propriétés intéressantes (compactes, sur batterie, prévu pour consommer peu), qui font qu'avec une bonne plateforme ils pourraient être utilisés pour des hacks.

Sinon, un article qui parle de tout ça va quand même faire 15km…