eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.

Server stats:

225
active users

#tls

3 posts3 participants1 post today

Does anyone know of a table of data which shows PKI CA root certs and which devices/clients they are compatible with? (i.e. which devices/clients include each root cert in their default trust store)

I think I have asked about this in the past. It'd be incredibly useful.

#PKI#TLS#InfoSec
Replied to Aral Balkan

@aral Great point — and I agree that most users would be suspicious if they saw an IP address like 89.72.4.2 instead of a familiar domain like mybank.com. The concern raised in the article, though, was more about scenarios where users don’t see the link clearly — such as in emails, PDFs, or messaging apps where URLs may be masked behind anchor text or shortened links. For example, a phishing email might show a link that says “View Invoice” but actually points to https: //203.0.113.10/login.

Experienced users like you and I know to hover over links, check certificate info, or inspect the address bar. But many users don’t do that — or worse, they click links without verifying anything. According to the Verizon DBIR and other phishing studies, this is still one of the top attack vectors today.

Also, I don’t think the article was arguing against IP certs outright — just highlighting that, like with any new capability, there's potential for abuse that the broader public (and infosec community) should be aware of.

Let's #Encrypt rolls out free IP address #certificates • The Register

Let's Encrypt, a #CertificateAuthority (CA) known for its free TLS/SSL certificates, has begun issuing digital certificates for IP addresses.

It's not the first CA to do so. #PositiveSSL , #Sectigo, and #GeoTrust all offer TLS/SSL certificates for use with IP addresses, at prices ranging from $40 to $90 or so annually. But Let's Encrypt does so at no cost.
#security #tls #ssl #privacy

theregister.com/2025/07/03/let

The Register · Let's Encrypt rolls out free security certs for IP addressesBy Thomas Claburn
Continued thread

Oh boy, I have a lead! And it's NOT related to #TLS. I finally noticed another pattern: #swad only #crashed when running as a #daemon. The daemonizing wasn't the problem, but the default logging configuration attached to it: "fake async", by letting a #threadpool job do the logging.

Forcing THAT even when running in foreground, I can finally reproduce a crash. And I wouldn't be surprised if that was actually the reason for crashing "pretty quickly" with #LibreSSL (and only rarely with #OpenSSL), I mean, something going rogue in your address space can have the weirdest effects.

Running e-mail servers is always fun: as the time came to renew TLS certificate on one machine doing e-mail transmission (SMTP), came to know TLSA records are now supposed to be 3 1 1 (no more 3 0 1) :blobcateyes:

There is an added benefit of 3 (DANE-EE) 1 (subject public key) 1 (SHA2-256 hash digest) - if you do not rotate your private key to issue TLS certificate, you don't need to update the TLSA record - signature can be squeezed from key and certificate is not necessary at that point. If you do rotate private keys, this enables you to pre-create DNS records even before certificate is issued (given that you already generated keys) - that is really nice :blobcatthumbsup:

mail.sys4.deA sensible "3 1 1" + "3 1 1" key rotation approach

Hello, I’m hosting a #Vaultwarden server behind #Caddy 2.10 and made the following test:

Tuning Caddy to allow only #PQC curves:

	tls {
		curves x25519mlkem768
	}

Trying to connect with #Firefox Mac -> OK
Trying to connect with #Bitwarden #android client -> Fail

Without the #TLS tuning, the Bitwarden Android client will happily connect to the server.

Is it a problem with the Bitwarden Android client or with Android, or both?

A recent research has exposed more than 40 * 10³ IoT cameras happily showing their feed _and_ location to anyone who can browse and use search engines specialized in the indexing of the misconfigured devices.

More than 14 * 10³ are localised in the USA.

Read more here.

Note:
I know that there are more than a million of these cameras world wide misconfigured an open on just port 80 http not even TLS 443, with admin / admin as credentials 🪪

theregister.com/2025/06/10/400

More interesting progress trying to make #swad suitable for very busy sites!

I realized that #TLS (both with #OpenSSL and #LibreSSL) is a *major* bottleneck. With TLS enabled, I couldn't cross 3000 requests per second, with somewhat acceptable response times (most below 500ms). Disabling TLS, I could really see the impact of a #lockfree queue as opposed to one protected by a #mutex. With the mutex, up to around 8000 req/s could be reached on the same hardware. And with a lockfree design, that quickly went beyond 10k req/s, but crashed. 😆

So I read some scientific papers 🙈 ... and redesigned a lot (*). And now it finally seems to work. My latest test reached a throughput of almost 25k req/s, with response times below 10ms for most requests! I really didn't expect to see *this* happen. 🤩 Maybe it could do even more, didn't try yet.

Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...

(*) edit: Here's the design I finally used, with a much simplified "dequeue" because the queues in question are guaranteed to have only a single consumer: dl.acm.org/doi/10.1145/248052.

Continued thread

Solved! 🥳

This was a pretty "interesting" bug. Remember when I invented a way to implement #async / #await in #C, for jobs running on a threadpool. Back then I said it only works when completion of the task resumes execution on the *same* pool thread.

Trying to improve overall performance, I found the complex logic to identify the thread job to put on a pool thread a real deal-breaker. Just having one single MPMC queue with a single semaphore for all pool threads to wait on is a lot more efficient. But then, a job continued after an awaited task will resume on a "random" thread.

It theoretically works by making sure to restore the CORRECT context (the original one of the pool thread) every time after executing a job, whether partially (up to the next await) or completely.

Only it didn't, at least here on #FreeBSD, and I finally understood the reason for this was that I was using #TLS (thread-local storage) to find the context to restore.

Well, most architectures store a pointer to the current thread metadata in a register. #POSIX user #context #switching saves and restores registers. I found a source claiming that the #Linux (#glibc) implementation explicitly does NOT include the register holding a thread pointer. Obviously, #FreeBSD's implementation DOES include it. POSIX doesn't have to say anything about that.

In short, avoiding TLS accesses when running with a custom context solved the crash. 🤯