NicolaiS

> "make your clients trust the CA"

There's no single trust store: the OS has one, Firefox, Java (cacerts), Python (certifi), Node, Go containers, all your Docker images, ...

Failure? People just toggle TLS verification off.

Easy to do in a one-man shop, but almost impossible in any big company. Try grepping for verify=False / -k / InsecureSkipVerify in any fortune 500 and you'll find plenty

badssl.com is an amazing tool especially for testing "TLS intercepting" boxes. I've seen more than one fortune 500 company that re-sign certain broken certs with their own CA, allowing silent MITM.

This exists, but not very well supported: https://github.com/C2SP/C2SP/blob/main/well-known-ssh-hosts....

But DNSSEC + SSHFP is a better supported solution at the moment

> Have mitmproxy gotten any better in usability over the years?

The new-ish "Local Capture" and "WireGuard"-mode are quite nice.

And running e.g. `mitmproxy --ignore-hosts '.*' --show-ignored-hosts` [1] for monitoring apps with certificate pinning also a new feature

[1] cmd will turn mitmproxy into a "non-MITM proxy" but do show domains (SNI) the app is connecting to.

TLS inspection can _never_ be implemented in a good way, you will always have cases where it breaks something and most commonly you will see very bad implementations that break most tools (e.g. it is very hard to trust a new CA because each of OS/browser/java/python/... will have their own CA store)

This means devs/users will skip TLS verification ("just make it work") making for a dangerous precedent. Companies want to protect their data? Well, just protect it! Least privilege, data minimization, etc is all good strategies for avoiding data leaking

Got acquired by a Fortune 500 and recieved new laptop. First hour I'm seeing TLS errors everywhere except the browser. They'd half-baked their internal CA rollout, so wasn't trusted properly.

By day two I started validating their setup. The CA literally had a typo in the company name, not a great sign.

A quick check with badssl.com showed that any self-signed(!) cert was being transparently MITM'ed and re-signed by their trusted corporate cert. Took them 40 days to fix it.

Another fun side-effect of this is that devs will just turned off TLS verification, so their codebase is full of `curl -k`, `verify_mode = VERIFY_NONE`, `ServerCertificateValidationCallback = () => true`, ... Exactly the thing you want to see at a big fintech company /s

Do you have any sources that the infected USB contained AV updates?

I can't find any sources saying that..

Note that this requires an authenticated user, so most redis installations are not directly at risk.

The github issue has these workarounds: > An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.

I guess most people doesn't use the lua engine, so this is probably a good advice to disable even if upgrading to a non-vuln version of Redis.

was pi: raspberry, but it was changed a long time ago to have no default user:pass

I guess a bunch of "roll your own X.509 validation"-logic will have that bug, but to exploit it you need a misbehaving CA to issue you such a cert (i.e. low likelihood)

After the Linux Foundation became a CNA (CVE Numbering Authority), it started issuing CVEs for a broad range of "vulns", such as local denial-of-service, memory errors with no viable exploit path, and logic flaws lacking meaningful security implications.

Looking at the raw number of CVEs is not very meaningful

Parent comment writes: "ship[ing] the tree root hash", for a merkle tree ("bitcoin style") this would just be a single (small) hash no matter the tree size, i.e. 32 bytes is enough.

Agree

Caddy even supports 'ACME profiles' for people that want to follow the latest recommendation from CAB / want shortlived certs

Another approach that avoids symlinks and avoids a git repo in $HOME (i.e. everything is a subdir of that git repo) is to use the option "git-dir" to clone into a subdir, e.g. `$HOME/.dotfiles/` but checkout into $HOME:

    git clone --bare git@github.com:.../dotfiles.git $HOME/.dotfiles
    git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME checkout
    alias dotfiles='git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'
    dotfiles config --local status.showUntrackedFiles no

Now the "dotfiles"-alias can be used like git, "dotfiles add, checkout, log", no symlinks are needed and you avoid "contaminating" subdirs of $HOME (git searches parent dirs for ".git", so a ".git" folder in $HOME kinda sucks)

A confidential channel can be established over an insecure medium using e.g. Diffie-Hellman key exchange. To protect against MITM, an out-of-band QR/bluetooth can be used.

Biggest reason to avoid DES is the short key. Double-DES doesn't fix that due to the meet-in-the-middle attack. Triple DES "solves" the short key problem.

Amazing to see post-quantum crypto (PQC) by-default, and support for Encrypted ClientHello (ECH) and ACME Profiles!

This will not work as any attacker that can MITM the client (likely scenario for end-users), can also MITM this "certificate issuing" setup and issue their own cert.

The reason an attacker can't MITM Let's Encrypt (or similar ACME issuers) is because they request the challenge-response from multiple locations, making sure a simple MITM against them doesn't work.

A fully DNS based "certificate setup" already exists: DANE, but that requires DNSSEC, which isn't wildly used.

Sorry, but this will never work very well.

The tool contains a bunch of "denylist regexes", i.e.

    `user (should not|must not|cannot) see`

But these can easily be bypassed. Any real security tool should use allowlists, but that is ofc much harder with natural languages.

MCP-Shield can also analyse using Claude, but that code contains an easy to exploit prompt injection: https://github.com/riseandignite/mcp-shield/blob/19de96efe5e...

Self-hosting Conduit as my homeserver using SQLite as by database and Caddy as reverse proxy.

That is: 2 binaries (conduit + caddy) + 5 lines of toml config for Conduit and 2 line of config for Caddy + 1 database file. That's all you need for a basic homeserver.

A note for Ubuntu users; if Firefox is installed using `snap` (default) and you run `snap refresh` it will output "All snaps up to date" - but this is not true! You have to close firefox, then run `snap refresh` for snap to upgrade firefox...

Corporate MITM'ing is always a bad practice, it breaks a lot of TLS (e.g. mTLS) and can't be implemented in a way that will not break legitimate workflows (e.g. cert pinning a untrusted leaf vs the middlebox trusting everything and re-signing with 'real' cert)

Slightly related, but mostly for fun:

You can do valid HTTP & SSH on the same port: https://media.ccc.de/v/bornhack2023-56142-sexy-ssh-hacks#t=4... (Without detecting which client connects, it works just like the "valid PNG and ZIP polyglot" trick)

You are misunderstanding the attack. The attacks requirement is: replace two encrypted files (e.g. by gaining access to someone's dropbox that contains the synced db), wait for them to leak "secretA" on "siteB" because `pass` doesn't securely bind secret and sites together. The attack is very realistic and high impact (but hard to perform).

openssl packaged as `3.0.2-0ubuntu1.7` fixes the issue. So `>1, <= 3.0.2-0ubuntu1.6` is vulnerable.

If you are using an APT mirror, you might not see the update yet. Consider adding `deb http://archive.ubuntu.com/ubuntu jammy-updates main restricted` to `/etc/apt/sources.list` to get the updated package

It's in the post:

    a specially constructed file can result in arbitrary code execution

There is nothing called "VARCHAR(n)" in SQLite. It is mapped to `CHAR(ACTER) => TEXT` which is limited to 2^31 - 1 characters.

[1] https://www.sqlite.org/datatype3.html#3.1.1

[2] https://www.sqlite.org/limits.html#max_length

You are missing the steps to install, setup, cronjob, for certbot.

What about HTTP->HTTPS redirection, etc?

Same for secure cipher selection.

All of that Caddy gives you in 1 line of config (i.e. domain name)

In case Bitcoin needed to upgrade e.g. secp256k1, then a logical/easy way to avoid this problem is with a simple commitment scheme.