Wandering Thoughts archives

TLS Certificate Transparency logs let us assess Certificate Authorities

I was recently reading Scott Helme's The Complexities of Chain Building and CA Infrastructure (it's part of a series from last year on the impending doom of expiring root CAs, which was linked to by Helme's Let's Encrypt Root Expiration - Post-Mortem). In it Helme mentioned something that previously hadn't consciously struck me about the modern Certificate Transparency environment. I'll just quote Helme here:

Who are the biggest CAs out there?

A few years ago that was probably a really hard question to answer. You might have to ask every CA what their issuance volume was and then compare them all to each other, hoping they weren't presenting figures in creative ways. Today though, we have a very easy way of determining this, Certificate Transparency. [...]

Simplifying slightly, all significant Certificate Authorities have had to log the TLS certificate they issue into Certificate Transparency logs for some time. Chrome has required this since May 2018, and since all fully valid TLS certificates have had a maximum validity of slightly over a year for a while, all still valid TLS certificates had better be in Certificate Transparency logs. As Scott Helme says, this means that we can count CA activity by looking at CT logs for what TLS certificates they've issued. We can do this for all of their TLS certificates, or just those with some characteristics (such as being in a specific TLD).

(There are some complexities in practice, but they can be solved with work.)

This matters for more than just a CA popularity count. One of the eternal arguments around either changing the rules for TLS certificates and CAs, or dealing with an issue with a CA, is how many people and TLS certificates will be affected. In the past traditionally there were all sorts of arguments and back and forth numbers and so on (from browsers, from CAs, etc). Today, for many questions we can go out and measure through the CT logs to count at least how many TLS certificates would be affected. How many TLS certificates would be affected is not the same thing as how much traffic or how many people would be affected, of course. But it's a start, which is more than we used to have to work with in the open.

PS: One use for this that I've already seen in past incidents is for third parties to check a CA's claims of how many of their TLS certificates have some mistake. Generally the answer is 'more than the CA initially reported', although probably my sample is biased because if people just confirm the CA's numbers they may not say anything.

V7 Unix had no stack size limit, and when Unix acquired one

Famously, modern Unixes by limit the (default) size of the main process stack and the size of thread stacks; they pick different limits, which causes issues because C has no way of dealing with this. Today, for reasons beyond the scope of this entry, I became curious if V7 had any stack size limit and if it didn't, when such a limit appeared.

The short answer about V7 is that V7 had no stack size limit. The combination of your stack and your program's data (and perhaps your program's code, depending on the model of PDP-11) could take up all of the 64 KB of memory available to your process for this. If your process took a memory access fault and its stack pointer was below the kernel's idea of the bottom of your stack, the kernel automatically grew the stack as far as necessary. You can see this in the V7 trap.c, where the decision to grow is made, and sig.c, which has the routine for the growing (and also ureg.c for one additional function).

On the BSD line of Unixes, 3BSD doesn't seem to have anything but 4BSD introduces a vlimit(2) system call to get and set limits, including the stack size. By 4.1c BSD, this has changed to the now familiar getrlimit(2) and setrlimit(2) system calls.

(Interestingly, Linux glibc provides a vlimit(), according to the manpage.)

On the AT&T side, there doesn't seem to be anything much that I could find. The System V Interface Definition (SVID) seems to be the official source of a ulimit() system call, but its only official thing is limiting file size. As far back as System III, there is a ulimit(2), but it doesn't set the stack size limit; the closest it comes is that it can get (but not set) the brk(2) limit. The System III VAX trap.c and sig.c still seem to be free of stack size limit checks, and have comments that say things are grown unconditionally.

(The current Oracle Solaris ulimit(2) manual page still talks about being able to get the maximum possible break value, although this isn't required in POSIX.)