Wandering Thoughts archives


There are two sorts of TLS certificate mis-issuing

The fundamental TLS problem is that there are a ton of Certificate Authorities and all of them can create certificates for your site and give them to people. When talking about this, I think it's useful to talk about two different sorts of mis-issuance of these improper, unapproved certificates.

The first sort of mis-issuance is when a certificate authority's systems (computer and otherwise) are fooled or spoofed into issuing an otherwise normal certificate that the CA should not have approved. This issuance process goes through the CA's normal procedures, or something close to them. As a result, the issued certificate is subject to all of the CA's usual logging, OCSP processes (for better or worse), and so on. Crucially, this means that such certificates will normally appear in Certificate Transparency logs if the CA publishes to CT logs at all (and CAs are increasingly doing so).

The second sort of mis-issuance is when the CA is subverted or coerced into signing certificates that don't go through its normal procedures. This is what happened with DigiNotar, for example; DigiNotar was compromised, and as a result of that compromise some unknown number of certificates were improperly signed by DigiNotar. This sort of mis-issuance is much more severe than the first sort, because it's a far deeper breach and generally means that far less is known about the resulting certificates.

My impression is that so far, the first sort of mis-issuance seems much more common than the second sort. In a way this is not surprising; identity verification is tricky (whether manual or automated) and is clearly subject to a whole lot of failure modes.

The corollary to this is that mandatory Certificate Transparency logging can likely do a lot to reduce the impact and speed up the time to detection of most mis-issued certificates. While it can't do much about the second sort of mis-issuance, it can pretty reliably work against the first sort, and those are the dominant sort (at least so far). An attacker who wants to get a mis-issued certificate that isn't published to CT logs must not merely break a CA's verification systems but also somehow compromise their backend systems enough to subvert part of the regular certificate issuance processing. This is not quite a full compromise of the CA's security, but it's a lot closer to it than merely finding a way around the CA's identity verification processes (eg).

TLSCertificatesTwoMisissues written at 23:15:59; Add Comment


There are several ways to misread specifications

In an ideal world, everyone reads specifications extremely carefully and arrives at exactly the same results. In the real world, generally specifications are read casually, with people skimming things, not putting together disparate bits, and so on. If the specification is not clear (and perhaps even if it is), one of the results of this is misinterpretations. However, it's my view that not all misinterpretations are the same, and these differences affect both how fast the misreading propagates and how likely it is to be noticed (both of which matter since ultimately specifications are defined by their implementations).

I see at least three ways for misreadings to happen. First, you can accept more than the specification wants; if a field is specified as ASCII, you can also accept UTF-8 in the field. Second, you can accept less than the specification wants; if a field is specified as UTF-8, you can only accept ASCII. Finally, you can have a different interpretation of some aspect; the specification might have a 'hostname' field where it's intended to accept ASCII or UTF-8, but you accept ASCII or IDNA ASCII and decode the IDNA ASCII to UTF-8.

In a sense, the important thing about all of these misreadings is that they're only partially incompatible with the real specification. In all of my examples, a pure-ASCII thing can be successfully interchanged between your misreading and a fully correct implementation. It's only when one side or the other goes outside of the shared base that problems ensue, and that's obviously part of how far a misreading can propagate before it's noticed.

There are also misreadings where you are outright wrong, for example the specification says 'text' and you assume this means UTF-16 instead of ASCII. But these sort of misreadings are going to be detected almost immediately unless the field (or option or whatever) is almost never used, because you'll be completely incompatible with everyone else instead of only partially incompatible.

My belief is that the misreading that will propagate the farthest and be noticed the slowest is a more expansive reading, because there's no way to notice this until someone eventually generates an improper thing and it's accepted by some implementations but not all. If those accepting implementations are popular enough, the specification will probably expand through the weight of enough people accepting this new usage.

(The corollary to this is that if a specification has conformance tests, you should include tests for things that should not be accepted. If your specification says 'field X is ASCII only' or 'field X cannot be HTML', include test vectors where field X is UTF-8 or contains HTML or whatever.)

Misreadings that are more restrictive or different can flourish only when the things that they don't accept are missing, rare, or hard to notice the mistake in. This goes some way to explain why implementation differences are often found in the dark corners or obscure parts of a specification, in that there isn't enough usage for people to notice misreadings and other mistakes.

SpecMisreadingSeveralWays written at 01:22:52; Add Comment


Why I plan to pick a relatively high-end desktop CPU for my next PC

My general reflex when it comes to any number of PC components, CPUs included, is to avoid the (very) highest end parts. This is for the well known reason that the top of the product range is where nearly everyone raises prices abruptly. If you want something close to the very best, the vendor will charge you for the privilege and the result is not that great a price to performance ratio. Going down a step or three can give you most of the benefits for much less cost. This is certainly the approach that I took with the CPU for my current machine, where picking an i5-2500 over an i7-2600 was about 2/3rds of the cost for much of the performance.

Well, you know what, this time around I'm not going to do that for the new PC I'm slowly planning. The lesser reason is that there is now much more of a (potential) performance difference in Intel's current desktop CPUs; an i5-8400 is clocked clearly lower than i7-8700, on top of not having hyperthreading and having 3 MB less L3 cache. But the larger reason is that I'm no longer convinced that economizing here makes long term sense with how I've treated my PCs so far. Specifically, I seem to get at least five years out of each one and I don't upgrade it over that time.

I think that buying a cost-effective CPU makes a lot of sense if you're going to later upgrade it to another cost-effective CPU when the performance difference becomes meaningful to you. But if you're not, buying a cost-effective CPU that meaningfully underperforms a higher-end one means that your machine's relative performance slides sooner and faster. Buying a meaningfully faster CPU now keeps your machine from becoming functionally obsolete for longer, and if you amortize the extra cost over the (long) lifetime of your machine, it may not come out to all that much extra.

(It's my current view that CPU performance still matters to me, so I will notice differences here.)

To some degree this contradicts what I said in my thinking about whether I'd upgrade my next PC partway through its life, where I was open to a mid-life CPU upgrade. There are two answers here. One of them is that I don't really want to go through the hassle of a CPU upgrade, both in figuring out when to do it and then the actual physical process.

The other answer is that this is all rationalization and justification. In reality, I've become tired of doing the sensible, economical thing and settling for a 'not as good as it could reasonably be' system. Buying an objectively overpriced CPU is something that I can afford to do and it will make me irrationally happier with the resulting PC (and the five year amortized cost is not all that much).

PCSelectingHighEndCPU written at 02:14:38; Add Comment


HD usage can be limited by things other than cost per TB

I was recently reading WDC: No SSD/HDD Crossover (via), which reports Western Digital data that says that HDs will continue to have a significant price per TB advantage over SSDs for at least the next decade (the quoted figure is a 10:1 advantage). I'm perfectly prepared to believe this (I have no idea myself), but at the same time I don't think it's necessarily very relevant. The simple way to put it is that a great deal of storage is not bulk storage.

If you're doing bulk storage, then certainly the cost per TB matters lot and HDs will likely continue to have the advantage. But if you're not, there are a number of other concerns that will probably clip the wings of HDs long before then. Two classical concerns are maintaining enough IOPS per TB, and the time it takes to restore your data redundancy after a disk is lost (whether through a RAID resynchronization or some other mechanism).

Larger and larger HDs might come with an increase in IOPS per disk, but history is fairly strongly against that; genuine sustainable IOPS per disk has been basically flat for HDs for years. This means that as your HDs grow bigger, IOPS per TB drops; the same amount of IOPS per disk is spread among more TB per disk. If you feel you need reasonably responsive random IO, this can easily mean that your usable TB per disk is basically capped. This is the situation that we're in with our fileservers, where we deliberately used 2 TB HDs instead of something larger in order to maintain a certain level of IOPS per TB.

(This IOPS limit is different from a situation where HDs simply can't provide enough IOPS to meet your needs.)

The time required to restore full data redundancy after a disk failure goes up as you put more and more data on a single disk. If you lose a giant disk, you get to copy a giant disk's worth of data, and the bigger your disks are the longer this takes. At a certain point many people decide that they can't afford such long rebuild times, and so they have to cap the usable TB per disk. Alternately they have to build in more redundancy, which requires more disks and results in higher costs per usable TB of space (not raw TB of space).

(This has already happened once; as disks got larger, people moved away from RAID-5 in favour of RAID-6 in large part because of rebuild times and the resulting exposure if you lost a drive in a RAID-5 array.)

If your usable TB per disk is capped in this way, the only thing that larger, cheaper per TB HDs do for you is perhaps drive down the price of smaller right-sized disks (in our case, this would be 2 TB disks). Unfortunately, disks seem to have a floor price and as disk capacity increases, what you get for this floor price in a decent quality drive seems quite likely to go over the maximum TB that you can use. More to the point, the cost of SSDs with the same capacity is going to keep coming down toward where they're affordable enough. This is the real-world SSD inflection point for many environments; not the point where the price per TB of SSDs reaches that of HDs, but the point where you might as well use SSDs instead of the HDs that you can use, or at least you can afford to do so.

HDUsageLimits written at 01:08:27; Add Comment


Understanding what our wireless password protects

I don't have a deep understanding of wireless networking protocols. Usually this is fine and I can get by on broad knowledge and superstition. But as part of reading about KRACK, I found myself not sure of how exposed we were in some ways, because I wasn't sure what wireless passwords actually protect. Did they only protect access to your WPA/WPA2 wireless network, or did they also secure data being transmitted and received?

(This may sound like a silly question, but Diffie-Hellman key exchange can arrange encryption between parties without any shared secret. It's perfectly possible for wireless networking to only use the wireless password to authenticate your access to the network and then have you and the AP use some form of Diffie-Hellman to negotiate the actual encryption keys.)

The short answer is that wireless passwords are used for both authentication and encryption. As best I can determine from following along in the four-way handshake from IEEE 802.11i and reading people's discussions of it, the wireless password is the only piece of secret information that goes into the encryption keys negotiated between a wireless client and the AP; everything else is visible to eavesdroppers and so doesn't protect the eventual key. If you know a network's password, you can decrypt all traffic from other people that you can snoop, provided that you captured their initial authentication to the AP.

(Confirmation for this comes from things such as Wikipedia's discussion of the lack of forward secrecy in WPA.)

This means that KRACK is in some senses much less nasty against wireless networks where the wifi password is already widely known and you assume that your network may already have eavesdroppers on it. KRACK basically gives outsiders some or a fair bit of the power that a semi-insider with the password already has. Your pool of attackers may be wider, but the severity is no worse than it was before; your worst case is still a complete loss of encryption on wireless communication.

PS: I'm not surprised by this result, because it's what my broad knowledge and superstition had led me to believe was the case. But it's one thing to just believe something because it's what I think I've heard and another thing to have actually tried to look it up to be sure.

WirelessPasswordAndEncryption written at 02:08:52; Add Comment


Working to understand PCI Express and how it interacts with modern CPUs

PCI Express sort of crept up on me while I wasn't looking. One day everything was PCI and AGP, then there was some PCI-X in our servers, and then my then-new home machine had PCIe instead but I didn't really have anything to put in those slots so I didn't pay attention. With a new home machine in my future, I've been working to finally understand all of this better. Based on my current understanding, there are two sides here.

PCI Express itself is well described by the Wikipedia page. The core unit of PCIe connections is the lane, which carries one set of signals in either direction. Multiple lanes may be used together by the same device (or connection) in order to get more bandwidth, and these lane counts are written with an 'x' prefix, such as 'x4' or 'x16'. For a straightforward PCIe slot or card, the lane count describes both its size and how many PCIe lanes it uses (or wants to use); this is written as, for example 'PCIe x16'. It's also common to have a slot that's one physical size but provides fewer PCIe lanes; this is commonly written with two lane sizes, eg 'PCIe x16 @ x4' or 'PCIe x16 (x4 mode)'.

While a PCIe device may want a certain number of lanes, that doesn't mean it's going to get them. Lane counts are negotiated by both ends, which in practice means that the system can decide that a PCIe x16 graphics card in an x16 slot is actually only going to get 8 lanes (or less). I don't know if in theory all PCIe devices are supposed to work all the way down to one lane (x1), but if so I cynically suspect that in practice there are PCIe devices that can't or won't cope well if their lane count is significantly reduced.

(PCIe interconnection can involve quite sophisticated switches.)

All of this brings me around to how PCIe lanes connect to things. Once upon a time, the Northbridge chip was king and sat at the heart of your PC; it connected to the CPU, it connected to RAM, it connected to your AGP slot (or maybe a PCIe slot). Less important and lower bandwidth things were pushed off to the southbridge. These days, the CPU has dethroned the northbridge by basically swallowing it; a modern CPU directly connects to RAM, integrated graphics, and a limited number of PCIe lanes (and perhaps a few other high-importance things). Additional PCIe lanes, SATA ports, and everything else are connected to the motherboard chipset, which then connects back to the CPU through some interconnect. On modern Intel CPUs, this is Intel's DMI and is roughly equivalent to a four-lane PCIe link; on AMD's modern CPUs, this is apparently literally an x4 PCIe link.

Because you have to get to the CPU to talk to RAM, all PCIe devices that use non-CPU PCIe lanes are collectively choked down to the aggregate bandwidth of the chipset to CPU link for DMA transfers. Since SATA ports, USB ports, and so on are also generally connected to the chipset instead of the CPU, your PCIe devices are contending with them too. This is especially relevant with high-speed x4 PCIe devices such as M.2 NVMe SSDs, but I believe it comes up for 10G networking as well (especially if you have multiple 10G ports, where I think you need x4 PCIe 3.0 to saturate two 10G links).

(I don't know if you can usefully do PCIe transfers from one device to another device directly through the chipset, without touching the CPU and RAM and thus without having to go over the link between the chipset and the CPU.)

Typical Intel desktop CPUs have 16 onboard PCIe lanes, which are almost always connected to an x16 and an x16 @ x8 PCIe slot for your graphics cards. Current Intel motherboard chipsets such as the Z370 have what I've seen quoted as '20 to 24' additional PCIe lanes; these lanes must be used for M.2 NVMe drives, additional PCIe slots, and additional onboard chips that the motherboard vendor has decided to integrate (for example, to provide extra USB 3.1 gen 2 ports or extra SATA ports).

The situation with AMD Ryzen and its chipsets is more tangled and gets us into the difference between PCIe 2.0 and PCIe 3.0. Ryzen itself has 24 PCIe lanes to Intel's 16, but the Ryzen chipsets seem to have less additional PCIe lanes and many of them are slower PCIe 2.0 ones. The whole thing is confusing me, which makes it fortunate that I'm not planning to get a Ryzen-based system for various reasons, but for what it's worth I suspect that Ryzen's PCIe lane configuration is better for typical desktop users.

Unsurprisingly, server-focused CPUs and chipsets have more PCIe lanes and more lanes directly connected to the CPU or CPUs (for multi-socket configurations). Originally this was probably aimed at things like multiple 10G links and large amounts of high-speed disk IO. Today, with GPU computing becoming increasingly important, it's probably more and more being used to feed multiple x8 or x16 GPU card slots with high bandwidth.

PCIeAndModernCPUs written at 02:10:23; Add Comment


Understanding M.2 SSDs in practice and how this relates to NVMe

Modern desktop motherboards feature 'M.2' sockets (or slots) for storage in addition to some number of traditional SATA ports (and not always as many of them as I'd like). This has been confusing me lately as I plan a future PC out, so today I sat down and did some reading to understand the situation both in theory and in practice.

M.2 is more or less a connector (and mounting) standard. Like USB-C ports with their alternate mode, M.2 sockets can potentially support multiple protocols (well, bus interfaces) over the same connector. M.2 sockets are keyed to mark different varieties of what they support. Modern motherboards using M.2 sockets for storage are going to be M.2 with M keying, which potentially supports SATA and PCIe x4 (and SMBus).

M.2 SSDs use either SATA or NVMe as their interface, and generally are M keyed these days. My impression is that M.2 NVMe SSDs cost a bit more than similar M.2 SATA SSDs, but can perform better (perhaps much better). A M.2 SATA SSD requires a M.2 socket that supports SATA; a M.2 NVMe SSD requires a PCIe (x4) capable M.2 socket. Actual motherboards with M.2 sockets don't necessarily support both SATA and PCIe x4 on all of their M.2 sockets. In particular, it seems common to have one M.2 socket that supports both and then a second M.2 socket that only supports PCIe x4, not SATA.

(The corollary is that if you want to have two more or less identical M.2 SSDs in the same motherboard, you generally need them to be M.2 NVMe SSDs. You can probably find a motherboard that has two M.2 sockets that support SATA, but you're going to have a more limited selection.)

On current desktop motherboards, it seems to be very common to not be able to use all of the board's M.2 sockets, SATA ports, and PCIe card slots at once. One or more M.2 SATA ports often overlap with normal SATA ports, while one or more M.2 PCIe x4 can overlap with either normal SATA ports or with a PCIe card slot. The specific overlaps vary between motherboards and don't seem to be purely determined by the Intel or AMD chipset and CPU being used.

(Some of the limitations do seem to be due to the CPU and the chipset, because of a limited supply of PCIe lanes. I don't know enough about PCIe lane topology to fully understand this, although I know more than I did when I started writing this entry.)

The ASUS PRIME Z370-A is typical of what I'm seeing in current desktop motherboards. It has two M.2 sockets, the first with both SATA and PCIE x4 and the second with just PCIe x4. The first socket's SATA steals the regular 'SATA 1' port, but its PCIe x4 is unshared and doesn't conflict with anything. The second socket steals two SATA ports (5 and 6) in PCIe x4 mode but can also run in PCIe x2 mode, which leaves those SATA ports active. So if you only want one NVMe SSD, you get 6 SATA port; if you want one M.2 SATA SSD, you're left with 5 SATA ports; and if you want two M.2 NVMe SSDs (at full speed), you're left with 4 regular SATA ports. The whole thing is rather confusing, and also tedious if you're trying to work out whether a particular current or future disk configuration is possible.

Since I use disks in mirrored pairs, I'm only interested in motherboards with two or more M.2 PCIe (x4) capable sockets. M.2 SATA support is mostly irrelevant to me; if I upgrade from my current SSD (and HD) setup to M.2 drives, it will be to NVMe SSDs.

(You can also get PCIe cards that are PCIe to some number of M.2 PCIe sockets, but obviously they're going to need to go into one of the PCIe slots with lots of PCIe lanes.)

M2SSDsAndNVMe written at 02:17:13; Add Comment


Thinking about whether I'll upgrade my next PC partway through its life

There are some people who routinely upgrade PC components through the life of their (desktop) machine, changing out CPUs, memory, graphics cards, and close to every component (sometimes even the motherboard). I've never been one of those people; for various reasons my PCs have been essentially static once I bought them. I'm in the process of planning a new home and work PC, and this time around I'm considering deliberately planning for some degree of a midway upgrade. Given that I seem to keep PCs for at least five years, that would be two or three years from now.

(Part of my reason for not considering substantial upgrades was I hadn't assembled PCs myself, so thoughts of things like replacing my CPU with a better one were somewhat scary.)

Planning for a significant midway upgrade in advance is always a bit daring and uncertain, since you never know what companies like Intel are going to do in the future with things like new CPU sockets and so on. Despite that I think you can at least consider some things, and thus perhaps build up your initial PC with some eye towards the future changes you're likely to want to make. Well, let me rephrase that; I can think about these things, and I probably should.

However, for me the big change would be a change in mindset. My PC would no longer be something that I considered immutable and set in stone, with me just having whatever I had. Merely deliberately deciding that I'll have this mindset probably makes it more likely that I'll actually carry through and do some upgrades, whatever they turn out to be.

In terms of actual upgrades, the obvious midway change is an increase in RAM and I can make that easier by picking a DIMM layout that only populates two out of four motherboard DIMM slots. These days it's easy to get 32 GB with two 16 GB DIMM modules, and that's probably enough for now (and RAM is still surprisingly expensive, unfortunately).

Planning a midway CPU upgrade is more chancy because who knows if a compatible CPU will still be available at a reasonable price in a few years. Probably I'd have to actively keep up with CPU and socket developments, so that when my PC's CPU socket stops being supported I can wait for the last compatible CPU to hit a suitably discounted price and then get one. If this happens too soon, well, I get to abandon that idea. It's also possible that CPUs won't progress much in the next five years, although I'm hoping that we get more cores at least.

Graphics card upgrades are so common I'm not sure that people think of them as 'upgrading your PC', but they're mostly irrelevant for me (as someone who runs Linux and sticks to open source drivers). However I do sometimes use a program that could use a good GPU if I had one, and someday there may be real open source drivers for a suitable GPU card from either AMD or nVidia (I'm aware that I'm mostly dreaming). This will be an easy drop-in upgrade, as I plan to use Intel motherboard graphics to start with.

(Hard drives are a sufficiently complicated issue that I don't think they fit into the margins of this entry. Anyway, I need to do some research on the current state of things in terms of NVMe and similar things.)

MidwayPCUpgradeThoughts written at 02:26:06; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.