#DEfO has completed #ECH implementation for #nginx and there is a pull request:

https://github.com/nginx/nginx/pull/840

If you want to see ECH in nginx sooner rather than later, please jump in and review, give feedback, thumbs up, etc.

#EncryptedClientHello#TLS#OpenSSL

#DEfO has completed #ECH implementation for #nginx and there is a pull request:

https://github.com/nginx/nginx/pull/840

If you want to see ECH in nginx sooner rather than later, please jump in and review, give feedback, thumbs up, etc.

#EncryptedClientHello#TLS#OpenSSL

Am I really the only one who uses 24hrs long living certificates which get automatically renewed and signed by an own CA via ACME?

#ssl #tls #dane #acme #certificate #certificateauthority #ca

Am I really the only one who uses 24hrs long living certificates which get automatically renewed and signed by an own CA via ACME?

#ssl #tls #dane #acme #certificate #certificateauthority #ca

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

#CyberSecurity#Phishing#DigitalTrust#TLS

Introducing Web Numbers

Domains? Where we’re going, we don’t need domains!

Get ready for an exciting new (old?) way to address (small) web sites in 2026.

https://ar.al/2025/06/25/web-numbers/

💕

(Thanks to @letsencrypt.)

#WebNumbers #SmallWeb#domainNames #IPAddresses#TLS#HTTPS#LetsEncrypt #web #decentralisation#SmallTech

Introducing Web Numbers

Domains? Where we’re going, we don’t need domains!

Get ready for an exciting new (old?) way to address (small) web sites in 2026.

https://ar.al/2025/06/25/web-numbers/

💕

(Thanks to @letsencrypt.)

#WebNumbers #SmallWeb#domainNames #IPAddresses#TLS#HTTPS#LetsEncrypt #web #decentralisation#SmallTech

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

Found and fixed two more bugs affecting only #TLS with #swad, so here's yet another "bugfix release":

https://github.com/Zirias/swad/releases/tag/v0.9

One of these bugs was always there and I never noticed (just ignoring intermediate certificates) because many clients cope well with this, but not all.

The other bug is yet another regression from earlier performance improvements. 😞

So, lots of releases these last days. I'll have to remember to do very thorough regression testing whenever "optimizing" things in existing code 🙈

In a nutshell: 0.8 was finally fine again without TLS, but if you need TLS, better use this new 0.9.

#TLS#ACME
Il n'y a de page Wikipédia pour #certbot qu'en tchèque. https://cs.wikipedia.org/wiki/Certbot