Vos concurrents vous cachent des choses. Enfin, j'crois ^^
Leur infrastructure secrète, leurs projets en cours, leurs lancements prévus... Et pourtant, une bonne partie de tout ça est en fait visible si on sait où regarder...
Comment ? Grâce aux logs Certificate Transparency, c'est-à-dire les registres publics où les autorités de certification reconnues par les navigateurs enregistrent les certificats SSL qu'elles émettent.
Du coup, quand une boîte prépare un nouveau service sur staging.secret-project.example.com, hop, le certificat SSL est enregistré dans les logs CT et devient visible pour qui sait chercher. Et c'est exactement à ça que sert CertRadar , un outil gratuit qui va fouiller ces logs pour vous.
Perso j'adore ce genre d'outil pour le pentest et la veille concurrentielle. Vous tapez un domaine et bam, vous récupérez une bonne partie des sous-domaines qui ont eu un certificat SSL. Y'a de quoi faire pleurer un admin sys qui pensait que son serveur de dev était bien planqué !
CertRadar propose plusieurs modules. Le Cert Log Search qui est le coeur du truc, fouille les logs CT pour trouver les certificats émis pour un domaine. Le TLS Scanner analyse la config TLS de n'importe quel serveur (versions supportées, ciphers, tout ça). Le Header Search inspecte les en-têtes HTTP. Y'a aussi un RDAP Lookup pour les infos whois, un Domain Health pour vérifier la santé globale d'un domaine, et même un Multi-Domain Report pour analyser plusieurs domaines d'un coup.
Maintenant, mettons que vous voulez cartographier l'infrastructure de votre concurrent. Vous entrez leur domaine principal dans le Cert Log Search, et vous récupérez une liste de leurs sous-domaines visibles dans les logs CT : api.example.com, staging.example.com, admin-panel.example.com, dev-v2.example.com... Certains noms sont parfois très parlants sur les projets en cours !
D'ailleurs, si vous cherchez d'autres méthodes pour trouver les sous-domaines d'un site , j'avais déjà parlé de SubFinder qui fait ça en ligne de commande.
La différence avec CertRadar c'est que tout se passe dans le navigateur, pas besoin d'installer quoi que ce soit. Vous allez sur le site, vous tapez votre requête, et vous avez vos résultats. Hyper fastoche.
Pour ceux qui font de la sécu, c'est clairement un outil qui a sa place dans votre arsenal. La partie Cert Log Search et RDAP c'est de la reconnaissance passive pure, vous ne touchez pas aux serveurs cibles. Par contre le TLS Scanner et le Header Search vont activement interroger les serveurs, donc à utiliser uniquement sur des domaines où vous avez l'autorisation. Vous pouvez découvrir des endpoints oubliés, des serveurs de staging exposés, des APIs non documentées... Bref, tout ce que les équipes IT auraient préféré garder discret.
Et comme les logs Certificate Transparency sont publics par design (c'est fait pour améliorer la transparence et détecter les certificats frauduleux), consulter ces données est parfaitement légal. James Bond peut aller se rhabiller, la vraie surveillance se fait en open source maintenant !
Si vous voulez jouer les espions légaux, c'est cadeau les copains. Comme d'hab que du bon ici ^^
Orange reporte d’un an la fermeture commerciale de son réseau ADSL pour environ 8 000 communes françaises. Initialement prévue plus tôt, la possibilité de souscrire à un nouvel abonnement ADSL est désormais maintenue jusqu’au 31 janvier 2027 pour ces zones et cela s’explique par l’absence de fibre optique. …
Aimez KultureGeek sur Facebook, et suivez-nous sur Twitter
N'oubliez pas de télécharger notre Application gratuite iAddict pour iPhone et iPad (lien App Store)
L’article Orange retarde la fin commerciale de l’ADSL faute de fibre optique suffisante est apparu en premier sur KultureGeek.
XCA is an x509 certificate generation tool, handling RSA, DSA and EC keys, certificate signing requests (PKCS#10) and CRLs. It supports a broad range of import and export formats.
Lorsque votre certificat SSL est compromis (par exemple parce que sa clé privée a été volée), vous pouvez le révoquer, c'est-à-dire le signaler comme étant invalide et plus digne de confiance.
Mais comment le navigateur sait-il qu'un certificat est révoqué, car ce n'est pas une information que celui-ci contient ? Deux mécanismes existent : CRL et OCSP.
Cet article les présente ainsi que les problématiques liées.
ÉDIT : OCSP a depuis été déprécié en faveur de CRL : https://www.abetterinternet.org/post/replacing-ocsp-with-crls/
Lorsque vous achetez un certificat SSL, il n'est pas rare que des garanties, des assurances, soient proposées pour couvrir certains dommages pouvant résulter de mauvais usages. Quels usages ? Est-ce que ces assurances servent vraiment à quelque chose ?
Les courbes elliptiques, c’est la promesse de la robustesse des communications chiffrées de TLS sans la lourdeur des tailles de clés utilisées avec l’algorithme RSA. Il ne sera pas question de mathématiques aujourd’hui (je suis trop mauvais pour ça, vous avez qu’à voir Wikipedia pour ça), juste de quelques notes sur leur utilisation, pour du certificat autosigné, de la vérification, et un micro rappel de Let’s Encrypt.
Faites une petite recherche rapide, et 99,9% des tutos pour générer un certificat, que ça soit pour de l’auto-signé, ou dans le cadre de la commande chez une autorité « classique », et vous aurez du RSA avec un panel de 2048 à 4096 bits de taille de clé. Sans faire de benchmark, je peux vous assurer que si 2048bits est assez classique, 4096 ça commence à être assez lourd à gérer. Les courbes elliptiques sont des objets mathématiques qui promettent de garder la complexité mathématique, clé de la robustesse en matière de cryptographie, mais avec une taille de clé beaucoup plus réduite, ce qui permet d’améliorer la consommation de ressources et la performance du chiffrement des communications, parce que c’est le contexte dans lequel elles ont été envisagées et déployées.
Typiquement, pour déployer un virtualhost « par défaut » sur mon serveur web Nginx, j’ai voulu générer un certificat auto-signé certes, mais avec les courbes elliptiques comme base cryptographique. C’est plutôt simple au final, ça se joue en à peine plus de temps, ça repose sur l’incontournable OpenSSL, malgré les problèmes qu’il pose ces dernières années, surtout en tant que bibliothèque applicative. On commence par lister les courbes disponibles :
openssl ecparam -list_curves
Vous choisissez ce que vous voulez, pour des raisons de compatibilité, j’ai sélectionné secp384r1 qui est la plus utilisée derrière sa petite sœur en 256bits et qui est nommée prime256v1 (parce que nique la cohérence, hein). C’est au passage celle que j’utilise sur le blog 
Ensuite, on fait les étapes classiques pour un autosigné :
openssl ecparam -genkey -name secp384r1 -out key.pem openssl req -new -sha256 -key key.pem -out csr.csr openssl req -x509 -sha256 -days 365 -in csr.csr -out certificate.pem
Pendant la phase de création du CSR, vous répondez comme vous le souhaitez aux questions, comme on est sur de l’autosigné vous pouvez être créatif si ça vous chante 
Et voilà, vous n’avez plus qu’à renseigner la clé et le certificat dans votre Virtualhost par défaut, comme ça, si vous interrogez l’IP de votre serveur web, c’est ce certificat « placeholder » qui apparaitra (autosigné certes, mais certificat quand même) et ça masquera le reste de vos virtualhosts, parce que sinon le serveur web présente le premier chargé dans les configurations incluses (je me demande si j’en ferai pas une démo en live tiens…).
Oui je sais ça parait con, mais ça m’est déjà arrivé une quantité beaucoup trop importante de fois de ne pas être certain qu’un nouveau certificat à installer correspond encore à la clé qui est déjà déployée, ou si une nouvelle clé à été générée pour l’occasion. La joie de l’infogérance et des tickets traités par plusieurs admins successivement.
Idem, quand on cherche les manipulations à effectuer, on trouve quasi systématiquement la méthode basée sur le modulus. Sauf que cette méthode est propre à l’algorithme RSA, et n’est donc pas applicable pour des courbes elliptiques. Malgré tout, on peut s’en sortir. L’astuce consiste cette fois à comparer la clé publique entre la clé et le certificat. D’abord pour la clé :
openssl ec -in key.pem -pubout |openssl md5 openssl x509 -in certificate.pem -noout -pubkey |openssl md5
Si les deux résultats sont identiques, vous pouvez les charger dans le serveur web (ou dans l’interface de votre fournisseur d’infrastructure, si vous êtes dans le claude).
Let’s Encrypt (et certainement d’autres fournisseurs) supporte les courbes elliptiques depuis un moment déjà. Personnellement, je préfère utiliser le léger acme.sh plutôt que l’officiel certbot, que je trouve particulièrement lourd. La génération est plutôt simple :
acme.sh --issue --ecc -k ec-384 -d www.domain.tld -w /var/www/ --debug
Évidemment c’est à adapter au domaine, et au dossier par lequel il va bosser le challenge. Perso je préfère ensuite faire une installation dans un dossier dédié pour inclure la commande de rechargement du serveur web derrière :
acme.sh --install-cert -d domain.tld --fullchain-file /etc/nginx/ssl/domain.tld.crt --key-file /etc/nginx/ssl/domain.tld.key --reloadcmd "systemctl reload nginx"
Voilà, comme on le voit, il ne faut pas grand chose pour passer à cette méthode cryptographique, et investiguer à son sujet est à peu près aussi simple qu’avant. Juste je trouve qu’il y a vraiment peu d’articles qui incluent les courbes dans les manipulations. Bon ben voilà 
Connexion