Olivier Serve a écrit 856 commentaires

Ça, c'était un homme !

Il y a une chose qui m'échappe : il faut changer tout le train arrière pour un problème de roulements ?

Tout simplement pour signer les données envoyées avec la clé privée associée au certificat. Tu es le seul détenteur de cette clé privée, il n'y a donc que toi (i.e. ton navigateur) qui puisse signer.

Le concept de "bon" développeur est parfois difficile à juger. Après avoir consulté le code source d'OpenSSL, j'ai du mal à déterminer si c'est génial ou immonde.

Tu le fais exprès ou t'es né con et borné ?

Explications complémentaires de Zack Rusin : http://zrusin.blogspot.com/2009/08/2d-in-kde.html
Je n'ai pas tout relu, mais c'était instructif.

NB: Zack Ruzin fait partie de l'équipe qui développe Gallium3D et a participé au développement des moteurs graphiques de Qt4.

Si le système veut detecter une différence majeure (et pas minime) entre les mots de passe, il doit les stocker en clair.

Absolument pas, il suffit de demander le mot de passe actuel en même temps que le nouveau. On le compare avec le hash enregistré et ensuite on peut faire les comparaisons de différences.

Oui, et ?

Bronsonisée [:aloyd]

Source : http://fr.wiktionary.org/wiki/bronsoniser

Wiktionary :
http://fr.wiktionary.org/wiki/bronsoniser

pour le classement "delirant", va mettre 5000 fichiers dans un folder fat32 on en reparlera

C'est bizarre, les autres constructeurs y arrivent. Apple, c'est vraiment des gros nases quand même.

Pour le vorbis, tu sais tres bien que le vorbis est totalement inadapte au dsp, ca tue la batterie et les implems viable en production ont mit un temps fou a venir. Alors, oui, super hacker le fait tourner dans son garage, ca veut pas dire que c'est mettable en prod, [...]

Dingue ça, mon H340 y arrive depuis 5 ans...

et on passera sous silence toute l'incertitude legale qui tourne autour de ogg vorbis (je sais, c'est quelque chose que tu refuses de comprendre aussi...)

OMG, dépèche-toi de prévenir les ingés de Samsung, Cowon, iRiver et les autres ! Ah, et les dévs de l'UnrealEngine aussi, ils ne sont pas au courant du risque qu'ils courent !

Mouhahahahahahahahahaha

Non mais il faut rester sérieux un peu quand même...

Le coup du PrimaryMail/SecondMail se comprend car il apporte une différenciation sémantique (principal / secondaire) que 2 valeurs pour emailAddress n'apporte pas.

Cela dit, je suis d'accord qu'un client mail qui force un schéma LDAP, c'est très très moyen comme stratégie.

Reste les taches de communication entre les applicatifs, etc, mais ce n'est pas le job d'un environnement avant tout cosmétique.

C'est pourtant tout l'intérêt des environnements de bureau d'apporter plus qu'un gestionnaire de fenêtres.

Corba, DCOP, son successseur D-Bus sont issus des environnements de bureau. Ce n'est pas un hasard, mais ça répond à un besoin de ces environnements.

Ceci dit je ne connais aucun site public qui me propose une authentification par certificat (mais ça doit bien éxister je suppose)

Au hasard, en France, l'administration des impôts. Plus certains services administratifs (Système d'Immatriculation des Véhicules par exemple).

En Belgique, la carte d'identité électronique permet(tra ?) de s'authentifier sur des sites administratifs et repose sur ce principe.

et dans les entreprises proposant ce genre de service, il est rarement possible d'établir une session ssl si l'on ne présente pas son certificat.

Tu as rarement du SSL client uniquement. C'est plus souvent un mélange de SSL serveur & client pour les parties vraiment sensibles.

Le keep-alive permet d'envoyer plusieurs requêtes HTTP. L'attaque fonctionne toujours avec une seule requête sans keep-alive.

D'ailleurs, j'ai pris l'exemple du HTTP parce que c'est ce qui parle le plus, mais sur du LDAP le problème est identique.

Pertinent, j'aurais dû choisir un autre exemple. C'est pas évident de trouver un scénario qui "parle" et soit réaliste à la fois.

En fait, il est plus facile d'exploiter cette attaque avec des services web (SOAP/REST/...) car ils sont en général plutôt prévus pour accepter des requêtes unitaires.

Comme le SSL client est généralement utilisé pour authentifier le client (c'est un peu le but quand même à la base), il y a rarement une page de login derrière.

Pire, en forgeant une requête terminée par un header incomplet (« X-Plop: » qui va permettre d'effacer la première ligne de la requête d'Aline tout en conservant les autres en-têtes), l'intrus profite de tous les cookies du client. Pour une seule requête, certes.

Exactement, c'est ce que je voulais dire.

En effet, l'intrus ne peut pas lire la réponse du serveur. Mais il peut quand même valider des formulaires (par exemple).
Autrement dit il a un accès en écriture seule au système d'information (limité par les droits de l'utilisateur).

Par contre tu as raison (ça m'avait échappé sur le coup), mon scénario ne marche pas. En effet, le client reçoit le certificat du serveur original, qui n'est pas censé correspondre au nom de domaine de l'intrus. Il faut donc du DNS spoofing/cache poisonning/... pour que ça marche.

Dans ce cas précis non, car Aline communique toujours avec le "vrai" serveur.

Attention les yeux, je tente le schéma ASCII :

Aline                  Intrus                Banque
  |----(client hello)--->|                      |
  |                    | |----(client hello)--->|
  |                    | |                      |
  |                    | |<---(server hello)----|
  |                    | |<----(certificat)-----|
  |                    | |<-(server hello done)-|
  |                    | |                      |
  |                    | |--(client key xchge)->|
  |                    | |--(chg cipher spec)-->|
  |                    | |- - - (finished)- - ->|
  |                    | |                      |
  |                    | |<--(chg cipher spec)--|
  |                    | |<- - - (finished)- - -|
  |                    | |                      |
  |                    | |- (GET /priv/evil)- ->| (requêtes forgées)
  |                    | |                      |
  |                    | |<----(hello req)------| (renégo initiée par le serveur)
  |                    | |                      |
  |                    `-|----(client hello)--->| (requête d'Aline rejouée par l'intrus)
  |                      |                      |
  |<---(server hello)----|<---(server hello)----|
  |<----(certificat)-----|<----(certificat)-----|
  |<-----(cert req)------|<-----(cert req)------|
  |<-(server hello done)-|<-(server hello done)-|
  |                      |                      |
  |----(certificat)----->|----(certificat)----->|
  |--(client key xchge)->|--(client key xchge)->|
  |----(cert verif)----->|----(cert verif)----->|
  |--(chg cipher spec)-->|--(chg cipher spec)-->|
  |- - - (finished)- - ->|- - - (finished)- - ->|
  |                      |                      |
  |<--(chg cipher spec)--|<--(chg cipher spec)--|
  |<- - - - - - - - -(finished)- - - - - - - - -|
  |                      |                      |
  |<- - - - - - - -(HTTP/1.1 OK)- - - - - - - - | (réponse à la requête forgée)
  |                      |                      |
  |- - - - - -(GET /priv HTTP/1.1)- - - - - - ->|


Pas tout-à-fait.

1) Une renégo peut avoir lieu aussi si le serveur demande un changement d'algorithmes. C'est assez rare avec des sites web, moins avec des services web.

2) L'intrus n'a jamais connaissance de la clé de chiffrement utilisée entre Aline et sa banque. Il se contente d'injecter des requêtes HTTP nécessitant une authentification client avant que l'authentification n'ait lieu. Et ces requêtes sont exécutées après l'authentification (et sont donc acceptées).

Je n'y avais même pas pensé ^^

Cela dit, j'ai toujours entendu parler d'« homme du milieu » en français. Même si ce n'est pas une référence absolue, wikipédia est d'accord : http://fr.wikipedia.org/wiki/Attaque_de_l'homme_du_milieu

En effet, j'aurais dû préciser qu'on est dans le cas d'une banque qui fait de l'authentification par certificat client (carte à puce ou autre).