Technique si vous recevez du spam clairement illégal.

1. Prendre le nom de domaine de l'adresse email (après le @)
2. Rechercher ce nom de domaine sur whois https://www.whois.com/whois/
3. Regarder la ligne "Registrar Abuse Contact Email" (ou dans le groupe Registrar Information, la ligne Abuse Email)
4. Transmettre le mail frauduleux, et donner un peu de contexte dans le mail. Le service devrait faire le reste

Signal client uses SQLcipher database to store conversation messages. Since SQLcipher
is essentially SQLite with encryption, it inherits SQLite features.

To update the database, SQLite (and consequently SQLcipher) uses Write-Ahead Logging.
All transactions are written to a Write-Ahead Log file, which is then merged to the
main database file when a certain number of pages are written to the log file, the
database is manually checkpointed, or the database file is reopened.

This results in an unexpected situation when messages are deleted in Signal, either
manually or by a timed deletion. The deletions from the database are recorded to the
Write-Ahead Log file, but they are not actually deleted from the database file until
the Write-Ahead Log is committed back to the main database.

By default, the Write-Ahead Log has a threshold size of 1000 pages. Depending on how
busy your Signal app is, this transaction limit could take several days to reach. This
means that the messages deleted in Signal will linger on disk far longer than expected.
The database file with the supposedly deleted messages can easily end up being backed
up to Time Machine backups, adding unexpected data persistence.

Since its reporting 29 months ago, the vulnerability remained unknown except to Chromium developers. Then on Wednesday morning, it was published to the Chromium bug tracker. Rebane initially assumed the vulnerability was finally fixed. Shortly thereafter, she learned that, in fact, it remained unpatched. While Google removed the post, it remains available on archival sites, along with the exploit code.

Another security issue in the kernel

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:

1. 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.
2. The CA will know which domain names the client has accessed.
3. 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.

Previous: https://shaarli.lyokolux.space/shaare/hamcqA

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 X1

lyokolux.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.

1. A certificate can have only one issuer because the issuer is a fixed field in the certificate, not a list.
2. The essence of signing is just appending a hash value encrypted with a private key.
3. 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:

• clients: https://www.pixelstech.net/article/1722050582-All-I-Know-About-Certificates----Clients
• websites: https://www.pixelstech.net/article/1722050937-All-I-Know-About-Certificates----Websites

Next: https://shaarli.lyokolux.space/shaare/hamcqA

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:

• https://www.bleepingcomputer.com/news/security/new-pack2theroot-flaw-gives-hackers-root-linux-access/
• https://github.security.telekom.com/2026/04/pack2theroot-linux-local-privilege-escalation.html

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