Bravo tu as gagné le commentaire le plus bas du front et populiste de la journée.
Le cas Apple vs FBI est une affaire complexe, la réduire à ta remarque est d’un simplisme digne d’un enfant.
Apple ne demande pas de ne pas être soumis aux lois, il conteste le fait de devoir torpiller ses propres produits et donc son business-model sous couvert d’une loi qui est interprétée de manière exagérément large dans un contexte totalement différent de l’époque où elle a été écrite.
Apple a déjà plusieurs fois collaborer avec les autorités pour rendre disponible des informations nécéssaires à une enquête et dont elle disposait sur ses servers.
Non malheureusement, ça ne marchera clairement pas dans tous les cas et encore moins sur les iPhone. Il ne faut pas lire tout ce qui traine partout sur le net.
Le dispositif de déverrouillage de l’iPhone demande obligatoirement d’entrer le code de déverrouillage si pas de déverrouillage du téléphone depuis 48h. Hors lors d’une interpellation, d’une GAV ou plus généralement d’une enquête judiciaire (si mort), les données du téléphone ne sont pas la priorité immédiate et ne parviennent aux enquêteurs spécialisés que plusieurs jours après. Donc l’empreinte digitale ne sert plus à rien, il faut obligatoirement rentrer à la main de code de déverouillage. Dans le cas d’une personne morte, on voit que c’est fini pour l’enquête sur un iPhone. Et dans le cas d’un Gardé à vue, s’il est bien conseillé par son avocat il ne donnera pas son code, ce qui est une défense totalement recevable.
Telegram a un protocole de chiffrement maison très très critiqué par la communauté des cryptographes. De ce que j’ai lu, on parle de code assez mal pensé et qui pourrait poser des problèmes à moyen terme.
Je ne l’utiliserai pas personnellement.
Je ne suis pas persuadé qu’avoir un logiciel qui tourne sur toutes les plateformes soit un bon point niveau sécurité. les OS étant très différents et les bibliothèques difficilement transposables, je crois que c’est plus du chipotage qu’autre chose.
Je pense que des softs différents sur mobile et Desktop serait de loin préférable pour le côté sécurité à l’heure actuelle.
Si TU ne sais pas utiliser des finderprint c’est TON problème. Par contre évite de dire que le fait que personne ne les vérifie rend le système peu fiables pour ceux qui savent l’utiliser … :p
Google n’a pas la clé vu qu’elle est stockée chiffrée (AES) sur le téléphone à l’aide du mot de passe de déverrouillage. Quand bien même Google aurait la clé chiffrée que ça ne lui servirait pas à grand chose non plus.
Le
21/10/2015 à
10h
28
Pour les appareils ne disposant pas de puce dédiée pour le traitement de AES oui le proco doit faire ça lui-même.
Bien pour ça que ce n’est OBLIGATOIRE et AUTOMATIQUE pour Android 6.0 QUE sur les appareils disposant de cette puce qui permet d’être totalement fluide.
Les autres doivent l’activer volontairement “à la main” et assument les conséquences en cas de ralentissements.
-FAI : nous on chiffre vos mails avec vos/nos clefs privées qu'on remettra aux Renseignements dès le premier coup de téléphone.
- Michu : OK, je suis rassuré.
Non encore une fois il y a erreur sur ce que vous comprenez :
- chiffrer un mail = chiffrement du contenu = chiffrement de bout en bout.
- ici on parle de chiffrement de la couche de transport = chiffrement du flux via TLS.
Donc, il n’y a aucun mensonge, ni tentative de faire croire que les mails sont protégés des agences gouvernementales ou de la justice. La charte essaye juste de mettre en place plusieurs pratiques de sécurité de base en 2015, notament le chiffrement des flux entre les machines.
(Il y a en réalité d’autres points abordés dans la charte …)
Le
05/10/2015 à
18h
40
CryoGen a écrit :
En tout cas c’est bien que l’état veuille avancer dans le chiffrement… moi je propose d’ajouter le chiffrement (client) dans le chiffrement (transport) comme çà plus aucune interception de possible " />, responsabilité claire etc. " />
Même si c’est vrai qu’ils ne vont pas se tirer une balle dans le pied en le mettant en place, en imaginant même que ce soit possible politiquement, ça sera une toute autre chose de déployer le chiffrement sur le contenu (bout en bout) que sur le transport (TLS).
Même si un opérateur décidait de l’intégrer dans son webmail, le chiffrement de bout en bout automatique ne serait en place qu’entre correspondants de la même plateforme de mail. L’interopérabilité du chiffrement de bout en bout Mr/Mme Michu compatible est loin d’être techniquement faisable à l’heure actuelle … :)
Le
05/10/2015 à
14h
29
On en est à la 5e page de HS … et surement 10-12 commentaires RÉELLEMENT sur le sujet …
Allo la modération ?
Le
05/10/2015 à
12h
41
ledufakademy a écrit :
C’est pour cela qu’ils (quasi tous les acteurs : états et boites) poussent pour que vous foutiez TOUS vos données sur un cloud … et pas chez vous sur un NAS !!!!
" /> " /> " />
Heu tu dis un pue n’importe quoi. Il n’y a aucun incitation des pouvoirs publiques à mettre tes données sur le Cloud …
C’est juste que l’informatique, telle que développée par les techos eux-mêmes, est juste très compliquée à gérer en décentralisé et beaucoup plus simple à laisser administrer par des autorités centralisées …
Y voir une connivence ou un dessein longtemps préparé ou calculé est une affabulation totale. Les institutions publiques qui veulent se servir de nos données ont juste profité de la centralisation HISTORIQUE des dites-données …
Le
05/10/2015 à
12h
37
Ça n’est en rien de sa responsabilité, ni son affaire …
Il essaye au moins de rendre effectif le chiffrement des FLUX entre gros opérateurs de mail. Ce qui en 2105 me semble en effet être un minimum.
Je ne vois pas trop le sens de ton post. Il n’est ni pour, ni contre le chiffrement de bout en bout. Disons même que l’ANSI recommande même son utilisation dans certains cas et notamment dans certains domaines professionnels. Donc beaucoup de gens ici font un mauvais procès à cette proposition.
De toute façon, le chiffrement de bout en bout “bien fait”, c’est UNIQUEMENT la responsabilité des utilisateurs finaux … Les fournisseurs de solution mail n’ont rien à voir la dedans et encore moins les autorités publiques …
P.S.: Ca ne dérrange que moi les 20 derniers comms totalement HS par rapport à la News ???
Le
05/10/2015 à
10h
29
le TLS bashing n’a strictement aucun sens. Et je soupçonne ceux qui le font de ne pas bien comprendre tout l’intérêt qu’il peut y avoir dans le déploiement automatique du chiffrement des flux.
Il n’y a aucun sens de parler de backdoor étant donné qu’on ne crée pas une porte dérobée volontaire, on utilise simplement le fonctionnement normal du chiffrement TLS pour déchiffrer en local les flux qui arrivent chez les opérateurs.
Il n’empêche que même si TLS, dans le cas des emails chez de gros opérateurs centralisés, peut permettre à des services de renseigment/justice français d’avoir accès aux flux en clair, il est de toute façon préférable de déployer de chiffrment de flux pour prévenir les oreilles indiscrètes de nombreux autres acteurs qui en veulent à notre vie privée !
Cessez d’être manichéens. C’est un bon pas en avant. Celui qui crache sur le chiffrement de flux TLS et qui ne chiffre pas de bout en bout son contenu n’est qu’un troll …
Heu chers amis @sscrit et @Haemy , le cracking ne se fait plus en ligne depuis très longetmps. Le cracking se fait chez soi après avoir récupéré la base de données (hashée + salée). Les sites ont depuis longtemps mis en place des solutions qui bloquent le compte après X tentatives. Et essayer un mdp par compte par jour prendrait probablement des millions d’années pour tomber sur des mots de passe un tant soit peu complexe …
Le
14/09/2015 à
17h
13
mouais t’as augmenter ton charset size mais t’es quand même à max 8 caractères … :p
Le
14/09/2015 à
16h
19
Bannockh a écrit :
Je vois pas l’interêt des majuscules/minuscule/accent/etc…. Pour un ordi ca reste un caractère donc ca ne rajoute aucune protection contre un ordi un tant soit peu puissant. Par contre plus c’est long, plus c’est bon ….
C’est des maths tout simplement, je t’explique :
L’ensemble des mots de passes contenant uniquement des minuscules est bien plus petit que l’ensemble des mots de passes contenant des minuscules+Majuscules+chiffres+symboles. Un calcul par force brute est donc en terme de probabilité plus compliqué sur l’ensemble le plus gros …
Sans parler du fait que faire varier les types de caractères permet également de réduire la menace des attaques par dictionnaire.
Autre information importante :
UN GESTIONNAIRE DE MOTS DE PASSE EST OBLIGATOIRE EN 2015 !
Si tu pouvais demander pour moi quand est-ce qu’ils comptent passer à Apache 2.4 ? Et aussi s’ils bossent pour intégrer la nouvelle CA Let’s Encrypt ? Merci :p
En tout cas ils l’utilisent de manière qu’il n’est pas possible d’envoyer des emails en PGP standard, il faut obligatoirement passer par leur interface web pour la personne recevant le mail (au lieu de simplement envoyer la clé publique et de déchiffrer le message).
Je viens de tester et j’ai très bien pu m’envoyer à moi et à d’autres un mail chiffré PGP via Thunderbird+Enigmail sur des adresses @protonmail. Donc oui ils utilisent bien du OpenPGP standard. Il faut juste envoyer en inline message plutôt qu’en PGP/MIME. :)
Le
24/08/2015 à
16h
09
Anthodev a écrit :
La limitation principale de ProtonMail reste le non support d’OpenPGP standard. Ils ont une implémentation perso qui empêche d’envoyer des emails au format PGP à d’autres adresses de services utilisant OpenPGP normal.
Ils n’ont toujours pas répondu sur la possibilité de passer par OpenGPG standard au lieu de leur implémentation (ce qui fait que seul les mails entre utilisateurs de ProtonMail sont chiffrés). Il est possible d’exporter la clé publique de son compte ProtonMail mais ce n’est pas utile si on ne peut pas envoyer les mails en PGP (et non en ProtonMail PGP)
Je pense qu’il doit y avoir confusion quelque part. ProtonMail utilise bien du OpenPGP standard. Juste ils n’ont pas encore implémenté la gestion des clés manuellement pas les utilisateurs, y compris de sa propré clé privée.
En gros c’est comme si t’avais un GPG verouillé sur ton PC mais derrière il esst faux de dire que c’est un format PGP différent des autres … C’est bien du OpenPGP standard.
Je constate juste qu’il y a de nombreuses failles et qu’au final, la techno des NAS n’est pas encore mature.
Ce sont des produits qui à mes yeux sont arrivés trop tôt et qui doivent encore corriger plusieurs problèmes importants de sécurité avant d’être exploitables.
(surtout que si je m’en sers, ce ne sera pas pour stocker des données à la con)
Tu devrais vraiment ne parler que sur des choses que tu connais. Tu ne te rends pas compte j’imagine mais tu viens de te ridiculiser !
Les NAS existent depuis de très nombreuses années et ont prouvé leur utilité dans certaines configurations précises.
Après venir dire que parce qu’on corrige des failles sur des logiciels libres, c’est une preuve de non-maturité …. encore une preuve que tu caricatures et méconnais grandement le sujet.
Dire que El capitan supporte des becanes de 2008 c’est pas être fanboy, c’est juste décrire la réalité …
Si t’as un problème avec ça, il existe des établissements adaptés qui te permettront d’arrêter de projeter sur les autres. :)
Liste officielle Apple :
iMac 2007 ou plus récent
· MacBook Air 2008 ou plus récent
· MacBook 2008 ou plus récent
· Mac mini 2009 ou plus récent
· MacBook Pro de mi/fin 2007 ou plus récent
· Mac Pro 2008 ou plus récent
· Xserve 2009 ou plus récent
Le
13/07/2015 à
16h
54
t’as pas remarqué que tu mélanges plusieurs postes peut-être ??? Je n’ai absolument aucun Mac Pro …
Le
13/07/2015 à
16h
34
Tu mélanges vraiment tout et n’importe quoi … t’essayes de tirer dans toutes les directions pour avoir raison on dirait …
1) Ta phrase initiale sous-entendait qu’un Mac de 2011 ramerait sous 10.11 … ce qui est une connerie monumentale … pour l’avoir installé sur mon iMac de 2008, ça tourne comme une horloge !
2) Tu dis Microsoft supporte encore Vista et Seven … Je te signale qu’Apple continue encore de supporter ces anciens système étant donné qu’ils continuent à bénéficier de mises à jour de sécurité. (Apple vient même de pousser une Maj du “Mathusalemiem” Java 6 par exemple … )
Le prix n’a strictement rien à voir dans ton post initial … tu parlais de pousser à racheter du matos en poussant à l’obsolescence … Apple fait du premium, ça sera toujours plus cher sans forcément avoir plus ! Tout le monde le sait normalement aujourd’hui non … ?
4) Y’a aucun besoin de changer une pièce d’origine pour passer à El Capitan …
(J’ai hate que tu répondes pour voir comment tu continues à creuser … " />
)
Le
13/07/2015 à
08h
45
merphémort a écrit :
Pour Metal j’ai envie de te dire que c’était prévisible quand même avec un HD3000 (d’ailleurs maintenant que tu mets le doigt dessus Apple a publié une liste des Mac compatibles ou bien?…), et si (connaissant Apple) ton MacBook de 2011 a déjà droit à EL Capitan sans gros bugs ou problèmes de perfs ce sera déjà pas mal va " />
Tu connais très mal le support des versions de OS X on dirait et tu continues les stéréotypes sur Apple à ce sujet …
El Capitan supportent des macs jusqu’à 2008 donc bon venir dire qu’Apple pousse à racheter du nouveau matos via ses OS c’est quand même une belle fumisterie …
Il n’y a pas de chiffrement par défaut et obligatoire sur openfire. Donc on n’est pas vraiment dans le même domaine …
Le
24/06/2015 à
11h
25
heu non …
Un, le client complet est dispo sur Github : GitHub
Deux, le client est une application complète qui intègre le protocole miniLock et qui gère aussi le gestion des contacts et les envoies des messages et des fichiers chiffrés.
Il vaut peut-être mieux essayer un soft avant de le commenter :p
Le
24/06/2015 à
08h
23
Il n’existe actuellement aucune solution aussi complète et aussi simple d’utilisation avec code dipsonible pour le client et le server. Ici le code client est au moins disponible et Les développeurs s’étaient engagés à publier du code server dans le futur.
Je tiens à te signaler que c’est toi qui a commencé avec le ad hominem : Il n’est pire aveugle que celui qui ne veut pas voir…
Sinon toujours aucun argument crédible selon moi, comme le dit @k43l, quelques secondes (dans le pire des cas !!!) est très peu visible par des gens n’ayant pas des exigences comme toi.
Et pour avoir une connexion THD et une bonne machine, venir dire qu’il y a une gène sur la différence entre une connexion HTTP et HTTPS même sur du 100Mbps … me semble particulièrement subjective.
Et allons au fond des choses, si on laisse le choix comme tu le veux, ça veut dire qu’on laisse le HTTP par défaut sur la majorité des sites (donc non sensibles à TES yeux). Donc que 90% des utilisateurs n’essaieront même pas s’il y a du HTTPS vu qu’ils ne s’y connaissent pas assez souvent pour comprendre la différence entre les deux. Donc pour gagner quelques milisecondes chez beaucoup de gens aujourd’hui. Ta solution finit par casser un processus de protection de la vie privée qu’on tend à généraliser parce que tu veux gagner 2% de temps sur une connexion.
Le
17/06/2015 à
08h
35
Ho mais je vais répondre, pas de chance je m’y connais bien en TLS … " />
Il n’y a aucun avantage sur les petites connexions à l’heure où tu l’as dit toi-même, dans les pays occidentaux et “développées”, l’immense majorité des gens ont des machines dotées de puces pour AES (ordis & iphones) et où les machines non-pourves ont des suites de chiffrement très rapides aussi (CHACHA20-POLY1305) sur les smartphones sous Android par exemple.
On faisait du SSL à l’époque du 56K et ça ne posait pas de problème particuliers non plus, au pire ça rajoute quelques secondes pour des connexions anémiques dans les pays en voie de développement.
Pour la consommation des machines, là aussi, tu ne vas pas au bout de ton raisonnement parce que si tu retires les machines dotées de puces dédiées (on doit être dans une grosse majorité des machines accédeant au net aujourd’hui dans les pays développés) et vu que la puce ne consomme quasiment rien à côté du processeur, beaucoup d’études ont montré que TLS était un vrai coût négligeable côté client. En réalité un PC moyen aujourd’hui est capable d’agir en tant que server et de chiffrer plusieurs milliers de connexions TLS par seconde. Par pitié évitons de faire croire que TLS bouffe des tonnes, c’est juste une blague.
Le
17/06/2015 à
08h
16
la généralisation du HTTPS ce n’est en rien de la sécurité aveugle ! Ca permet simplement de ne pas permettre aux intermédiaires techniques de savoir ce que l’on consulte sur un site particulier. Et sur un site comme Wikipedia, je pense que c’est plutôt indispensable à l’heure du tracking permanent.
Je ne vois aucun avantage pour le particulier aux connexions sans TLS non désolé. Pour les très grosses boites c’est surement un allègmement (léger en réalité vu le très faible cout en ressource de TLS aujourd’hui !) d’une partie de la charge server.
Le
17/06/2015 à
08h
06
Alors pour la millième fois dans les comms : Il n’y a pas de limite légale à la taille des cléfs. Que ce soit en Europe ou aux USA en tout cas.
Mouais. DKIM ça sert mieux pour lutter contre le phishing que contre le SPAM. Je connais des boites de SPAM qui ont du DKIM installé sur leurs servers. C’est pas très compliqué et ça passe partout. Les grosses boites qui font du SPAM s’y sont mis depuis un moment …
Le
02/06/2015 à
13h
20
Vser a écrit :
Ce n’est pas tant pour y donner de la publicité mais pour que nxi l’utilise lors de l’envoi de mail.
Déjà qu’ils veulent pas mettre du TLS sur la consultation du site (ce qui est ultra simple à faire vie Cloudflare chez qui ils sont clients ) … t’es pas près de voir des mails chiffrés avec GPG …
Le
02/06/2015 à
09h
10
90% de la population utilisant internet n’est pas foutue de se créer un mot de passe correct.
Vous voulez leur faire utiliser un mécanisme qui demande l’utilisation d’une phrase de passe et qui demande de gérer de manière sécurisée le stockage d’une clé privée ?! Revenez sur terre. PGP/GPG est destiné à une toute petite tranche de la population et le restera encore de nombreuses décennies.
La seule solution est d’apprendre à gérer une phrase de passe. Cette étape est faisable. A partir de là on peut utiliser des système de chiffrement asymétrique avec dérivation des clés via une phrase de passe. Si vous voulez vraiment faire gérer localement une clé privée c’est déjà mort pour une énorme majorité de gens.
le lecteur multimedia de la mini 4k est tout bonnement merdique pour l’instant. Il ne prend pas en charge le son multupistes (adieu AC3, DTS, DTS-HD, etc …), il ne lit pas certains sous-titres, et la liste est longue.
En gros il lit assez peu de fichiers …
Produit pas fini comme à son habitude avec Free !
Pour avoir testé sur le mon NAS Synology (DSM 5.2 mis à jour), je peux vous annoncer que le server web n’est pas tuché par la faille logjam mais que le server mail lui l’est vu qu’il accepte les suites de chiffrement Export avec DHE.
Si vous voulez testez par vous-même, il existe cette commande pour openssl :
J’espère que tout ce qui est “vieux” dans TLS va disparaitre pour http2. Cela serait dommage d’avoir des algo pourris dés le début, alors que l’on change la base de communication.
Vous m’avez mal compris en plus. Retirer DHE ne signifie certainement pas ne plus être compatible avec des anciens clients. (D’ailleurs si on parle vraiment de vieux client, ceux sous Windows XP notamment, DHE n’est presque pas supporté non plus donc bon … ) Supprimer DHE signifie juste rendre les clients les plus récents compatible uniquement avec ECDHE (et donc voir sur du plus long terme).
Rien n’empêche, et c’est ce que tout le monde fait d’ailleurs, moi y compris, de laisser RSA en fin de list de ciphersuites pour toujours rester accessible aux “vieux clients”.
Les GAFA sont une toute autre question, pour certains ils développent carrément un navigateur à eux et quasi tous ont des bibliothèquent TLS patchées avec des modifs maison …
Le
20/05/2015 à
14h
25
des boites qui ont des millions de clients sur le net on en compte 1000 dans le monde entier à tout casser, et je doute que les seniors chargés de la sécu informatique postent des comms sur NXi … " />
Donc non, mon commentaire ne se destinait pas aux sys admins de Amazon, Paypal, Google, Apple, etc … " />
Le
20/05/2015 à
14h
23
Pourtant si le site ne supporte plus du tout DHE, tu devrais avoir ce message :
Good News! This site is safe from the Logjam attack. It
supports ECDHE, and does not use DHE.
Le
20/05/2015 à
14h
14
Edtech a écrit :
Au taff :
C’est rare qu’on soit au point ! Etrangement, c’est le seul serveur géré par un collègue développeur et pas par le sys admin " />
On est carrément en ECDHE !
Le mieux est encore de retirer DHE complètement et de ne laisser que ECDHE. Ca permet d’avoir le top actuellement et de n’être compatible qu’avec des clients modernes et récents (plus souvent mis à jour).
il faut activer le javascript pour naviguer sur le site. C’est la raison pour laquelle votre page est blanche.
Qwant Team
Non toutes les pages blanches que je vois c’est lorsque les cookies sont désactivés.
Que les utilisateurs inscrits aient besoin des cookies pour stocker les réglages d’accord, mais que les viviteurs occasionnels non-inscrits et n’ayant touché à aucun réglage doivent obligatoirement accepter les cookies sur le site est un problème sur mon choix à protéger ma vie privée.
Le
14/04/2015 à
16h
35
je connais des sites de recherche qui permettent de faire des recherches sans AUCUN cookie et ça marche très bien. Donc selon moi, pour un site qui met en avant la protection de la vie privée, je pense qu’il serait évidemment souhaitable qu’une recherche sans cookie soit évidemment posssible !
Le
14/04/2015 à
16h
19
Suis-je le seul à avoir une page blanche sur ce site si je désactive les cookies sur mon navigateur ?
Pour un moteur de recherche qui dit respecter nos données et notre vie privée … c’est plutôt cocasse !
Ben visiblement tu es donc soit un peu naïf, soit assez mauvais sur le plan technique pour gober si facilement le baratin de comm du gouvernement et du raporteur du texte …
Et tu as bien parlé de ne se contenter QUE des metadonnées, ce qui est évidemment faux ce qui est juste de la propagande pour faire passer la pilule du DPI (non contrôlable puisque boite noire avec algo non publique … )
Le
10/04/2015 à
13h
33
carbier a écrit :
Je crois que tu confonds beaucoup de choses dans le projet de loi.
Les boites noires ne s’intéressent “qu’“aux méta-données et encore elles feront le tri sur place et n’enverront que les données de connexion en concordance avec ce qui est surveillé.
Ce sont ces méta données de connexion qui seront ensuite analysées plus profondément pour savoir s’il s’agit d’un faux positif ou d’une vraie tendance.
Et c’est seulement après que l’arsenal de la pêche aux infos de contenu sera engagée sur des “cibles” bien définies.
Je ne dis pas que c’est bien, juste que les gens ont l’impression que la totalité de ce qu’ils consultent / publient / envoient sera analysée en permanence… Et cela, je ne suis même pas sur que la NSA sache le faire, alors la France…
Je crois que tu n’as pas lu le texte, pas suivi les débats en commission, ni bien compris l’intention de cette loi.
Plusieurs fois les intervenants pour ce texte ont bien parlé de savoir quelles étaient les URL consultées en temps réels dans l’infrastructure des FAI via les boites noires. Or pour connaître les URL il faut évidemment aller plus loin que les méta-données. Les URL font partie du contenu d’un paquet. Il n’y a aucun besoin d’une URL pour router les paquets entre les routeurs.
On parle donc bien ici de DPI dans les boites noires donc d’analyse de contenu sur l’ensemble des communications. avec tout ce que cela entraine …
Quand on dit qu’elles sont là, elles sont donc réputées sûres et, par corolaire, ne sont plus probables.
Je ne sais pas les autres mais moi je ne comprends pas ta phrase. Le dev c’est pas de la philo. Essaye d’objectiver tes propos.
Le
08/04/2015 à
10h
19
Certaines failles sont parfois théoriquement possibles mais extrêmement difficiles à mettre en place en réalité. Donc l’existence d’une faille ne veut pas forcément toujours dire que la menace est réellement applicable. C’est pour ça que les failles ne sont pas considérées comme majeures.
607 commentaires
iPhone verrouillé : un juge new-yorkais donne raison à Apple
01/03/2016
Le 01/03/2016 à 13h 24
Bravo tu as gagné le commentaire le plus bas du front et populiste de la journée.
Le cas Apple vs FBI est une affaire complexe, la réduire à ta remarque est d’un simplisme digne d’un enfant.
Apple ne demande pas de ne pas être soumis aux lois, il conteste le fait de devoir torpiller ses propres produits et donc son business-model sous couvert d’une loi qui est interprétée de manière exagérément large dans un contexte totalement différent de l’époque où elle a été écrite.
Apple a déjà plusieurs fois collaborer avec les autorités pour rendre disponible des informations nécéssaires à une enquête et dont elle disposait sur ses servers.
Deux députés s’attaquent au chiffrement
01/03/2016
Le 01/03/2016 à 11h 43
Non malheureusement, ça ne marchera clairement pas dans tous les cas et encore moins sur les iPhone. Il ne faut pas lire tout ce qui traine partout sur le net.
Le dispositif de déverrouillage de l’iPhone demande obligatoirement d’entrer le code de déverrouillage si pas de déverrouillage du téléphone depuis 48h. Hors lors d’une interpellation, d’une GAV ou plus généralement d’une enquête judiciaire (si mort), les données du téléphone ne sont pas la priorité immédiate et ne parviennent aux enquêteurs spécialisés que plusieurs jours après. Donc l’empreinte digitale ne sert plus à rien, il faut obligatoirement rentrer à la main de code de déverouillage. Dans le cas d’une personne morte, on voit que c’est fini pour l’enquête sur un iPhone. Et dans le cas d’un Gardé à vue, s’il est bien conseillé par son avocat il ne donnera pas son code, ce qui est une défense totalement recevable.
Telegram : 100 millions d’utilisateurs, une version 3.6 pour Android et iOS
24/02/2016
Le 25/02/2016 à 11h 10
Telegram a un protocole de chiffrement maison très très critiqué par la communauté des cryptographes. De ce que j’ai lu, on parle de code assez mal pensé et qui pourrait poser des problèmes à moyen terme.
Je ne l’utiliserai pas personnellement.
Je ne suis pas persuadé qu’avoir un logiciel qui tourne sur toutes les plateformes soit un bon point niveau sécurité. les OS étant très différents et les bibliothèques difficilement transposables, je crois que c’est plus du chipotage qu’autre chose.
Je pense que des softs différents sur mobile et Desktop serait de loin préférable pour le côté sécurité à l’heure actuelle.
Tor lance son propre Messenger, basé sur le client InstantBird de Mozilla
30/10/2015
Le 30/10/2015 à 11h 47
avec Tor + OTR il n’y a plus de dichotomie du tout vu qu’il y a anonymisation pour le contexte et vie privée (chiffrement) sur le contenu ! :)
Certificats SSL gratuits : Let’s Encrypt avance bien, une bêta publique le mois prochain
22/10/2015
Le 22/10/2015 à 21h 55
Si TU ne sais pas utiliser des finderprint c’est TON problème. Par contre évite de dire que le fait que personne ne les vérifie rend le système peu fiables pour ceux qui savent l’utiliser … :p
Android 6.0 : le chiffrement intégral obligatoire sur les appareils assez puissants
21/10/2015
Le 21/10/2015 à 22h 58
Google n’a pas la clé vu qu’elle est stockée chiffrée (AES) sur le téléphone à l’aide du mot de passe de déverrouillage. Quand bien même Google aurait la clé chiffrée que ça ne lui servirait pas à grand chose non plus.
Le 21/10/2015 à 10h 28
Pour les appareils ne disposant pas de puce dédiée pour le traitement de AES oui le proco doit faire ça lui-même.
Bien pour ça que ce n’est OBLIGATOIRE et AUTOMATIQUE pour Android 6.0 QUE sur les appareils disposant de cette puce qui permet d’être totalement fluide.
Les autres doivent l’activer volontairement “à la main” et assument les conséquences en cas de ralentissements.
Une charte avec les FAI français pour le chiffrement des flux emails
05/10/2015
Le 05/10/2015 à 20h 54
Le 05/10/2015 à 18h 40
Le 05/10/2015 à 14h 29
On en est à la 5e page de HS … et surement 10-12 commentaires RÉELLEMENT sur le sujet …
Allo la modération ?
Le 05/10/2015 à 12h 41
Le 05/10/2015 à 12h 37
Ça n’est en rien de sa responsabilité, ni son affaire …
Il essaye au moins de rendre effectif le chiffrement des FLUX entre gros opérateurs de mail. Ce qui en 2105 me semble en effet être un minimum.
Je ne vois pas trop le sens de ton post. Il n’est ni pour, ni contre le chiffrement de bout en bout. Disons même que l’ANSI recommande même son utilisation dans certains cas et notamment dans certains domaines professionnels. Donc beaucoup de gens ici font un mauvais procès à cette proposition.
De toute façon, le chiffrement de bout en bout “bien fait”, c’est UNIQUEMENT la responsabilité des utilisateurs finaux … Les fournisseurs de solution mail n’ont rien à voir la dedans et encore moins les autorités publiques …
P.S.: Ca ne dérrange que moi les 20 derniers comms totalement HS par rapport à la News ???
Le 05/10/2015 à 10h 29
le TLS bashing n’a strictement aucun sens. Et je soupçonne ceux qui le font de ne pas bien comprendre tout l’intérêt qu’il peut y avoir dans le déploiement automatique du chiffrement des flux.
Il n’y a aucun sens de parler de backdoor étant donné qu’on ne crée pas une porte dérobée volontaire, on utilise simplement le fonctionnement normal du chiffrement TLS pour déchiffrer en local les flux qui arrivent chez les opérateurs.
Il n’empêche que même si TLS, dans le cas des emails chez de gros opérateurs centralisés, peut permettre à des services de renseigment/justice français d’avoir accès aux flux en clair, il est de toute façon préférable de déployer de chiffrment de flux pour prévenir les oreilles indiscrètes de nombreux autres acteurs qui en veulent à notre vie privée !
Cessez d’être manichéens. C’est un bon pas en avant. Celui qui crache sur le chiffrement de flux TLS et qui ne chiffre pas de bout en bout son contenu n’est qu’un troll …
Ashley Madison : les mots de passe navrants de banalité
14/09/2015
Le 14/09/2015 à 18h 30
Heu chers amis @sscrit et @Haemy , le cracking ne se fait plus en ligne depuis très longetmps. Le cracking se fait chez soi après avoir récupéré la base de données (hashée + salée). Les sites ont depuis longtemps mis en place des solutions qui bloquent le compte après X tentatives. Et essayer un mdp par compte par jour prendrait probablement des millions d’années pour tomber sur des mots de passe un tant soit peu complexe …
Le 14/09/2015 à 17h 13
mouais t’as augmenter ton charset size mais t’es quand même à max 8 caractères … :p
Le 14/09/2015 à 16h 19
Synology : nouvelle mise à jour de sécurité Update 4 pour le DSM 5.2
08/09/2015
Le 08/09/2015 à 11h 50
Si tu pouvais demander pour moi quand est-ce qu’ils comptent passer à Apache 2.4 ? Et aussi s’ils bossent pour intégrer la nouvelle CA Let’s Encrypt ? Merci :p
Emails chiffrés : ProtonMail passe en 2.0, devient open source et lance ses applications mobiles
24/08/2015
Le 25/08/2015 à 13h 20
Le 24/08/2015 à 16h 09
DSM 5.2 de Synology : mise à jour de sécurité pour OpenSSL
16/07/2015
Le 16/07/2015 à 14h 52
iOS 9 et OS X El Capitan : Apple met en ligne ses bêtas publiques
10/07/2015
Le 13/07/2015 à 17h 01
Dire que El capitan supporte des becanes de 2008 c’est pas être fanboy, c’est juste décrire la réalité …
Si t’as un problème avec ça, il existe des établissements adaptés qui te permettront d’arrêter de projeter sur les autres. :)
Liste officielle Apple :
iMac 2007 ou plus récent
· MacBook Air 2008 ou plus récent
· MacBook 2008 ou plus récent
· Mac mini 2009 ou plus récent
· MacBook Pro de mi/fin 2007 ou plus récent
· Mac Pro 2008 ou plus récent
· Xserve 2009 ou plus récent
Le 13/07/2015 à 16h 54
t’as pas remarqué que tu mélanges plusieurs postes peut-être ??? Je n’ai absolument aucun Mac Pro …
Le 13/07/2015 à 16h 34
Tu mélanges vraiment tout et n’importe quoi … t’essayes de tirer dans toutes les directions pour avoir raison on dirait …
1) Ta phrase initiale sous-entendait qu’un Mac de 2011 ramerait sous 10.11 … ce qui est une connerie monumentale … pour l’avoir installé sur mon iMac de 2008, ça tourne comme une horloge !
2) Tu dis Microsoft supporte encore Vista et Seven … Je te signale qu’Apple continue encore de supporter ces anciens système étant donné qu’ils continuent à bénéficier de mises à jour de sécurité. (Apple vient même de pousser une Maj du “Mathusalemiem” Java 6 par exemple … )
4) Y’a aucun besoin de changer une pièce d’origine pour passer à El Capitan …
(J’ai hate que tu répondes pour voir comment tu continues à creuser …
)
Le 13/07/2015 à 08h 45
Peerio passe en version 1.1.0 et apporte quelques nouveautés
24/06/2015
Le 25/06/2015 à 12h 50
Il n’y a pas de chiffrement par défaut et obligatoire sur openfire. Donc on n’est pas vraiment dans le même domaine …
Le 24/06/2015 à 11h 25
heu non …
GitHub
Un, le client complet est dispo sur Github :
Deux, le client est une application complète qui intègre le protocole miniLock et qui gère aussi le gestion des contacts et les envoies des messages et des fichiers chiffrés.
Il vaut peut-être mieux essayer un soft avant de le commenter :p
Le 24/06/2015 à 08h 23
Il n’existe actuellement aucune solution aussi complète et aussi simple d’utilisation avec code dipsonible pour le client et le server. Ici le code client est au moins disponible et Les développeurs s’étaient engagés à publier du code server dans le futur.
HTTPS : le chiffrement par défaut arrive sur Bing et Wikimedia
17/06/2015
Le 17/06/2015 à 08h 59
Le 17/06/2015 à 08h 35
Ho mais je vais répondre, pas de chance je m’y connais bien en TLS …
" />
Il n’y a aucun avantage sur les petites connexions à l’heure où tu l’as dit toi-même, dans les pays occidentaux et “développées”, l’immense majorité des gens ont des machines dotées de puces pour AES (ordis & iphones) et où les machines non-pourves ont des suites de chiffrement très rapides aussi (CHACHA20-POLY1305) sur les smartphones sous Android par exemple.
On faisait du SSL à l’époque du 56K et ça ne posait pas de problème particuliers non plus, au pire ça rajoute quelques secondes pour des connexions anémiques dans les pays en voie de développement.
Pour la consommation des machines, là aussi, tu ne vas pas au bout de ton raisonnement parce que si tu retires les machines dotées de puces dédiées (on doit être dans une grosse majorité des machines accédeant au net aujourd’hui dans les pays développés) et vu que la puce ne consomme quasiment rien à côté du processeur, beaucoup d’études ont montré que TLS était un vrai coût négligeable côté client. En réalité un PC moyen aujourd’hui est capable d’agir en tant que server et de chiffrer plusieurs milliers de connexions TLS par seconde. Par pitié évitons de faire croire que TLS bouffe des tonnes, c’est juste une blague.
Le 17/06/2015 à 08h 16
la généralisation du HTTPS ce n’est en rien de la sécurité aveugle ! Ca permet simplement de ne pas permettre aux intermédiaires techniques de savoir ce que l’on consulte sur un site particulier. Et sur un site comme Wikipedia, je pense que c’est plutôt indispensable à l’heure du tracking permanent.
Je ne vois aucun avantage pour le particulier aux connexions sans TLS non désolé. Pour les très grosses boites c’est surement un allègmement (léger en réalité vu le très faible cout en ressource de TLS aujourd’hui !) d’une partie de la charge server.
Le 17/06/2015 à 08h 06
Alors pour la millième fois dans les comms : Il n’y a pas de limite légale à la taille des cléfs. Que ce soit en Europe ou aux USA en tout cas.
Wikipedia
Enfin, la Loi pour la confiance dans l’économie numérique du 21 juin 2004 a totalement libéré l’utilisation des moyens de cryptologie :
Le 17/06/2015 à 08h 01
Les vraies questions sont :
1) quel intérêt vois-tu à avoir le choix ?
2) Pourquoi priviligierais-tu le HTTP sans TLS à certains moments ?
3) Crois-tu que c’est aux utilisateurs (souvent “ignares” sur les questions de sécurité) à devoir prendre ce choix ?
Facebook lance le chiffrement de ses emails de notification avec GnuPG
02/06/2015
Le 02/06/2015 à 18h 44
Mouais. DKIM ça sert mieux pour lutter contre le phishing que contre le SPAM. Je connais des boites de SPAM qui ont du DKIM installé sur leurs servers. C’est pas très compliqué et ça passe partout. Les grosses boites qui font du SPAM s’y sont mis depuis un moment …
Le 02/06/2015 à 13h 20
Le 02/06/2015 à 09h 10
90% de la population utilisant internet n’est pas foutue de se créer un mot de passe correct.
Vous voulez leur faire utiliser un mécanisme qui demande l’utilisation d’une phrase de passe et qui demande de gérer de manière sécurisée le stockage d’une clé privée ?! Revenez sur terre. PGP/GPG est destiné à une toute petite tranche de la population et le restera encore de nombreuses décennies.
La seule solution est d’apprendre à gérer une phrase de passe. Cette étape est faisable. A partir de là on peut utiliser des système de chiffrement asymétrique avec dérivation des clés via une phrase de passe. Si vous voulez vraiment faire gérer localement une clé privée c’est déjà mort pour une énorme majorité de gens.
Freebox Révolution et mini 4K : firmware 3.1.2 et correctifs pour le boîtier Server
02/06/2015
Le 02/06/2015 à 09h 41
le lecteur multimedia de la mini 4k est tout bonnement merdique pour l’instant. Il ne prend pas en charge le son multupistes (adieu AC3, DTS, DTS-HD, etc …), il ne lit pas certains sous-titres, et la liste est longue.
En gros il lit assez peu de fichiers …
Produit pas fini comme à son habitude avec Free !
Synology : encore une mise à jour de sécurité pour les DSM 5.1 et 5.2
21/05/2015
Le 21/05/2015 à 15h 54
Pour avoir testé sur le mon NAS Synology (DSM 5.2 mis à jour), je peux vous annoncer que le server web n’est pas tuché par la faille logjam mais que le server mail lui l’est vu qu’il accepte les suites de chiffrement Export avec DHE.
Si vous voulez testez par vous-même, il existe cette commande pour openssl :
openssl s_client -starttls smtp -connect smtp.exemple.com:25 -cipher “EXP”
N’hésitez pas à contacter Synology par les moyens que vous préférez pour les faire bouger sur la partie mail. ;)
Logjam : après FREAK, une nouvelle faille dans le chiffrement des connexions
20/05/2015
Le 21/05/2015 à 14h 34
Le 20/05/2015 à 14h 57
@Cedrix @janiko
Vous m’avez mal compris en plus. Retirer DHE ne signifie certainement pas ne plus être compatible avec des anciens clients. (D’ailleurs si on parle vraiment de vieux client, ceux sous Windows XP notamment, DHE n’est presque pas supporté non plus donc bon … ) Supprimer DHE signifie juste rendre les clients les plus récents compatible uniquement avec ECDHE (et donc voir sur du plus long terme).
Rien n’empêche, et c’est ce que tout le monde fait d’ailleurs, moi y compris, de laisser RSA en fin de list de ciphersuites pour toujours rester accessible aux “vieux clients”.
Les GAFA sont une toute autre question, pour certains ils développent carrément un navigateur à eux et quasi tous ont des bibliothèquent TLS patchées avec des modifs maison …
Le 20/05/2015 à 14h 25
des boites qui ont des millions de clients sur le net on en compte 1000 dans le monde entier à tout casser, et je doute que les seniors chargés de la sécu informatique postent des comms sur NXi …
" />
" />
Donc non, mon commentaire ne se destinait pas aux sys admins de Amazon, Paypal, Google, Apple, etc …
Le 20/05/2015 à 14h 23
Pourtant si le site ne supporte plus du tout DHE, tu devrais avoir ce message :
Good News! This site is safe from the Logjam attack. It
Le 20/05/2015 à 14h 14
À la découverte du nouveau moteur de recherche Qwant
14/04/2015
Le 16/04/2015 à 07h 58
Le 14/04/2015 à 16h 35
je connais des sites de recherche qui permettent de faire des recherches sans AUCUN cookie et ça marche très bien. Donc selon moi, pour un site qui met en avant la protection de la vie privée, je pense qu’il serait évidemment souhaitable qu’une recherche sans cookie soit évidemment posssible !
Le 14/04/2015 à 16h 19
Suis-je le seul à avoir une page blanche sur ce site si je désactive les cookies sur mon navigateur ?
Pour un moteur de recherche qui dit respecter nos données et notre vie privée … c’est plutôt cocasse !
Des hébergeurs menacent de quitter la France en cas d’adoption de la loi renseignement
10/04/2015
Le 10/04/2015 à 13h 47
Ben visiblement tu es donc soit un peu naïf, soit assez mauvais sur le plan technique pour gober si facilement le baratin de comm du gouvernement et du raporteur du texte …
Et tu as bien parlé de ne se contenter QUE des metadonnées, ce qui est évidemment faux ce qui est juste de la propagande pour faire passer la pilule du DPI (non contrôlable puisque boite noire avec algo non publique … )
Le 10/04/2015 à 13h 33
Truecrypt n’a finalement aucune porte dérobée ni faille majeure
08/04/2015
Le 08/04/2015 à 10h 42
Le 08/04/2015 à 10h 19
Certaines failles sont parfois théoriquement possibles mais extrêmement difficiles à mettre en place en réalité. Donc l’existence d’une faille ne veut pas forcément toujours dire que la menace est réellement applicable. C’est pour ça que les failles ne sont pas considérées comme majeures.
Nadim Kobeissi : de Cryptocat à Peerio, du piratage au doctorat
30/03/2015
Le 31/03/2015 à 08h 44
Merci pour cet articles très intéressant qui retrace bien le parcours de ce phénomène bien trop peu connu (et soutenu ! ) en France.
Je vous recommande d’utiliser Peerio tant il est simple et facile à prendre en main.