lom a écrit 444 commentaires

Si tu ne maîtrise pas assez ton véhicule pour te conformer au code de la route

Le code de la route dit uniquement que si tu as un clignotant tu dois l'utiliser. Il n'est nul part stipulé qu'un cycliste doit obligatoirement signaler qu'il va tourner.

Donc pareil que plus haut, je ne dis que je vais tourner que si ça ne présente aucun danger pour moi. Sinon je préfère garder ma vie.

quand tu grilles un feu en vélo, tu te prends une bonne amende et des points en moins (si tu as un permis)

Et non...
On ne peut te retirer des points que si tu fais une infraction avec un véhicule qui nécessite le permis. J'ai trouvé ça sur légifrance, il y a quelques temps (une ordonnance de novembre 92, si mes souvenirs sont bons). Par contre, tu peux te prendre une amende sans problème.

Un cas dont je n'ai pas trouvé une réponse satisfaisante est le cas où on peut te faire sauter le permis d'un seul coup. Là, je crois que même en vélo on peut te le supprimer. Ca me surprend, mais je n'ai rien trouvé qui m'indiquait le contraire.

Dans ce cas, si ça marche en local avec lynx, et que ça ne marche pas à distance, je ne pense pas que ça soit un problème du à apache. Il faut chercher au niveau réseau, système ou vaudou, à mon avis.

Je ne sais pas si je me suis bien exprimé.
Dans le cas que j'explique, ce n'est pas le fait de refaire des certificats qui va régler le pb, c'est le fait que FF ait encore des traces d'un ancien certificat qui va causer l'erreur.

C'est peut-être un avantage, non?

Je diffuse mon adresse mail, mon numéro de portable et tout ce qui permet de me joindre à mes connaissances (attention la nuance, pas uniquement à mes amis). On ne peut pas toujours choisir de ne pas diffuser son numéro, voire pire un intermédiaire donne ton numéro à quelqu'un d'autre.

Et bien dans ce ca, quand je change de coordonnées (mail, portable) je contacte moi même les amis avec qui je veux rester en relation, et j'élague avec classe les autres, qui n'ont plus moyen de m'importuner..

C'est-y pas beau, les nouveaux moyens de communication?

je pense que tu as vérifié ce dont je parlais.

Ce que je voualis dire, c'est que dans le gestionnaire de certificat de FF, tu as entre autres 2 anglets, un qui s'appelle "site web" et l'autre "autorité de confiance". C'est dans la liste de certificat de ces 2 onglets que je te proposais de voir si tu n'avais pas un certificat qui avait le nom du serveur auquel tu te connectes, avec de fausse informations. Vu l'erreur que tu as, et vu le fait que ça marche avec lynx, je suis à peu près sur que ça doit être ça.

maintenir un des fichiers (disons .bashrc) et dans l'autre placer: source .bashrc

Ca me semble plus propre, et moins source d'erreur si jamais d'aventure tu as besoin de modifier l'un et pas l'autre et que tu as oublié ta manip.

Ah, intéressant!

Regarde dans les certificats déjà enregistrés dans ton navigateur si tu n'as pas un certificat (site web ou autorité, pour FF) qui aurait déjà le nom du certificat qui est utilisé par apache. Et si c'est le cas, vire le tout de suite et sans regret, puis redémarre ton navigateur.

Raison: si tu as enregistré le certificat d'une autorité, et que sans changer de nom son certificat est modifié, tu as une erreur incompréhensible, comme ce que tu as actuellement.

Je croise les doigts, je touche du bois et de la peau de singe, mais je le sens bien, sur ce coup là.

En supposant que les et n'ont pas été affichés mais son bien présents:

Est-ce qu'il te demande bien le mdp de ta clé privée au démarrage?

Pas de problème de droit entre l'uid/gid d'apache, ceux de ta clé et certificat et ceux de ton document root?

Si tu n'as pas d'autres erreur dans ton log, je ne vois pas quoi rajouter de plus. Et au fait, c'est quoi l'erreur que tu as quand tu te connectes en https?

Sinon, question bête: tu n'as pas de firewall qui pourrait interdire l'accès au port 443?

Je vois deux possibilités:
- tu as mal donné le mot de passe de la clé privé (directive SSLPassPhraseDialog) mais je ne pense pas que ça soit ça.
- la clé ne correspond pas au certif. Tu peux le vérifier par openssl:

1) modulo identiques?
openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5
Les 2 md5 doivent être identiques (on peut le faire à la main comme pour l'exposant, mais c'est gros, donc plus pratique de passer par md5).

2) exposants identiques?
openssl x509 -noout -text -in server.crt
openssl rsa -noout -text -in server.key
et comparer les champs "public exponent" (en général 65537)

Ce n'est qu'un warn, ce n'est pas grave pour le fonctionnement. Il te faudra effectivement avoir un autre certificat pour être propre, mais ce n'est pas genant.

En fait, si tu arrives à tout configurer avec ce certificat, quand tu te connecteras via ton navigateur, tu auras un message du style: "Attention, vous essayez de vous connecter à philou83.org, alors que le certificat indique que le serveur est localhost.localdomain. Voulez vous continuer?" Et tu pourras dire oui sans problème. Après, il faudra que tu te crées un certificat qui contient effectivement philou83.org pour ne plus vaoir ce message.

Sinon, tu dis que tu as une erreur en https. C'est quoi le message que tu as?
Es-tu sur que ssl.conf est bien inclus?

Ca te vient de quel fichier? La seule chose qu'on apprend ici c'est que SSL n'est pas accessible pour ldap...

ssl_error_log te donnes quoi?

C'est sans doute trop compliqué pour ton cas (et de toute façon ça ne doit pas marcher, parce que tu as besoin du nom du fichier plusieurs fois), mais ça sert beaucoup dans d'autres cas (surtout avec des noms de répertoire avec des blancs)

find . -name "*.jpg" -print0 | xargs -0 grep

Quelle erreur est affichée?
Tu dois voir ça error_log, ou ssl_error_log.
Ca aiderait à te donner une solution.

Ou alors donne ton ssl.conf (en virant tous les commentaires que ça ne prenne pas 3 écrans).

Citation tirée d'un aimant de frigo:

Si vous ne pouvez pas être un bon exemple, soyez au moins un terrible avertissement.

- Tabbrowser extension: vital
- Adblock: vital
- AllinOneGesture: si quelqu'un connait mieux/plus léger pour les mvt de souris, je suis preneur
- Webdevelopper: super pratique, inclus editcss
- UserAgentSwitcher: sert malheureusement parfois
- ieview: sous Win, quand le précédent ne suffit pas (pour info: ouvre la page courante avec IE)
- Firesomething: inutile donc nécessaire
- I must not fear!: inutile donc nécessaire
- LiveHttpHeader
- SwitchProxy
- Digger: rajoute un menu contextuel au bouton Go (habitude de nautilus)

Pas mal, c'est vraiment joli, comme raisonnement, je n'y avais pas pensé. J'y vois seulement un souci: tu ne peux pas choisir toi même ton mdp, c'est à ta banque de le faire...

Dans le cas de la banque donnée en exemple (bon OK, eux ne donnent qu'un mdp de 6 caractères) on peux choisir son propre mdp, donc à mon avis la solution que tu proposes ne peut pas convenir...

En plus, à partir du moment où la banque connait l'algo pour recréer les 15 caractères du mdp, il n'y a pas besoin de faire d'autres manipulations.

Je pense que ton idée est bonne, mais je ne suis pas sur que ça soit qui soit utilisé dans le cas présent. A mon avis, pour utiliser ce que tu proposes, il faudrait poser plusieur fois des questions, ce qui n'est pas le cas ici.

A quoi ça sert de ne fournir qu'un bout du mdp?
Une attaque par force brute sera beaucoup plus complexe.

Pour l'exemple, je ne me place plus dans le cas précis de la banque citée, mais dans l'optique de quelqu'un qui veut implémenter ce système, de la bonne façon, et afin qu'il soit réellement solide.

Si on suppose qu'un bon mot de passe, en plus d'autres considérations, fait 8 caractères, rien ne nous empêche de créer un mot de passe de 42 caractères, et d'en demander 8 aléatoirement à chaque fois. Du coup, ce qui est demandé changeant à chaque fois, la force brute n'y pourra plus grand chose.

Exactement, c'est un peu à ça que ça me faisait penser. Je vois qu'on a les même références à ce sujet...

Cependant, dans le cas précis, ce n'est pas vraiment du 0-knowledge, car on transmet tout de même une partie du mot de passe, mais ça a l'avantage de simplifier le protocole, parce que les protocoles 0-knowledge se basent sur le principe défi-réponse, et instaurent donc un dialogue. Dans le cas du mot de passe par parties, il y juste un seul échange.

Il suffit de créer correctement le mdp de 15 carateres, qui doit etre fournit par ta banque non ?.

Je ne vois pas ce que tu veux dire...

En fait, ce qui m'intéresse, c'est de savoir comment la banque a stocké mon mot de passe (ou son hash, ou n'importe quoi qui lui permet de vérifier mes infos).

Il suffit de partir dans l'autre sens, dans ce cas là.
Si en regardant la table on détermine que le mot de passe est stocké par caractère, on se crée au chaud une table de correspondances caractères->condensé, et ça ne prendra pas longtemps à trouver tout les mots de passe.

--> paranoya ? faut bien un petit peu ;)

Vaut mieux être un petit peu paranoïaque q'un petit peu mort.

(Cité d'après je ne sais pas qui, je ne sais pas où, qu'il me soit permis ici de le remercier.)

Merci pour ces pistes, mais ce n'est pas ce que je recherche.

Je connais certaines solutions, ta solution PGP est intéressante, mais je cherche plus des infos sur une solution existante (passer un mot de passe par partie) que d'autres pistes.

De plus, dans le cas précis, ce que je cherche, ce n'est pas de ne pas passer le mot de passe en clair, mais plutôt de ne pas le passer du tout (ou tout du moins n'en passer qu'une partie).

OK, merci.
Ce qui me semble peut-être dommage, avec ce système, c'est que tu
es obligé d'avoir ta carte (ou liste...) avec toi pour te connecter. Ce n'est pas forcément un gros souci, mais j'aime bien avoir la possibilité de me connecter de n'importe où (typiquement si on me demande un RIP/RIB par surprise).

Petites questions par curiosité sur ce que tu décris.

Elle fait quelle taille, cette liste? Ils t'en renvoit une quand tu en as fini une? Ca n'a jamais posé de souci?

Dans le cas où quelqu'un son compte quasiment tous les jours, cette liste ne risquerait pas d'être épuisé trop vite?

C'est quelle banque, si ce n'est pas indiscret?

J'avais plutôt pensé à une solution de ce type par groupe de 4 caractères (si on demande 4 carcatère du mdp), mais c'est aussi trop simple à trouver je pense, sans parler du nombre d'arrangement possible, qui explose rapidement.

Intéret 1: satisfaction intellectuelle sur un procédé dont j'ai entendu parler, mais que je ne comprends pas complètement.

Intéret 2: éviter de transmettre le mot de passe, sans passer par un protocole de type 0-knowledge.