"3DES is considered weak and must be avoided, using it cap your score to "C"."
Alors que la RFC 7525 qui te sert de référence dit le contraire :
3DES a un autre biais, sa taille de bloc, qui n’est que de 64 bits, soit bien trop faible.
L’ANSSI déconseille aussi ce cipher (cf http://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf page 10 & 11) et recommande au moins du 128 bits (en taille de clef & en taille de bloc).
Je me pose des questions car ce "perfect" bloque plein d'utilisateurs considérés encore comme sûrs, c'est "perfect" vis à vis de quoi?
C’est « perfect » au sens qu’on n’a aucun des warning/erreurs précédents.
il est imparfait si il bloque des utilisateurs sans raison de sécurité au moment du test
Faux.
Le fait d’avoir du 3DES actif côté serveur suffit à pouvoir tomber dessus en cas de mauvaise configuration (ordre des suites côté client) ou en cas d’attaque (downgrade attack).
On n’est donc pas à l’abris d’une merde dès que 3DES est dispo quelque part.
On a aussi vu que le non support de PFS exposait violamment à la NSA (par exemple via Heartbleed) en cas de compromission de la clef privée dans le futur.
Idem, sauf à utiliser uniquement des suites PFS (puisque la présence d’une non PFS rendrait la connexion potentiellement non fiable), on est à poil.
Du coup, un serveur du monde réel qui ne veut pas se couper de gens sans raison de sécurité en 2015 se tape un "C" sur cryptcheck la où il obtient un "A+" sur SSLLabs…
Ne pas se couper des gens à l’heure actuelle, c’est exploser en plein vol à la prochaine grosse faille de sécu sur ces protocoles. TLSv1.0 & TLSv1.1 sont dorénavant faillibles à du Poodle, et une escalade de cette faille rendrait vulnérables tous les utilisateurs de ces protocoles.
La note « A » est donc la seule configuration valable actuellement qui résistera dans le temps et évitera d’avoir à patcher à l’arrache (ou non, cf RC4 & MD5 qui persistent malgré les risques…).
Tant qu’on ne fait pas mal à l’utilisateur, la sécu ne s’améliore pas. La preuve, même les CA ne savent pas commencer à bosser avant d’être plus que le dos au mur (voire même plutôt déjà encastrées dedans), cf https://cabforum.org/pipermail/public/2015-September/005935.html
Postfix permet d'éviter cela en vérifiant à la place que le certificat utilisé couvre bien le nom de domaine destinataire
C’est plus compliqué que ça.
En pratique, il ne faut pas vérifier le nom de domaine du certificat, car à l’inverse de HTTPS, SMTP+STARTTLS ne permet pas SNI, ie. de sélectionner un certificat pour chaque domaine de destination, sauf à sous-entendre que 1 domaine = 1 serveur SMTP & 1 IP.
C’est par exemple particulièrement vrai pour les fournisseurs mutualisés, comme OVH, Google ou Microsoft, qui n’ont qu’un seul MX pour l’ensemble des domaines servis.
Au mieux on pourrait seulement vérifier que domaine du certificat = domaine du MX (ou de son reverse), mais en aucun cas la vérification domaine du certificat = domaine du récepteur n’est possible. Une usurpation du DNS ne pourra donc pas être détectée par ce moyen.
De plus, les RFC mentionnent aussi qu’il faut considérer que les serveurs SMTP émetteurs n’ont pas les compétences nécessaires pour vérifier la chaîne de validité, par exemple pas de liste de CA valides (cf https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.3).
Un MitM serait dans tous les cas facilement faisables, via un simple certificat auto-signé usurpant le domaine visé…
En clair, le mail est non sécurisable parce que personne ne l’a envisagé comme ça quand il a été définit au début du monde, et toutes les couches de sécu actuelles sont des hacks plus ou moins ignobles et (in)efficaces pour corriger le tir.
Le problème de la notation pour le mail, c’est que c’est beaucoup plus compliqué que pour HTTPS, SMTP étant un protocole asynchrone. En particulier, il vaut mieux utiliser un protocole totalement moisi comme SSLv3, DES ou MD5 que d’émettre le message en clair, ce qui est le cas si les 2 serveurs n’arrivent pas à se mettre d’accord sur une suite de chiffrement.
Un serveur noté « F » n’est donc pas complètement anormal tant qu’on aura pas améliorer l’ensemble des serveurs du monde.
À noter aussi que la présence (ou l’absence) de STARTTLS n’est pas authentifiée comme dans le cas de HTTPS, et donc qu’un attaquant dans le réseau n’a qu’à simplement droper le petit paquet réseau contenant la chaîne « STARTTLS » dans les échanges SMTP pour que le serveur émetteur considère que le destinataire ne supporte pas le chiffrement et envoie alors le message en clair.
C’est à la portée de n’importe qui, y compris d’un pixel sur le parvis de la Défense avec un routeur TP-Link à $20… Je vous laisse le soin de comprendre ce qu’une agence gouvernementale est capable de faire sur le sujet :)
Les 2 cumulés, sauf à avoir de sérieuses preuves scientifiques que leur système a fait mieux sur ces 2 domaines, c’est juste un no-go.
Et en prime, vouloir faire du mail « sécurisé », quand on sait ce que leak comme méta-données ce protocole, c’est plus ou moins du suicide aussi.
Pour finir, la même question qu’on devrait toujours se poser avant de parler de sécurité : c’est quoi le modèle de menace ?
Whiteout annonce même clairement qu’ils n’en ont pas et que c’est à l’utilisateur de bâtir le sien et de savoir s’il peut utiliser ce service : https://whiteout.io/security.html « So it's best to decide which threat model applies to you. »
Sans plus d’infos techniques à disposition de l’utilisateur pour qu’il puisse réellement faire cette réflexion, inutilisable aussi.
Allez, encore un petit effort pour le A+ sur SSLLabs :D
Il y a encore du RC4 qui traîne et quelques navigateurs sans Forward Secrecy.
Et il manque aussi le support de HSTS.
Les configs qui vont bien : http://www.iletaitunefoisinternet.fr/ssltls-benjamin-sonntag/
Les sources des bannières étant publiques, tu pouvais très bien supprimer ces boutons.
Et même héberger chez toi ces pages pour éviter le tracking.
C'est ce qui a été fait sur le site de l'April (avec en prime la traduction en Français).
Quitte à défendre une cause, autant commencer par se l'appliquer à soi-même :)
Et la « norme » est totalement incomplète, avec des gros passages de type « pour cette fonction super utile, cf spec privée non publique d'une techno privatrice qu'on gardera bien pour nous »
L'objectif est de faire quoi ? Juste de gérer tes propres certificats ?
Ou de vraiment mettre en place une vraie PKI au sens large, avec livraison des certificats aux clients de manière sécurisée, gestion de la révocation, OSCP et le reste ?
Dans le 1er cas, EJBCA et OpenCA me paraissent juste overkill, XCA est bien plus simple pour une utilisation personnelle.
C'est beau de parler sur des préjugés (combien as-tu rencontré d'Epitech ? Ayant terminé leurs études, je parle).
Un certain nombre, que ça soit des candidats, des stagiaires ou des nouveaux diplômés.
Le niveau global est assez faible, généralement la personne ne maîtrise qu'un unique point de détail ou techno, le reste lui passe à 400km au dessus de la tête.
On va quand même éviter de généraliser trop brutalement, mais apparemment je ne suis pas le seul à avoir cette avis/expérience ici.
C'est beau de confondre le service communication d'une école avec ses étudiants.
Euh, généralement l'un ne va pas sans l'autre…
À force de voir dans les journaux ou l'actualité qu'ils sont les meilleurs du monde, forcément qu'ils finissent par y croire.
Et j'imagine assez mal un service communication qui dit une chose quand le corps enseignant les étudiants disent l'inverse =)
Concernant Epitech, même la formation spécialisée est très (trop) restreinte pour appeler ça une spécialité.
Ça pisse de la ligne en très grosse quantité, guère plus.
Au final ça sort de là à Bac+5 mais je préfère bien largement recruter des DUT à Bac+3 qui ont vraiment une approche utile et intéressante de la pratique de notre métier.
Et en tout cas, le diplôme et l'école d'origine ne rentre absolument pas en ligne de compte pour motiver mon avis quand je fais passer des entretiens d'embauche.
En plus de ça (et cette article en est une parfaite illustration), ils sont élevés à avoir une très haute estime d'eux-même et pensent réellement faire partie de l'élite européenne voire mondiale…
C'est un style de personnalité dont j'ai personnellement horreur et qui s'avère généralement totalement improductive voire contre-productive sur le terrain.
J'ai bien compris, et devines quoi, le developpeur doit lire la doc des APIs aussi, histoire de comprendre quels effets de bord ils peuvent avoir, dans quel cas ils peuvent se rater, etc…
J'ai aussi une info de dernière fraicheur pour toi : une doc n'est jamais à jour, toujours obsolète, toujours incohérente, toujours incomplète, voire même inexistante.
Celui qui te dira le contraire est un fou.
Si tu persistes encore à maintenir le contraire, prend n'importe quelle doc de ton choix et prouve-moi qu'elle est non seulement correcte, mais en plus exhaustive de tout ce qui peut se passer via n'importe quel cas d'utilisation.
La seule et unique chose qui peut décrire sans omission le comportement d'un code-source, c'est ce code-source lui-même, et lui seul.
Tout ce qu'un développeur peut te dire au sujet de ce code, et en particulier la doc, est tout autant soumis aux bugs du développeur que le code lui-même.
Un développeur peut très bien ne pas s'apercevoir d'un effet de bord de son code, et ne le documentera donc pas.
Je serais ouvert a ecouter tes experiences sur le sujet relativement aux gros projets software et a leur success / qualite. Si tu as mieux, n'hesites pas.
Je développe des softs toute la journée, et la qualité logicielle est justement une de mes préoccupations principale.
Et pour te résumer ma position de manière succinte : le C et consort, c'est mal; le duck-typing, c'est mal; le non-typé, c'est mal.
Pour le cas qui nous concerne, les check-exceptions sont pour moi le meilleur moyen de résoudre le problème qui nous inquiète.
Si on regarde le problème initial :
- Dans 99% des cas, on ne sait pas quelles erreurs peuvent arriver pour chaque ligne du programme. Cf supra, la doc ne peut pas aider sur ce point;
- Dans 99% des cas, on ne sait pas gérer une erreur au niveau où l'on est, et on devra la propager au niveau supérieur, jusqu'à ce que quelqu'un sache la gérer;
- Dans les cas les plus graves (null pointer exception, out of memory, buffer overflow…), on sait pertinemment que rien ne sert de tenter le moindre rétablissement, on est mort, autant s'arrêter.
Plutôt que d'avoir du code ignoble et inmaintenable à écrire sur chaque ligne et pour chaque erreur possible et/ou avoir à écrire la propagation supérieure et/ou avoir à gérer l'arrêt du programme, et ce sur chaque méthode, chaque appel de méthode et chaque programme, ça devrait être au compilateur de faire ce travail.
D'autant plus qu'il est très laborieux à faire, très difficile à faire écrire correctement et soumis à la bonne volonté du développeur (et de son planning/ses délais/ses finances !).
Si on prend les exceptions à la Java, on règle d'un coup tous les problèmes :
- Chaque méthode déclarant toutes les exceptions qu'elle peut lever, aucun risque d'en oublier une seule;
- Si une erreur peut arriver, alors on a que 2 choix, soit on sait la traiter et on la traite, soit on ne sait pas et on la laisse remonter, en déclarant que notre propre méthode peut échouer;
- Dans les cas les plus graves, le système lève une exception non-contrôlée, qui remontera toute seule toute la chaîne d'appel et arrêtera le programme.
C'est le compilateur qui fera tout le travail ingrat, proprement et sûrement, de manière mutualisée, évitant au développeur de réinventer la roue (carrée, de préférence…).
Voilà comment faire les choses proprement : déléguer au compilateur le maximum possible de vérification.
Un compilateur ne fera pas d'erreur, un développeur en fera obligatoirement une.
La realite est que cette methode est utilisee dans certains des plus gros projets software existants (Windows et Office au hasard ainsi que le kernel Linux) et que ca marche tres bien.
C'est pas parce que tout le monde fait comme ça qu'il faut faire comme ça…
Sinon, ça veut dire que Windows est meilleur que Linux ?
Sinon, ta phrase "l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète)" est franchement horrible, oh mon dieu, l'utilisateur doit lire la doc ? Grande nouvelle, si il ne l'a lit pas, mieux vaut qu'il n'ecrive pas de code !
En temps que développeur d'une application, tu es utilisateur des API de plus bas niveau.
Je ne parlais pas de l'utilisateur final, d'ailleurs ma phrase commence bien par « Au niveau développement ».
Ça ne change pas grand chose au final, ce genre de code est juste ignoble et devrait être catapulté en orbite à coup de bombes nucléaires (pour paraphraser Linus).
Sur un bout de code à la con, on voit bien que pour 2 lignes utiles qui devraient conduire à une complexité cyclomatique de 1 et dont le pseudo-code serait
fooBar() {
foo()
bar()
}
on en arrive à une 15aine de lignes de code et une complexité de 4.
Sur un soft d'une complexité standard, je te laisse imaginer ce que ça donne…
Idem en maintenance/évolution, alors que sur le pseudo-code on n'aurait qu'à ajouter une ligne entre foo() et bar(), en C on va devoir toucher aussi à toute la partie nettoyage/gestion d'erreur, aussi bien dans notre code que dans le code appelant. Idéal pour semer des régressions aux 4 coins de l'appli…
Au niveau développement, l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète) voire pire, carrément le code source…
Et même s'il prend la peine d'aller lire la doc, il ne sait généralement pas quoi faire en cas d'erreur, sinon se mettre à remonter à l'appelant toutes les erreurs de sa couche basse. « Eh les gars, on est en train de recoder les check-exceptions là ! »
Par extension, tout code en C DEVRAIT être codé selon ce principe, sauf à conduire aux différents problèmes soulevés PAR UN UTILISATEUR FINAL, c'est donc carrément le langage C qui devrait être mis en orbite !
Le problème, c'est justement comme tu le dis si bien, la PLUPART des appels retourne des codes de retour en C, quasiment jamais vérifié, et que tu devrais toi aussi retourner du coup un code d'erreur.
Ton code, ça va bien quand t'as 1 appel (et encore, le goto, c'est mal…). Mais je fais quoi quand j'empile 3, 4, 10, 42 appels ?
Tes 5-10s se transforment en 5-10min puis 5-10j puis 5-10mois, puis… Et faut aussi inclure le coût de la maintenance et des évolutions futures.
int fooBar() {
if (foo()) {
goto clean1;
}
if (bar()) {
goto clean2;
}
return 0;
clean1:
cleanFoo(); // Merdeuuuuuuuuuuu, je peux planter aussi…
return -1;
clean2:
cleanBar(); // Remerdeuuuuuuuuu, je peux planter aussi…
return -1;
}
C'est moche, c'est inmaintenable, c'est soumis à une palanqué de possibilité de bugs, ça fait du code spaghetti, ça fait qu'on perd à chaque fois la possibilité de retourner des valeurs non code d'erreur et donc qu'on doit se taper des passages par référence partout…
Et on ne sait généralement pas quoi faire sinon faire arrêter le programme de manière très moche dès qu'un truc retourne un truc non nul.
On n'a aucune certitude que notre programme fonctionnera correctement sauf à écrire du code considéré comme ignoble par tout développeur standard.
Et au final tout le monde s'en contre-fou de ces codes de retour, conduisant à des applis qui plantent/fuitent/buggent !
À ce sujet, il serait intéressant de connaître le matériel utilisé par le jury.
Je ne serais pas étonné que sa grosse majorité soit équipé avec la marque à la pomme, ce qui pourrait expliquer ce verdict et sa rapidité, étant donné la propension fan-boyiste chronique de cette partie de la population.
Mon petit mien au passage : https://gist.github.com/3094451
Ce qui peut donner : « (±|master|●1|+1|…1|⚡) » , scm | branche courante | modifs indexées | modifs non indexées | fichiers non trackés | état du workspace
Alors dans ce cas précis, je sort deboostrap/virtualbox/kvm/vserver et je me monte une Debian aussi pourrie que tu le souhaites pour compiler mon paquet et en faire un package Debian que j'installe proprement sur ma véritable Debian de tous les jours qui reste du coup toujours propre.
Pour moi, les seuls softs qui nécessitent d'être vraiment à jour, ce sont les navigateurs web.
Tente d'être en firefox 3.5 pour naviguer, tu vas juste pleurer et te croire sous IE6…
Peut-être aussi les clients de messageries instantanées, surtout sur les protocoles propriétaires.
Pour le reste, effectivement, avoir la dernière version n'apporte généralement pas grand chose.
Je ne te parle pas du point de vue du développeur Debian, mais de celui d'un utilisateur lambda.
Certes, testing est sensé servir à préparer la future stable.
Mais pour une Madame Michu standard, utiliser une stable est juste inenvisageable.
Certes c'est stable, joli et propre, mais les softs datent de Mathusalem, et comme on l'a si bien dit, Firefox 3.5, KDE 4.4, Chromium 0.9 ou OpenOffice 3.2 (wé, même pas de LibreOffice…), c'est pas que c'est @deprecated depuis des lustres mais presque.
Si tu promeus Debian en disant « Testing c'est pour les développeurs qui veulent stabiliser la future stable, donc tu restes en Stable car tu es simple utilisateur standard », je comprend mieux que Linux a du mal à s'imposer, les gens vont l'utiliser 2h et aller voir ailleurs…
C'est bien pour ça qu'il y a stable et testing.
Stable pour les serveurs pour sa fiabilité, stabilité et sécurité.
Testing pour le desktop, avec des softs suffisamment à jour sans être (trop) buggés et relativement fiables pour une utilisation quotidienne (pas besoin d'une SLA de 99.999% pour un utilisateur normalement constitué =)).
Oui mais si tu veux aider à stabiliser, tu ne dois plus te considérer comme utilisateur lambda et t'attendre à des effets de bord (bugs, failles, stabilité générale, cassure dans les dépendences…).
Généralement, je fais même ça dans une VM, histoire de ne pas trop mettre en péril mon PC desktop.
Et dans tous les cas, tu ne viens pas te plaindre après sur linuxfr que ça ne fonctionne plus (et encore moins de cette manière là).
[^] # Re: Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 1. Dernière modification le 13 octobre 2015 à 10:19.
3DES a un autre biais, sa taille de bloc, qui n’est que de 64 bits, soit bien trop faible.
L’ANSSI déconseille aussi ce cipher (cf http://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf page 10 & 11) et recommande au moins du 128 bits (en taille de clef & en taille de bloc).
C’est « perfect » au sens qu’on n’a aucun des warning/erreurs précédents.
Faux.
Le fait d’avoir du 3DES actif côté serveur suffit à pouvoir tomber dessus en cas de mauvaise configuration (ordre des suites côté client) ou en cas d’attaque (downgrade attack).
On n’est donc pas à l’abris d’une merde dès que 3DES est dispo quelque part.
On a aussi vu que le non support de PFS exposait violamment à la NSA (par exemple via Heartbleed) en cas de compromission de la clef privée dans le futur.
Idem, sauf à utiliser uniquement des suites PFS (puisque la présence d’une non PFS rendrait la connexion potentiellement non fiable), on est à poil.
Ne pas se couper des gens à l’heure actuelle, c’est exploser en plein vol à la prochaine grosse faille de sécu sur ces protocoles. TLSv1.0 & TLSv1.1 sont dorénavant faillibles à du Poodle, et une escalade de cette faille rendrait vulnérables tous les utilisateurs de ces protocoles.
La note « A » est donc la seule configuration valable actuellement qui résistera dans le temps et évitera d’avoir à patcher à l’arrache (ou non, cf RC4 & MD5 qui persistent malgré les risques…).
Tant qu’on ne fait pas mal à l’utilisateur, la sécu ne s’améliore pas. La preuve, même les CA ne savent pas commencer à bosser avant d’être plus que le dos au mur (voire même plutôt déjà encastrées dedans), cf https://cabforum.org/pipermail/public/2015-September/005935.html
[^] # Vérif du certificat
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 4.
C’est plus compliqué que ça.
En pratique, il ne faut pas vérifier le nom de domaine du certificat, car à l’inverse de HTTPS, SMTP+STARTTLS ne permet pas SNI, ie. de sélectionner un certificat pour chaque domaine de destination, sauf à sous-entendre que 1 domaine = 1 serveur SMTP & 1 IP.
C’est par exemple particulièrement vrai pour les fournisseurs mutualisés, comme OVH, Google ou Microsoft, qui n’ont qu’un seul MX pour l’ensemble des domaines servis.
Au mieux on pourrait seulement vérifier que domaine du certificat = domaine du MX (ou de son reverse), mais en aucun cas la vérification domaine du certificat = domaine du récepteur n’est possible. Une usurpation du DNS ne pourra donc pas être détectée par ce moyen.
De plus, les RFC mentionnent aussi qu’il faut considérer que les serveurs SMTP émetteurs n’ont pas les compétences nécessaires pour vérifier la chaîne de validité, par exemple pas de liste de CA valides (cf https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.3).
Un MitM serait dans tous les cas facilement faisables, via un simple certificat auto-signé usurpant le domaine visé…
En clair, le mail est non sécurisable parce que personne ne l’a envisagé comme ça quand il a été définit au début du monde, et toutes les couches de sécu actuelles sont des hacks plus ou moins ignobles et (in)efficaces pour corriger le tir.
# Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 4.
Il y a l’outil que j’ai développé : https://tls.imirhil.fr/
Sources dispo ici : https://github.com/aeris/cryptcheck
Le problème de la notation pour le mail, c’est que c’est beaucoup plus compliqué que pour HTTPS, SMTP étant un protocole asynchrone. En particulier, il vaut mieux utiliser un protocole totalement moisi comme SSLv3, DES ou MD5 que d’émettre le message en clair, ce qui est le cas si les 2 serveurs n’arrivent pas à se mettre d’accord sur une suite de chiffrement.
Un serveur noté « F » n’est donc pas complètement anormal tant qu’on aura pas améliorer l’ensemble des serveurs du monde.
À noter aussi que la présence (ou l’absence) de STARTTLS n’est pas authentifiée comme dans le cas de HTTPS, et donc qu’un attaquant dans le réseau n’a qu’à simplement droper le petit paquet réseau contenant la chaîne « STARTTLS » dans les échanges SMTP pour que le serveur émetteur considère que le destinataire ne supporte pas le chiffrement et envoie alors le message en clair.
C’est à la portée de n’importe qui, y compris d’un pixel sur le parvis de la Défense avec un routeur TP-Link à $20… Je vous laisse le soin de comprendre ce qu’une agence gouvernementale est capable de faire sur le sujet :)
# Crypto & Javascript ? Seriously ?
Posté par Aeris (site web personnel) . En réponse à la dépêche Whiteout, chiffrement de bout en bout des courriels, convivial et OpenSource. Évalué à 10.
On ne peut pas faire de crypto « propre » dans le navigateur, via Javascript.
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
http://blog.kotowicz.net/2014/07/js-crypto-goto-fail.html
Mettre sa clef privée sur iOS ou sur Androïd, faut aussi être maso.
Coucou la puce baseband : https://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor
Les 2 cumulés, sauf à avoir de sérieuses preuves scientifiques que leur système a fait mieux sur ces 2 domaines, c’est juste un no-go.
Et en prime, vouloir faire du mail « sécurisé », quand on sait ce que leak comme méta-données ce protocole, c’est plus ou moins du suicide aussi.
Pour finir, la même question qu’on devrait toujours se poser avant de parler de sécurité : c’est quoi le modèle de menace ?
Whiteout annonce même clairement qu’ils n’en ont pas et que c’est à l’utilisateur de bâtir le sien et de savoir s’il peut utiliser ce service :
https://whiteout.io/security.html « So it's best to decide which threat model applies to you. »
Sans plus d’infos techniques à disposition de l’utilisateur pour qu’il puisse réellement faire cette réflexion, inutilisable aussi.
[^] # Re: HTTPS
Posté par Aeris (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 6.
Normalement tu peux avoir A+ avec la conf à Benjamin en délaissant juste IE6/XP et IE8/XP. Ça ne doit plus concerner grand monde :D
# HTTPS
Posté par Aeris (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 5.
Allez, encore un petit effort pour le A+ sur SSLLabs :D
Il y a encore du RC4 qui traîne et quelques navigateurs sans Forward Secrecy.
Et il manque aussi le support de HSTS.
Les configs qui vont bien : http://www.iletaitunefoisinternet.fr/ssltls-benjamin-sonntag/
[^] # Re: Cohérence
Posté par Aeris (site web personnel) . En réponse à la dépêche Le jour de la riposte (« The Day We Fight Back ») contre la surveillance généralisée. Évalué à 3.
Les sources des bannières étant publiques, tu pouvais très bien supprimer ces boutons.
Et même héberger chez toi ces pages pour éviter le tracking.
C'est ce qui a été fait sur le site de l'April (avec en prime la traduction en Français).
Quitte à défendre une cause, autant commencer par se l'appliquer à soi-même :)
[^] # Re: En résumé
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé de LibreOffice à une suite propriétaire.... Évalué à 10.
Et la « norme » est totalement incomplète, avec des gros passages de type « pour cette fonction super utile, cf spec privée non publique d'une techno privatrice qu'on gardera bien pour nous »
# Utilisation personnelle simple ou PKI full features ?
Posté par Aeris (site web personnel) . En réponse au journal PKI open source: retours d'experience ?. Évalué à 2.
L'objectif est de faire quoi ? Juste de gérer tes propres certificats ?
Ou de vraiment mettre en place une vraie PKI au sens large, avec livraison des certificats aux clients de manière sécurisée, gestion de la révocation, OSCP et le reste ?
Dans le 1er cas, EJBCA et OpenCA me paraissent juste overkill, XCA est bien plus simple pour une utilisation personnelle.
[^] # Re: Écoles d'ingénieurs?
Posté par Aeris (site web personnel) . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 10. Dernière modification le 15 novembre 2012 à 01:07.
Un certain nombre, que ça soit des candidats, des stagiaires ou des nouveaux diplômés.
Le niveau global est assez faible, généralement la personne ne maîtrise qu'un unique point de détail ou techno, le reste lui passe à 400km au dessus de la tête.
On va quand même éviter de généraliser trop brutalement, mais apparemment je ne suis pas le seul à avoir cette avis/expérience ici.
Euh, généralement l'un ne va pas sans l'autre…
À force de voir dans les journaux ou l'actualité qu'ils sont les meilleurs du monde, forcément qu'ils finissent par y croire.
Et j'imagine assez mal un service communication qui dit une chose quand
le corps enseignantles étudiants disent l'inverse =)[^] # Re: Écoles d'ingénieurs?
Posté par Aeris (site web personnel) . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 10.
J'avais bien compris pour ta formation =)
Concernant Epitech, même la formation spécialisée est très (trop) restreinte pour appeler ça une spécialité.
Ça pisse de la ligne en très grosse quantité, guère plus.
Au final ça sort de là à Bac+5 mais je préfère bien largement recruter des DUT à Bac+3 qui ont vraiment une approche utile et intéressante de la pratique de notre métier.
Et en tout cas, le diplôme et l'école d'origine ne rentre absolument pas en ligne de compte pour motiver mon avis quand je fais passer des entretiens d'embauche.
En plus de ça (et cette article en est une parfaite illustration), ils sont élevés à avoir une très haute estime d'eux-même et pensent réellement faire partie de l'élite européenne voire mondiale…
C'est un style de personnalité dont j'ai personnellement horreur et qui s'avère généralement totalement improductive voire contre-productive sur le terrain.
[^] # Re: Écoles d'ingénieurs?
Posté par Aeris (site web personnel) . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 3. Dernière modification le 14 novembre 2012 à 23:17.
Wé, 'fin généralistes, ils le sont clairement pas. Spécialistes encore moins.
Même pour amuser la galerie au bureau, j'en voudrais pas :þ
# Oh my god ><
Posté par Aeris (site web personnel) . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 6.
Ça va les chevilles, pas trop douloureuses ?
Et la tête ? Elle passe encore dans les portes ?
[^] # Re: Ouf je me sens moins seul d’un coup.
Posté par Aeris (site web personnel) . En réponse au journal Free et Google. Effets de bord. Évalué à 4.
Idem, Val-de-Marne, tout ce qui touche à Google de près ou de loin rame.
Aucun soucis dès que j'utilise mon dédié OVH comme rebond.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Aeris (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à -5.
On va commencer par la fin, ça sera plus logique.
J'ai aussi une info de dernière fraicheur pour toi : une doc n'est jamais à jour, toujours obsolète, toujours incohérente, toujours incomplète, voire même inexistante.
Celui qui te dira le contraire est un fou.
Si tu persistes encore à maintenir le contraire, prend n'importe quelle doc de ton choix et prouve-moi qu'elle est non seulement correcte, mais en plus exhaustive de tout ce qui peut se passer via n'importe quel cas d'utilisation.
La seule et unique chose qui peut décrire sans omission le comportement d'un code-source, c'est ce code-source lui-même, et lui seul.
Tout ce qu'un développeur peut te dire au sujet de ce code, et en particulier la doc, est tout autant soumis aux bugs du développeur que le code lui-même.
Un développeur peut très bien ne pas s'apercevoir d'un effet de bord de son code, et ne le documentera donc pas.
Je développe des softs toute la journée, et la qualité logicielle est justement une de mes préoccupations principale.
Et pour te résumer ma position de manière succinte : le C et consort, c'est mal; le duck-typing, c'est mal; le non-typé, c'est mal.
Pour le cas qui nous concerne, les check-exceptions sont pour moi le meilleur moyen de résoudre le problème qui nous inquiète.
Si on regarde le problème initial :
- Dans 99% des cas, on ne sait pas quelles erreurs peuvent arriver pour chaque ligne du programme. Cf supra, la doc ne peut pas aider sur ce point;
- Dans 99% des cas, on ne sait pas gérer une erreur au niveau où l'on est, et on devra la propager au niveau supérieur, jusqu'à ce que quelqu'un sache la gérer;
- Dans les cas les plus graves (null pointer exception, out of memory, buffer overflow…), on sait pertinemment que rien ne sert de tenter le moindre rétablissement, on est mort, autant s'arrêter.
Plutôt que d'avoir du code ignoble et inmaintenable à écrire sur chaque ligne et pour chaque erreur possible et/ou avoir à écrire la propagation supérieure et/ou avoir à gérer l'arrêt du programme, et ce sur chaque méthode, chaque appel de méthode et chaque programme, ça devrait être au compilateur de faire ce travail.
D'autant plus qu'il est très laborieux à faire, très difficile à faire écrire correctement et soumis à la bonne volonté du développeur (et de son planning/ses délais/ses finances !).
Si on prend les exceptions à la Java, on règle d'un coup tous les problèmes :
- Chaque méthode déclarant toutes les exceptions qu'elle peut lever, aucun risque d'en oublier une seule;
- Si une erreur peut arriver, alors on a que 2 choix, soit on sait la traiter et on la traite, soit on ne sait pas et on la laisse remonter, en déclarant que notre propre méthode peut échouer;
- Dans les cas les plus graves, le système lève une exception non-contrôlée, qui remontera toute seule toute la chaîne d'appel et arrêtera le programme.
C'est le compilateur qui fera tout le travail ingrat, proprement et sûrement, de manière mutualisée, évitant au développeur de réinventer la roue (carrée, de préférence…).
Voilà comment faire les choses proprement : déléguer au compilateur le maximum possible de vérification.
Un compilateur ne fera pas d'erreur, un développeur en fera obligatoirement une.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Aeris (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à -6. Dernière modification le 09 septembre 2012 à 21:14.
C'est pas parce que tout le monde fait comme ça qu'il faut faire comme ça…
Sinon, ça veut dire que Windows est meilleur que Linux ?
En temps que développeur d'une application, tu es utilisateur des API de plus bas niveau.
Je ne parlais pas de l'utilisateur final, d'ailleurs ma phrase commence bien par « Au niveau développement ».
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Aeris (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 1.
Ça ne change pas grand chose au final, ce genre de code est juste ignoble et devrait être catapulté en orbite à coup de bombes nucléaires (pour paraphraser Linus).
Sur un bout de code à la con, on voit bien que pour 2 lignes utiles qui devraient conduire à une complexité cyclomatique de 1 et dont le pseudo-code serait
on en arrive à une 15aine de lignes de code et une complexité de 4.
Sur un soft d'une complexité standard, je te laisse imaginer ce que ça donne…
Idem en maintenance/évolution, alors que sur le pseudo-code on n'aurait qu'à ajouter une ligne entre foo() et bar(), en C on va devoir toucher aussi à toute la partie nettoyage/gestion d'erreur, aussi bien dans notre code que dans le code appelant. Idéal pour semer des régressions aux 4 coins de l'appli…
Au niveau développement, l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète) voire pire, carrément le code source…
Et même s'il prend la peine d'aller lire la doc, il ne sait généralement pas quoi faire en cas d'erreur, sinon se mettre à remonter à l'appelant toutes les erreurs de sa couche basse.
« Eh les gars, on est en train de recoder les check-exceptions là ! »
Par extension, tout code en C DEVRAIT être codé selon ce principe, sauf à conduire aux différents problèmes soulevés PAR UN UTILISATEUR FINAL, c'est donc carrément le langage C qui devrait être mis en orbite !
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Aeris (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 1.
Le problème, c'est justement comme tu le dis si bien, la PLUPART des appels retourne des codes de retour en C, quasiment jamais vérifié, et que tu devrais toi aussi retourner du coup un code d'erreur.
Ton code, ça va bien quand t'as 1 appel (et encore, le goto, c'est mal…). Mais je fais quoi quand j'empile 3, 4, 10, 42 appels ?
Tes 5-10s se transforment en 5-10min puis 5-10j puis 5-10mois, puis… Et faut aussi inclure le coût de la maintenance et des évolutions futures.
C'est moche, c'est inmaintenable, c'est soumis à une palanqué de possibilité de bugs, ça fait du code spaghetti, ça fait qu'on perd à chaque fois la possibilité de retourner des valeurs non code d'erreur et donc qu'on doit se taper des passages par référence partout…
Et on ne sait généralement pas quoi faire sinon faire arrêter le programme de manière très moche dès qu'un truc retourne un truc non nul.
On n'a aucune certitude que notre programme fonctionnera correctement sauf à écrire du code considéré comme ignoble par tout développeur standard.
Et au final tout le monde s'en contre-fou de ces codes de retour, conduisant à des applis qui plantent/fuitent/buggent !
[^] # Re: J'y connais rien en droit étasuniens mais j'ouvre ma gueule !!
Posté par Aeris (site web personnel) . En réponse au journal Apple vs Samsung: le verdict. Évalué à 7.
À ce sujet, il serait intéressant de connaître le matériel utilisé par le jury.
Je ne serais pas étonné que sa grosse majorité soit équipé avec la marque à la pomme, ce qui pourrait expliquer ce verdict et sa rapidité, étant donné la propension fan-boyiste chronique de cette partie de la population.
[^] # Re: Et zsh ?
Posté par Aeris (site web personnel) . En réponse à la dépêche Un prompt bash utile, sans poudre aux yeux. Évalué à 1.
Mon petit mien au passage : https://gist.github.com/3094451
Ce qui peut donner : « (±|master|●1|+1|…1|⚡) » , scm | branche courante | modifs indexées | modifs non indexées | fichiers non trackés | état du workspace
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 2.
Alors dans ce cas précis, je sort deboostrap/virtualbox/kvm/vserver et je me monte une Debian aussi pourrie que tu le souhaites pour compiler mon paquet et en faire un package Debian que j'installe proprement sur ma véritable Debian de tous les jours qui reste du coup toujours propre.
Mauvais usage, changer usage =)
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 2.
Pour moi, les seuls softs qui nécessitent d'être vraiment à jour, ce sont les navigateurs web.
Tente d'être en firefox 3.5 pour naviguer, tu vas juste pleurer et te croire sous IE6…
Peut-être aussi les clients de messageries instantanées, surtout sur les protocoles propriétaires.
Pour le reste, effectivement, avoir la dernière version n'apporte généralement pas grand chose.
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 1.
Je ne te parle pas du point de vue du développeur Debian, mais de celui d'un utilisateur lambda.
Certes, testing est sensé servir à préparer la future stable.
Mais pour une Madame Michu standard, utiliser une stable est juste inenvisageable.
Certes c'est stable, joli et propre, mais les softs datent de Mathusalem, et comme on l'a si bien dit, Firefox 3.5, KDE 4.4, Chromium 0.9 ou OpenOffice 3.2 (wé, même pas de LibreOffice…), c'est pas que c'est @deprecated depuis des lustres mais presque.
Si tu promeus Debian en disant « Testing c'est pour les développeurs qui veulent stabiliser la future stable, donc tu restes en Stable car tu es simple utilisateur standard », je comprend mieux que Linux a du mal à s'imposer, les gens vont l'utiliser 2h et aller voir ailleurs…
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 0.
C'est bien pour ça qu'il y a stable et testing.
Stable pour les serveurs pour sa fiabilité, stabilité et sécurité.
Testing pour le desktop, avec des softs suffisamment à jour sans être (trop) buggés et relativement fiables pour une utilisation quotidienne (pas besoin d'une SLA de 99.999% pour un utilisateur normalement constitué =)).
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 3.
Oui mais si tu veux aider à stabiliser, tu ne dois plus te considérer comme utilisateur lambda et t'attendre à des effets de bord (bugs, failles, stabilité générale, cassure dans les dépendences…).
Généralement, je fais même ça dans une VM, histoire de ne pas trop mettre en péril mon PC desktop.
Et dans tous les cas, tu ne viens pas te plaindre après sur linuxfr que ça ne fonctionne plus (et encore moins de cette manière là).