292 private links
A cybersecurity researcher has published proof-of-concept (PoC) exploits for two unpatched Microsoft Windows vulnerabilities named YellowKey and GreenPlasma, which are a BitLocker bypass and a privilege-escalation flaw.
"The result of this is that the X:\Windows\System32\winpeshl.ini is deleted, and when Windows Recovery is entered, rather than launching the actual Windows Recovery environment, it pops up a CMD.EXE. With the disk still unlocked" - Will Dormann
The websites must renew their certificates. Certificates are issued for two years but it's hard to renew certificates after two years! Let's Encrypt came up with a brilliant idea: all certificates are valid for only 90 days.
It has two advantates: it rotates the private key every 90 days and it pushes website owner to automate the renewal process.
In case of private key compromission, there are two methods to revoke the certificates: CRL and OCSP.
In principle, CA certificates themselves carry this information, informing clients that when verifying a certificate, they should visit this URL list to check if the certificate they are validating is in the revocation list. If it is, they should not trust it.
The CRL provides exactly that with the DER format.
The OCSP method needs to verify every URL of each certificates. This method has downsides:
- The website's performance will decrease due to the additional time required for CA requests. The OCSP servers could become htspots and might be overloaded by clients.
- The CA will know which domain names the client has accessed.
- If the CA's OCSP service is down, the client has two choices: ignore verification or no trust the target site.
There can be workarounds with the OCSP Stapling: the website itself query the CA's OCSP service and when a client visits the website, the website provides the OCSP response.
All of these methods works if the CA can be trusted. WoSign had for example a chaotic organization that issued certificates for websites directly, whereas the CA should have issued certificates for Chinese users only.
That's what Certificate Transparency (CT) should address after the DigiNotar incident in 2011.n CT must log the issued certificate in a CT database and the CT will provide a Signed Certificate Timestamp (SCT) back to the website. The clients will only trust certificates that have an SCT when visiting websites and websites (and everyone) can monitor the CT database to check if any certificates have been issued for their domains.
The client must have CA Root. Once the CA Root is verified, the client cana trust the certificates signed by the root and its other intermediate certificates.
Verification starts from the certificate of the domain. If it’s valid, the client verifies its issuer, and continues this process until reaching a certificate where the issuer is itself, indicating it is a Root.
For lyokolux.space, it goes as follow:
$openssl s_client -showcerts -connect lyokolux.space:443 -servername lyokolux.space 2> /dev/null | grep -A1 s:
0 s:CN = lyokolux.space
i:C = US, O = Let's Encrypt, CN = E8
--
1 s:C = US, O = Let's Encrypt, CN = E8
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1lyokolux.space is certified by Let's Encrypt. Let's Ecrypt is certified by the root certificate ISRG Root X1. The browser also tells ISRG Root X1 is a Certificate Authority.
Following the incident of DST Root CA X3 with a notable certificate expiration, the browsers started to trust Let's Encrypt directly. It seems openssl does it too because we don't see the certificate of ISRG Root X1 in the openssl output. The let's encrypt certificate is trusted because of ISRF Root XA.
- A certificate can have only one issuer because the issuer is a fixed field in the certificate, not a list.
- The essence of signing is just appending a hash value encrypted with a private key.
- Intermediate certificates are not directly trusted by clients; clients only trust Root CAs.
To increase security, a certificate can be cross-signed and verified by one or the other sources. It's up to the client or the software to trust root certificates. When the client further narrows down the trusted list to only its certificates (or its CA), this is Client Certificate Pinning. For example, the TikTok app uses this.
Next: https://shaarli.lyokolux.space/shaare/13012
Previous: https://shaarli.lyokolux.space/shaare/1ar20g
Cette nouvelle méthode permet de sécuriser plus rapidement Firefox, puisque l'IA montre une faille et essaie de résoudre le problème. Cela sert de base de travail.
Their relationship is:
- The client trusts the CA (for example Let's Encrypt)
- The CA issues certificates to websites (often certified by the industry standard ACME Challenge) .
- When a client visits a website, the website presents its certificate. Since the client trusts the CA, it also trusts the certificate issued by the CA.
To adress a privacy key leak by the CA, they often use intermediate certificates. That's the standard x509. The CA:FALSE value on certificates issued to entities means that even if they issue a certificate, it won't be trusted. So only root and intermediate certificates can be trusted to issue other certificates.
To trust a CA, the client store the CA locally.
Two posts follows:
The point is many actors can detect the flaw during the same week. A 90 days window to deliver a fix no longer holds
Another security vulnerability similar to copy.fail
Dans ce cas, séparer directement la commande curl de bash afin d'auditer le script téléchargé. Le serveur peut être malhonnête et renvoyer différent contenu selon le User Agent de Curl ou d'un navigateur web.
Il est possible de détecter le curl | bash via une commande sleep.
L'auteur à une démo locale.
Faire confiance au projet pour livrer un script bash honnête revient aussi à faire confiance:
- au domaine
- au DNS
- à l’hébergement
- au CDN
- au compte GitHub
- aux secrets de CI/CD
- au pipeline de release
- aux dépendances
- aux mainteneurs actuels et futurs
- à l’absence de compromission au moment précis où vous exécutez la commande
Another supply-chain attack.
According to new reports by Aikido and Socket, the compromised packages were modified to include a malicious 'preinstall' script that executes automatically when the npm package is installed.
That's why it's pertinent that https://npmx.dev lists these postinstall scripts
GTFOBins is a curated list of Unix-like executables that can be used to bypass local security restrictions in misconfigured systems.
La Deutsche Telekom Red Team vient en effet de publier Pack2theRoot (CVE-2026-41651), une faille notée 8.8/10 qui permet à n'importe quel utilisateur local de devenir root sans mot de passe.
Source:
C'est clairement une mauvaise idée
hashing: SHA-512
Password or one time code hashing: Argo2id
Key derivation: SHAKE256 or HKDF-SHA512
Api key: prefix + version + Base32LowerCase.encode(UUID || 32-byte secret); hash function: SHAKE256 with a 512 bit output, or SHA3-512 or SHA-512
Encryption: AES-256 has too short nonces, jey / nonce reuse is catastrophic and it's also lacking context commitment. XChaCha20-Poly1305 lacks context commitment, that's why ChaCha20-BLAKE3 is recommended.
Encrypting secrets: use a Key Management Service
Symmetric Key signature: HMAC-SHA512
Asymmetric key signature: ML-DSA-65, or ML-DSA-87
JSON Web TOkens: ML-DSA-65 for asymmetric signatures or HMAC-SHA512 for symmetric signatures
End-to-end encryption
While you probably need more advanced protocols for your specific use case (e.g. The Messaging Layer Security (MLS) Protocol, RFC 9420, for messaging), basic end-to-end encryption to a public key has been standardized in RFC 9180 - Hybrid Public Key Encryption (HPKE). In this context hybrid means that we combine both symmetric and asymmetric cryptography.
Therefore, I recommend the following algorithms for use with HPKE to encrypt data to a public key:
- KEM: X-Wing
- AEAD: AES-256-GCM
- KDF: HKDF-SHA512
TLS
Today, the only quantum-resistant key exchange algorithm available for TLS is the hybrid X25519MLKEM768. Ensure that your load balancers / reverse proxies support it.
« Les attaquants bénéficient d’un avantage asymétrique, puisqu’il leur suffit d’exploiter une seule brèche», alors que les défenseurs doivent couvrir une surface d’attaque qui n’est certes pas infinie, mais suffisamment étendue pour laisser des trous dans la raquette. Les développeurs de Firefox ne peuvent pas se permettre de « réécrire des décennies de code en C++ ».
De l'autre côté, l'IA peut détecter ces failles rapidement. Il est probable que ce genre de détection de faille soit inclus dans les processus avant la livraison d'une nouvelle version par exemple.
l’éditeur PDF intégré, qui permet de réorganiser, copier, coller, supprimer et exporter des pages dans un document PDF.
Oh pas mal
I did not install any Anthropic browser extension. I have never installed a Claude browser extension due to privacy and security concerns. I did install Claude Desktop, the Mac app, a while back. That is the only thing on this machine which could have written the file. Claude Desktop reached into Brave, a browser from a completely separate vendor, and registered a back door for a browser extension I do not have.
and the security risks involved is concerning.
"stateless" authentication simply is not feasible in a secure way. You must have some state to handle tokens securely, and if you must have a data store, it's better to just store all the data.
The reason to avoid JWTs comes down to a couple different points:
- The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions need to have longer lifespans than that.
- "stateless" authentication simply is not feasible in a secure way. You must have some state to handle tokens securely, and if you must have a data store, it's better to just store all the data. Most of this article and the followup it links to describes the specific issues: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
- (Yes, people are doing it, and yes, their applications are flawed, and you should not repeat that mistake.)
- JWTs which just store a simple session token are inefficient and less flexible than a regular session cookie, and don't gain you any advantage.
- The JWT specification itself is not trusted by security experts. This should preclude all usage of them for anything related to security and authentication. The original spec specifically made it possible to create fake tokens, and is likely to contain other mistakes. This article delves deeper into the problems with the JWT (family) specification.
Typo-squatting: using URLs is a false solution. "By making crate IDs longer, whether by namespacing within crates.io, GitHub organizations, or via domains, you only make it harder for users to remember them precisely, and thus harder to recognize typo-squatting."
Sandboxing can not be handled by the language itself.
It's the developer responsability to use crates on crates.io. It's an audit to make. Rust provides tool for it: cargo-vet, crates.io 90 day download plot, cargo chef or Nix to build isolation.
Also Rust itself does not have the resources for it at the moment. They simply can't. The compiler and std are primarily developed by volunteers, who don’t get anything out of it except for rare donations from other members of the community. The Rust project is not the same as GitHub or Linux. They don't have the same support.
We’re not nearly close to the level of security a centralized registry can provide. On the software side, in 2025 Rust teams made or piloted tools for typo squatting detection, dynamic build script analysis, and real-time code scanning. On the personal side, Rust Foundation hired on-call engineers in 2025 and a second infrastructure engineer in 2026. If that sounds overdue, well, they had net loss in 2023 – software isn’t cheap.
le FBI a réussi à extraire et lire des messages Signal d’un iphone à l’aide de techniques de forensic.
car l'aperçu des notifications est stocké en clair dans une base de données locale du système.
Signal est ici pas en cause, mais bien le stockage des aperçus de notifications.
Si vous utilisez un iPhone, quelques réglages simples peuvent limiter les dégâts :
- Dans Signal → Notifications → “Ni le nom ni le message”
- Dans iOS → Notifications → Signal → désactiver les aperçus ou les limiter à “Quand déverrouillé”
Et surtout, il faut déconstruire une idée reçue tenace : celle de “l’application magique” qui réglerait tous les problèmes de sécurité. C’est une illusion dangereuse.