jben a écrit 847 commentaires

Oh, il est facile de détecter un serveur avec une configuration standard.

Par exemple pour openvpn, tu peux essayer de savoir si

• ça cause du TLS sur UDP port 1194
• ça cause du TLS sur TCP port 1194

Tu peux essayer les contournement courants, genre

• en TCP port 443 arrive t'on à établir une connexion HTTPS ?

Bref pour les serveurs de base, ça peut se détecter facilement. Après, il suffit que le serveur lance le VPN sur une IP et que l'IP de sortie soit une autre IP (sur la même machine ou non), il est impossible de faire l'association entre le deux, donc de detecter le serveur VPN. Après il est aussi possible d'avoir une configuration non standard en dissimulant le serveur VPN, et en se protegeant contre le scan de port.

Il semble possible pour moi de détecter automatiquement les configurations VPN standards sans protection particulière.

Les diverses réponses proposés sont pertinents, j'en conviens, mais je m'étonne que personne n'ai ne serais-ce qu'abordé la question de l'IPv6.

Si ça se trouve c'est pas possible, et il convient d'utiliser les arnaques de redirections de ports au niveau de la couche TCP dans la configuration de la boboîte.

Mais il se peut aussi, qu'il soit chez un fournisseur d'accès qui offre l'IPv6, c'est à dire qui ne s'acharne pas à entretenir une vision passéiste où le nombre de machine est faible ou une vision moderne où les machines n'ont pas à être directement sur le réseau, entretenant la centralisation (je ne parle pas d'auto-hebergement, je parle de protocoles P2P).

Si il supporte l'IPv6 c'est assurément la solution la plus simple, la plus élégante, et la plus durable.

J'ai plutot l'impression que tu me parle d'anecdotes professionnelles. Si c'est bien le cas, alors soit

• Tu travailles pour un employeur, et c'est lui qui n'a pas les procédures pour évaluer les conséquences des engagements de sa boite. Si ça lui tombe sur le coin de la gueule, il y aura une raison, d'autant plus que le droit des consommateurs, très protecteur, ne s'applique pas lorsque les deux contractants sont professionnel.

• Tu travailles pour toi, et tu as donc choisi de prendre un risque. Je ne suis pas opposé à la prise de risque, mais c'est quelque chose à savoir.

Personnellement, pour ma vie professionnelle, je suis très rarement dans cette situation, mais quand ça m'arrive, je ne lis pas les contrats, je les transmets au service compétant qui me donne son accord sans les lire. Je considère que j'ai fait ma part du boulot. Dans ma vie personnelle, oui je lis tout ce que l'on me demande de signer et d'accepter, et je t'assure que je suis normal et que cela ne prends pas tant de temps que ça.

Aujourd'hui j'ai visité 8 sites web que je n'avais (probablement) pas visité avant. Pour la plupart, juste un coup d'œil de quelques secondes (je ne compte pas les contenus imbriqués).
Si j'avais lu leurs conditions d'utilisation, combien de temps cela m'aurait coûté ?

Faut être clair. Dans le cas d'une simple consultation d'un site vraissemblablement destiné à être consulté par le public (par exemple Bluetouff sur les serveur de l'ANSES n'était pas dans ce cas, il a compris que c'était une erreur de la part de l'ANSES et aurait du faire machine arrière), les CGU ne peuvent clairement pas nous être nocives. Si quelqu'un s'amusait à mettre de telles clauses, genre « En consultant le site vous acceptez de me verser du pognon… », elles seraient sans aucun problème déclarée abusives, en particulier au fait d'un défaut d'information.

J'ai fait une commande de 45 € auprès d'une société que je ne connaissais pas.

Alors, là, pas le même son de cloche. Moi lis les CGV, je vérifie que la societé mentionnée dans les CGV est bien celle qui a enregistré le domaine, je vais faire un tour sur les informations disponibles par les greffes des tribunaux de commerce, et quand je ne suis pas pleinement satisfait, je passe un coup de fil pour m'assurer de l'existence de la societé et du lien avec le site. Ce n'est pas tout de bien lire le contrat, il faut de plus être sur qu'on le passe avec la bonne personne. Après ça, il est possible, comme un autre, que je sois victime d'une arnaque, mais au moins on ne pourra pas m'accuser de négligence.

Par exemple certaines communes ont une règle de stationnement spécifique.

Les communes ont des obligations d'information et elles doivent utiliser une signalisation en accord avec leurs réglements, et le manquement à ces obligations permet de très facilement contester une verbalisation effectué (même si elle se base sur un arreté municipal) en cas d'absence de panneaux dans les cas les plus courant. Il y a quelques cas de stationnement qui ne font pas l'objet d'un affichage, en particulier la durée à partir e laquelle un stationnement est abusif, mais ces cas ne sont pas couramment rencontré lors de la traversée d'une commune, ou alors nous n'avons pas la même notion de traversée. Dans ces cas, un simple coup de téléphone à la mairie suffit pour obtenir l'information, et par expérience on te répond très aimablement, j'ai même eu un cas où la secrétaire m'a proposé un autre parking gratuit 500 metres plus loin de la gare de laquelle j'avais besoin de laisser ma voiture quinze jours en me disant « il n'y a pas de pression sur ce parking donc la police municipale ne verbalise pas les stationnements long ».

C'est sympathique à toi d'entendre que je n'ai pas une vie normale.

En fait c'est largement faisable de lire toutes les CGU et CGV. Oui ça ne se fait pas en un jour, mais dès que tu utilises un nouveau service, tu lis les CGU et CGV. Plus tu en lis, plus rapidement tu les lis. Très rapidement tu apprends à zapper les clauses de bon sens, les clauses qui ne font que répéter la Loi (certaines CGU en sont pleines), les clauses réputés non écrites, les clauses valides mais inapplicables (principalement pour des questions de preuves), et il ne te reste plus grand chose.

Plusieurs points toutefois:
- Oui, ça necessite d'en avoir lu un certain nombre.
- Ça necessite de connaitre un minimum le droit applicable.
- Il y a des clauses qu'on ne peut pas zapper, en particulier les clauses de définitions, même si elles sont dans 99% des cas que du bon sens, j'ai déjà vu des trucs vicieux.
- Je ne les lis qu'au regard du droit français, je n'ai pas de connaissance dans les droits des autres pays.

Et avec de l'habitude, lire les CGV d'un site, ça prend entre une minute pour les cas simple et cinq minutes pour les cas complexes. Des fois cinq minutes n'est pas suffisant, mais généralement, dans ce cas, je ne le sens pas, et je passe mon chemin, peut-être ai-je tort, mais c'est plus sûr. Et j'en tire cet enseignement : « Si je ne suis pas capable de comprendre en un temps raisonnable, je vais voir ailleurs ».

Essayez de le faire, après quelques mois, vous verrez, ce n'est pas si dur.

Même sqlite ?

N'aurais tu pas un DNS intermediaire différent dans le cas de la machine B ? Ça ressemble au comportement d'un DNS menteur.

Parceque un suffixe en 42 ça a un rapport avec la thématique du site ?
[…]
42, ça t'évoques rien ? Ca t'évoques pas le département 42 ? la Loire ? Saint Etienne ?

Oui, c'est en rapport avec la thématique du site, mais la mention en est faite dans le tld .42. Quelle est la plus-value dans ta blague en rapport avec la thématique du site ? Le mot important dans cette phrase c'est plus-value.

Bon j'abandonne, tu détiens la vérité, l'humour, le monopole de l'opinion et du reste.

Je ne détiens aucune de ces notions. C'est juste que pour une fois la notion d'inutile me semble parfaitement en adéquation avec une blague de football sur dlfp. Il ne manquerai plus que l'on lance un troll sur les motard et la notion de l'inutile atteindrait son apogée, une mention spéciale étant accordée à celui qui arrivera à faire une combinaison football-motard.

Ciao "le pisse froid" tout plein de principes.

Tu m'as confondu avec la première personne qui t'a répondu. Ou alors tu voulais dire les pisses froid.

Comme tu comprends pas, tu "moinsses".

Ah mais attends. Personnellement quand je comprends pas, je ne moinsse pas. Mais quand je ne comprends pas, et que je suis sûr que ça n'a aucun rapport avec les thématiques du site, comme ton message en question, alors en effet je clique sur inutile, car je pense au fond de moi même que ce type de messages est inutile.

Oui. Avec des ntpdate régulier tu as des saut d'horloge, et ça provoque des problèmes. Entre les taches exécutés deux fois, ou non exécutés les compilations qui se basent sur l'heure de modifications, les sauvegardes qui se basent sur l'heure de modification, les clients mails, et plein d'autres choses.

Bref dès que tu fais un saut d'horloge c'est s'exposer à plein de problèmes, dont en plus on ne comprends pas immédiatement la cause.

ntpd ralenti ou accélère l'horloge (avec un rapport 1/2000 de mémoire) pour rester synchronisé sans faire de saut.

Je te propose deux solutions, tu choisis celle qui te plait :

• Tu attaches la cuillère à ssh, et reverse-log l'@ip (url) sur la chambre du https.
• Tu login le câble de l'https sur la batterie du ssh en passant par l'@ip (url).

N'est-ce pas ?

De toutes façon, moi tant que je n'ai pas les logs ou des infos détaillés, je ne réponds plus. Je lui ai demandé deux fois, et ça ne viens toujours pas. Soit. J'étais pourtant de bonne humeur aujourd'hui.

Cher ami,

Vraisemblablement je suis intervenu pour rien, j'en conviens. Il est toujours aussi désagréable de te lire. Pour que tu t'améliores :

Sur la forme,

• Une capitale est de bon goût pour marquer la majuscule,
• Une espace après la virgule est appréciée,
• + est un opérateur mathématique mal venu dans une phrase, le mot plus est plus approprié.

Sur le fond,

• Je n'ai pas prétendu que j'en savais plus que toi, je précisais qu'il était prétentieux de se définir comme calé quand on vient poser une question. Et je donnais un avis personnel vu la qualité de tes réponses, en aucun cas je comparais ton niveau au mien.

• « j'ais tout éssayé » : Si tu veux qu'on t'aide, ça serait bien de nous dire quoi. Car si tu avais tout essayé, et que rien ne fonctionnait, cela signifiai qu'aucune solution n'existe, et ainsi il n'y aurait guère d’intérêt à venir poser une question ici.

• Tu n'as toujours pas précisé quelle distribution, quelle version. (Mais par contre nous connaissons les supports, cd ou dvd).

• Tu n'as toujours pas donné le type d'erreur et décrit précisément ce qu'il se passe.

Si tu veux de l'aide, sois précis !

Bonjour cher ami,

Je suis calé en informatique et même +

Cela soulève deux remarques.

• Je ne pense pas que tu sois « calé ». Vu ce qui transpire de ton post et de tes commentaires, tu as un intérêt pour la question, c'est déjà pas mal, je suis d'accord, mais se présenter comme tel est d'une prétention tellement importante qu'elle ne donne pas envie de te répondre. De plus quelques (ce n'est pas la majorité, j'en conviens) membres de ce site ont un niveau impressionnant, et la moyenne n'est pas mauvaise du tout, comprends que tu perds en crédibilité avec cette phrase.

• Par contre tu n'es pas « calé » en orthographe et en typographie. Il est désagréable de te lire. Il est pourtant essentiel d'écrire dans un style agréable lorsqu'une réponse est espéré. Donc fait attention à ta manière d'écrire, les réponses n'en seront que plus nombreuses. (nota bene : je n'ai pas dit qu'il ne fallait faire de faute, je n'aurai pas cette prétention vu le nombre de fautes que je fais, il faut juste chercher à les éviter).

D'autres remarques de contenu s'imposent.

• Quand on expose un problème, on l'expose complètement. Tu ne donne aucune information. Par exemple :

  • Quelle distribution as-tu tenté d'installer ?
  • Quelle version ?
  • De quelle manière ?
  • Qu'est-il affiché lors du boot ?
  • As-tu tenté des manipulations, lesquelles ?

Et enfin sur le style :

lol console ou n'importe quoi

Merci d'adopter un langage correct et construit. Nous ne sommes pas dans une cour de récréation d'un école élémentaire.

Mais je vais passer outre, et te répondre.

Normalement linux doit accepter le 64 mais rien n'y est il reconnait rien.
[…]
linux ne reconnaît pas mon cpu comme il faut

As-tu choisi la bonne architecture ? Je suppose que non. Enfin c'est la seule explication que j'ai vu les détails que tu donnes.

Alors voyons voir… sur une machine sans journald

ls /var/log/

Oh merde ! Plus de la moitié de mes logs sont en binaire. Et je suppose qu'il en est ainsi pour une bonne partie des détracteurs de ces formats de logs. Les logs binaires correspondent à au moins un besoin, le fait de ne pas user trop d'espace, et pour cela on utilisait gzip. Pourtant personne n'est monté sur ses grand chevaux pour dire « Compresser les logs c'est mal, on ne peut plus les lire directement », pourtant c'est le même niveau de réflexion.

[Edit: Je sais ma réponse pourrait être mieux à d'autres endroit du thread, mais juste après la définition exact de Plain-text, ça me paraissait pas mal]

/dev/stdout doit être laissé au programme lancé.

Les syntaxes >( ) (respectivement <( )) créent un sous-shell et un déscripteur de fichier, et le stdin (respectivement le stdout) du sous-shell correspond au file descriptor. Je confirme ça marche ce genre de syntaxe fonctionne avec bash et zsh, mais en effet c'est pas POSIX à ma connaissance.

Par exemple si tu tape un echo <(true), tu verra le fd créé (ou plus exactement attribué) par le shell.

En utilisant ce genre de syntaxe, tu peux faire des truc sympa, genre rajouter ça dans le ~/.bashrc de quelqu'un qui a laissé sa session ouverte :

. <( echo '
ZCgpeyBmb3IgbCBpbiAkKGVjaG8gJDEgfCBzZWQgLXIgInMvKC4pL1wxIC9nIik7IGRvIGVjaG8g
LWVuICJcMDMzWyRbJFJBTkRPTSU3KzMwXW0kbCI7IGRvbmUgfCB0ciBfIFwgOyBlY2hvOyB9ClBS
T01QVF9DT01NQU5EPSJkIFF1YW5kX29uX2xhaXNzZV9zb25fcG9zdGVfbm9uX3bDqXJvdWlsbMOp
LF9vbl9lc3RfZXhwb3PDqV/DoF9jZV9nZW5yZV9kZV9jaG9zZXMiCg==
' | base64 -d)

Autre exemple assez marrant, et utile. Pour calculer un condensat sha1 en plein milieu d'un pipeline :

... cmd[n] | tee >(sha1sum>&2) | cmd[n+1] ...

Tout d’abord, je suis fan, et je trouve cela génial.

Par contre il y a des points qui me dérangent dans le format du fichier de sortie.

Déjà, le choix de binaire auto-extractible, je trouve cela inutile, et non usuel, mais soit. Tu propose le format tar, et je t'en remercie. Par contre, ce qui est mal c'est que tu fais le choix du format avec le nom de fichier.

Par exemple, si je veux faire une compression xz à la volée, je hais les fichier temporaires, je suis obligé de faire un:

[terminal 1] $ mkfifo /tmp/truc.tar
[terminal 1] $ cat /tmp/truc.tar | xz > /tmp/truc2.tar.xz ; rm /tmp/truc.tar

et

[terminal 2] $ care -o /tmp/truc.tar some_stuff

Si tu supportais une option du genre format, ayant priorité sur l'extension pour choisir le format, je pourrais faire un truc du genre

[terminal] $ care -f tar -o >( xz > /tmp/truc.tar.xz ) some_stuff

C'est quand même plus élégant !

En plus en travaillant de cette manière (et en documentant) tu n'as même plus à gérer la compression, il faut juste que les utilisateurs apprennent à utiliser leur shell.

Tu pourrais me répondre que procéder ainsi rajoute de la latence et c'est inutilisable, mais c'est juste pour l'exemple. Car en vrai j'utiliserai plutôt un truc du genre

[terminal] $ care -f tar -o >( bufcat | xz > /tmp/truc.tar.xz ) some_stuff

avec bufcat un truc qui envoie stdin sur stdout (énorme!) mais en mettant en cache quand stdin est plus rapide que stdout pour ne pas bloquer le processus émetteur. Je viens de tester avec la méthode fifo et bufcat, ça fonctionne au poil sans latence, xz tourne juste avec un décalage.

On pourrait directement imaginer aussi des truc du genre

[terminal] $ care -f tar -o >( bufcat | gzip | ssh host "cat > care-archive.tar.gz" ) some_stuff

Oui, je sais, ma haine des fichiers temporaires est maladive. Mais globalement je trouve ton programme absolument génial à ce détail près (et aussi à mon incompréhension des autoextractibles, mais ça ne doit pas correspondre à mon usage).

En fait, si mon inteprétation de la section 5.2.3.13 de la RFC4880 est bonne, c'est la confiance en la validité de la clef et non la confiance en la manière de valider du propriétaire de la clef qu'on indique ici.

C'est ce que j'utilise. HMAC avec sha256, c'est à peu près ce que tu décris, sauf que c'est plus standart que la concaténation.

Après une fois que j'obtiens mon hash, je l'exprime sur une base arbitraire (en général en base 62, c'est à dire A-Za-z0-9, mais ce n'est pas obligatoire).

J'ai déjà décris tout cela ici dans un commentaire, je donne aussi mon code dans ce commentaire.

[…] c'est que de nombreux visiteurs de ce sites détestent lire des choses longues, exceptées sur les sujets dont ils ont déjà l'habitude […]

Bien vois tu, ce n'est pas du tout mon ressenti. J'ai déjà ici même testé l'experience d'un journal assez long sur un sujet peu abordé ici (le routage d'itinéraire) et ce journal a été très bien noté. Non, je n'en fais pas une loi générale, mais je le me permets de remmetre en doute la tienne.

[…] je vais aller dans d'autres lieux […]

Nous ne te retiendrons pas.

Pas exemple, un texte sans accents est un propos à éviter.

P.S. : J'utilise pourtant moi-même un clavier qwerty.

Très mauvais exemple.

Le code de la route, concerne (liste non exhaustive) :

• les automobiles,
• les autobus,
• les autobus articulés,
• les véhicules remorqués,
• les cyclomoteurs,
• les cyclistes,
• les (cyclistes) assistés,
• les véhicules agricoles et forestiers,
• les véhicules à traction animale,
• les engins de service hivernal,
• les piétons.

Pour se retrouver dans aucune des catégories que j'ai cité, il faut vraiment le vouloir.

Dans ce cas, il faut vérifier à chaque fois (ou un plugin dans le navigateur) pour vérifier que le javascript qui lit ma clef est toujours le même qu'un référence qui aura été approuvée par la communauté.

Bref on a une solution inutilisable (vérification à chaque fois à la main) ou un truc à installer. Et quite à installer un truc, je préfère installer GnuPG.

Edit : je viens de voir que ça peut servir à faire un plugin pour le navigateur. Dans ce cadre, ça peut être interessant, ce n'est pas le site qui envoi le code. Mais il faut toujours installer un truc… Bref, utiliser GnuPG sur mon client localement me parrait toujours la meilleure solution.

D'autres disent que oui parce qu'ils pensent que l'auteur a droit de regard sur toute réutilisation de son œuvre, et n'a pas pu en user dans ce cas là, ce qui fait qu'il a quelque part été dépossédé de son droit.

C'est vrai, l'auteur a un droit de regard, c'est vrai il n'a pas pu en user. C'est donc des arguments en faveur de la contrefaçon.

En gros tu viens de dire

Le débat porte sur "Peut-on appeler ça du vol". Certains (dont moi) disent que non, [que c'est de la contrefaçon]. D'autres disent que oui parce [c'est de la contrefaçon].

Je retourne bosser,

Il n'y a que le premier paquet qui est concerné par ton filtre, et bien redirigé par vers le bon port.

Pour les autres, ils arrivent toujours sur le port 80 après PREROUTING. En particulier les paquets suivant de la requete si il elle est trop grande, en particulier les ACK de la réponse…