Le truc passe très bien avec un cert custom directement, mais dès que je passe par mitmproxy devant le bordel, il me pète cette erreur…
Remember you can in all cases use #CryptCheck locally for quick feedback on your service.
Native deployment is a pain (thanks to obsolete OpenSSL), but you can use the provided Docker image for that :
docker run --rm aeris22/cryptcheck:v2.2-1.1 https imirhil.fr -qj --no-ipv6
For smart people wanting to restrict the usage of #CryptCheck on their services with a mega long duration locking the current state forever, the possible delay is capped to 1 hour.
Soon, I will check for HTTP headers and HTML meta for this feature too. And perhaps for an `.well-known` entry ? 😊
The DNS TXT entry is search on each subdomain to your primary domain (thanks to public suffix list).
For example `foo.bar.example.org` look for `foo.bar.example.org`, `bar.example.org` and `example.org`
New feature in #CryptCheck to ease debug/tuning of your service.
You can put a DNS TXT record `cryptcheck=<ISO8601 duration>` to control the refresh delay for your service.
You can even put `cryptcheck=debug` to skip completly the refresh delay.
- Mais pourquoi « sudo vim /foo/bar » c’est mal ?
- Ben ton process vim est root
- Et ?
- Qui t’empêche de :e /etc/shadow ou /etc/sudoers ?
- Ah… Oui… Effectivement… 😱
Je ne comprend d’ailleurs pas qu’il cherche à monter le réseau de compose avant même d’avoir démarrer le démon système… 🤔
Quelqu’un aurait une idée du pourquoi du comment ? Et/ou de comment dire à Docker d’arrêter de pisser partout sur le système et de prendre un range précis ? 🤔
Je suis obligé de shooter le bridge à la main (ip link set down + brctl delbr), de virer le default-address-pools, de reboot docker, de refoutre le default-address-pools et de rereboot…
[…/…]
Ça démarre bien… la 1ère fois… 😑
Sur tous les reboots suivants, il tente a priori de recréer un bridge (qui semble venir d’un docker-compose), et… se taule ensuite au boot avec un
PredefinedLocalScopeDefaultNetworks List: [x.x.x.0/24]: no available network
[…/…]
Je vais bien entendu aller creuser un poil, parce que vous me connaissez bien et l’adresse email utilisé dans la prise de contact n’avait bien entendu aucune raison de se retrouver dans la moindre base professionnelle hein…
Une DCP (donnée à caractère personnel) au sens RGPD, c’est dès le cas n°3. Pas uniquement le cas n°1 comme trop de monde le pense !
- les données possiblement identifiantes (cf https://twitter.com/aeris22/status/1483123311819296774 ou https://imirhil.fr/dcp.txt), où en tant que RT vous n’avez pas (encore) conscience des possibilités d’identification
- les données identifiantes (n° de sécu, IP, plaque minéralogique…), où en tant que RT vous n’avez pas accès directement à l’identification de la personne concernée mais qu’un tiers éventuel peut vous filer
Groupe crypto-terroriste individuel auto-radicalisé sur le darknet digital
he/him (parfois undefined)