Chameth.com - posts like http2-and-sni, surge-protectors-marketing-vs-reality, why-you-should-be-using-https

Surge protectors: marketing vs reality

2026-01-24T00:00:00Z

A while back I went down a deep rabbit hole looking into surge protectors, and what all the different numbers mean, and how that affects things in case of a voltage spike. Then I didn’t really do anything with the information, other than bore a few friends, and look around in despair at all the shockingly bad products out there. Time to fix that!

I’m coming at this from the angle of a computer user in a country with very good electrical regulations. If you’re protecting something else, or live somewhere that doesn’t believe in grounding things, your mileage may vary.

Building a better mental model

I think when most of us think of surge protectors, we think of an extension lead with some magical property that stops surges and protects everything plugged into them. It’s a bit like the shield on the USS Enterprise. If we put the shields up in time, they’ll stop everything thrown at them, until at some point they’re overloaded and stop working. Only then will we have problems. There’s even a little LED that goes out when she cannae take it any more, cap’n.

Of course, if that was actually the case, I wouldn’t be writing a blog post. Surge protectors are more like the crumple zone on a car. If you hit something, the crumple zone will absorb some of the impact, but you can quite easily still get injured. If the impact is big enough then the crumple zone will bleed some energy, but you’re still going to have a very bad time. My point here is that it’s not a perfect shield, can be overcome with a single excessive impact, and doesn’t magically recharge back to full strength.

The numbers, Mason! What do they mean?

To understand what protection these things really offer, we need to look at a couple of numbers. Unfortunately, they’re not the numbers that are displayed in the marketing. Sometimes they’re not even on the spec sheet. Most of the time they’re on the actual device, and if they’re not then it’s safe to just assume things are bad.

The most important number is the let-through voltage, U_p. It may also be called the clamping voltage, the voltage protection rating, or the VPR. This is the voltage that will be let through, before the surge protector does anything¹. We use 230V mains, with a +10%/-6% tolerance. So we shouldn’t be seeing anything above 253V. If you were designing a surge protector, you’d want it to engage a little above this, right? Maybe call it 300V so it doesn’t cut in prematurely? If you have a surge protector nearby, I invite you to try and find its U_p value. If you don’t have one, you can follow along with mine:

A not-very-good surge protector. Please take a moment to consider how difficult it was to make this text readable.

Yes, that’s 1,500 Volts. Up until that point the surge protector does nothing. Your computer’s power supply just has to deal with it. That’s not even the highest I’ve seen, either. It’s just the closest I had to hand.

So what are the other numbers? U_c is the maximum continuous operating voltage. That’s probably fine — in the worst case it’ll slowly degrade over time if the mains rides the 253V edge — but at the same time, would you not spec it for 275V or more given that? For the most part, we don’t really care about this, though. If the surge protector has the right kind of plug on it, then it’s probably got a U_c in the right ballpark.

Then we have U_oc, which is the open circuit voltage. This is one of the numbers that might end up on the marketing, because it can be big! This is the surge voltage that the device can sustain without failing itself. So for this surge protector, it won’t do anything for surges up to 1.5kV, between 1.5kV and 4kV it will clamp the voltage, and above 4kV it might fail in some manner. That failure could be failing open and leaving your computer to deal with the rest of the surge (the little LED would go out, though!).

The number not on the device that’s on all the marketing materials is the “Joule rating”. That’s how much energy the thing can absorb before it fails. That can be gradually drained by small surges over time, or by a big one. Something in the realm of 1kJ seems to be a “good” value, but what does it actually mean? Say we had a surge of 1.5kV, our 1kJ of protection would cover 0.66 Amp seconds. Surges are typically very short; let’s say one lasts 2µs. That energy budget would allow for 333kA of current to be handled! That’s an order of magnitude more than a lightning strike! Amazing! Except… There’s also a maximum surge current rating, and I guarantee it’s less than that. The actual number on the Joule rating is basically useless given all the other constraints, but the bigger the number the more hardy the protector will be, in general.

Oh, one more thing on that Joule rating. Sometimes surge protectors will have multiple different protection devices inside, especially when they protect other connectors like coax or telephone cables. Sometimes the Joule rating will just be the sum of all the individual protectors, so is even more useless. Yay marketing.

How much abuse can a PSU take, anyway?

OK, so it turns out surge protectors are… underwhelming, shall we say? If there’s a surge, your computer is going to be involved. So what can PSUs actually deal with?

Turns out modern PSUs have surge protection built-in, along with all sorts of other “why is the electricity not electricitying right?” safeguards. I can’t find a single manufacturer that actually puts any numbers to that, though.

If you were to open one up and look inside, you’d see something like this:

I spy with my little eye… something beginning with MOV!

That little thing hidden in heatshrink is a MOV, or Metal Oxide Varistor. Also known as a Zinc-Oxide Non-liner Resistor, or ZNR, as it’s labelled in the picture. It’s basically a resistor that varies its resistance based on the voltage. So it can have a high resistance at low voltages, and then after, say, 300V it could start dropping off. Can you guess what component is inside basically all consumer surge protectors? Yeah, these things! So, as mentioned, I don’t have numbers to back this up but I’m going to go out on a limb and say that the MOV in a £130 PSU can probably handle at least the same as the MOVs in a £7 surge protector.

It’s hard to imagine a situation where there’s a surge that would have destroyed the PSU that would be mitigated by an external surge protector. It’s probably either going to take both of them out, or they’ll both survive. No Enterprise shields here, I’m afraid.

So is it not worth having a surge protector at all? Not quite. MOVs degrade with use, so if a surge protector handles some smaller surges, or takes bites out of bigger ones, it might prolong the life of the PSU. Maybe that’s worth it, especially if you find one of the (increasingly rare) ones with a decently low clamping voltage.

Addendum: covered equipment warranties and magic smoke

A bunch of surge protectors come with a warranty for downstream equipment. That sounds like a great deal, right? Even if there’s a huge surge that the protector can’t handle, at least you can replace the equipment? Alas, no. These warranties only cover if the surge protector doesn’t operate within its specifications. If you go over the max voltage, or the max current, or the max energy and all your equipment blows up, then the surge protector is merely working as designed. It’s meant to fail in those circumstances, and at that point all bets are off. No warranty money for you.

The other thing to bear in mind is that — in the UK at least — significant power surges aren’t common at all. If you travel with your computer then you’re more likely to come across dodgy electrics that can fry your computer than you are to hit a power surge. I’ve been to a lot of LAN events and have never heard of a surge protector popping and saving a computer; on the other hand I have seen an entire row of computers release their magic smoke because the electrician hadn’t connected the three-phase supply properly. There’s absolutely no protection to be had from that!

Photo credit: thanks to Greg for supplying the picture of the PSU so I didn’t have to take my computer apart.

Well, actually, it does a tiny bit before U_p because it’s not a binary switch, and life is messy. It won’t do much of anything before U_p. ↩︎

HTTP/2 and TLS Server Name Indication

2024-05-25T00:00:00Z

I was recently alerted to a bug in Centauri, a simple reverse proxy I wrote. The initial report was that it was serving completely the wrong website, but only sometimes, and it behaved differently in different browsers, and no-one else could reproduce it.

I use Centauri for all of my web-facing services (including this site!) so it’s a little surprising such a major bug would have escaped my notice. Shane, who first noticed the bug, was persistent though and eventually managed to figure out some exact reproduction steps.

A brief overview of Centauri and SNI

Centauri originally only proxied HTTPS requests¹. When it receives a HTTPS request, it first looks at the Server Name Indication (or SNI) field in the TLS ClientHello message. It uses this field to determine which TLS certificate to respond with (as one Centauri instance will typically serve many websites across many domain names, each with their own certificate). That’s what the field exists for: before SNI, if you wanted to host two HTTPS sites on the same machine you’d need separate IP addresses for them!

Once the TLS session was established Centauri would read in the HTTP request, select which backend it was going to be sent to based on the SNI field, and then proxy it on. The HTTP request itself contains a Host header which identifies which host the request is for, but that will always be the same as the SNI field… or so I thought.

HTTP connection reuse

When accessing a website, your browser will request dozens of resources in a short space of time: the webpage itself, some stylesheets, maybe some scripts, plus any images, fonts, videos, etc. It would be extremely inefficient to open a new connection for each individual request, as setting up the connection requires several round trips between the client and the server.

To address this issue, HTTP/1.1 formalised the idea of “persistent connections”, which allow the client to keep a connection open and send another request once the first has completed. HTTP/2 takes this a step much further and allows full multiplexing — sending multiple requests at once and allowing the server to respond out-of-order.

Obviously, you can only reuse the connection if you’re requesting further resources from the same host: if your browser makes a request to example.com and that includes a script from example.net, it has to open a new connection for the other domain. However, HTTP/2 expands this slightly:

For “https” resources, connection reuse additionally depends on
having a certificate that is valid for the host in the URI. The
certificate presented by the server MUST satisfy any checks that the
client would perform when forming a new TLS connection for the host
in the URI.

Putting it all together

The reproduction steps that Shane figured out involved visiting sites hosted on two subdomains. The first site to be visited got “stuck” and subsequent requests to the other site were routed there instead. This only worked for one specific domain, though, and it turns out because that domain was configured in Centauri to use a wildcard TLS certificate (i.e., the certificate served for the request to the first site was also valid for the second site).

The certificate being valid for both sites allowed the browser to use the same connection. This breaks my assumption that the SNI field would always match the HTTP host, as all requests are sent over the same TLS connection that had the SNI field set to the first site’s subdomain. While perfectly in spec, the behaviour is quite surprising.

The fix for this was trivial: Centauri now checks the HTTP Host header instead of routing based on the SNI field. I found the bug itself interesting though, as it has such an awkward set of conditions for it to occur:

There must be multiple sites that share a certificate (the default behaviour in Centauri is to obtain one certificate per site)
A user must visit two of those sites
The browser must still have a connection open to the first site when visiting the second

It’s also one of those rare bugs where everything is working as intended, it’s just that the intention was slightly wrong for some reason. In this case it was because I wasn’t aware of the fairly significant shift in behaviour introduced in HTTP/2 for that one tiny part of the spec².

Thanks again to Shane for the debugging he did to figure this all out!

It now also proxies HTTP requests but only if they come over a Tailscale connection. Otherwise, plain HTTP requests are redirected to HTTPS. ↩︎
I think it’s this kind of thing that drives software devs to become carpenters or farmers. You don’t suddenly get a Door 2.0 specification that invalidates all your assumptions about how hinges work when certain people try to open it. ↩︎

Why you should be using HTTPS

2016-06-17T00:00:00Z

The EFF’s HTTPS Everywhere logo

One of my favourite hobbyhorses recently has been the use of HTTPS, or lack thereof. HTTPS is the thing that makes the little padlock appear in your browser, and has existed for over 20 years. In the past, that little padlock was the exclusive preserve of banks and other ‘high security’ establishments; over time its use has gradually expanded to most (but not all) websites that handle user information, and the time is now right for it to become ubiquitous.

Why use HTTPS?

There are numerous advantages to using HTTPS, both for the users of a website and for the operator:

Privacy

The most obvious advantage is that HTTPS gives your users additional privacy. An insecure (HTTP) request can potentially be read by anyone on the same network, or the network operators, or anyone who happens to operate a network along the path between the user and the server.

Users on shared WiFi networks (such as those in coffee shops, hotels, or offices) are particularly vulnerable to passive sniffing by anyone else on that network. If the network is open (as is frequently the case) then anyone in radio range can see exactly what the user is up to.

Integrity

HTTPS also helps to maintain the integrity of your site. With a plain HTTP request, there’s nothing to stop anyone in between the server and the user from modifying the content of the request or the response. This is a frequent tactic used by annoying WiFi gateways (such as the ones you’d find in a hotel), dubious ISPs who want to serve you extra adverts, or just plain old nefarious attackers.

If you’re trying to convey some kind of information to users (and if you aren’t, why exactly are you running a website again?) it seems beneficial to both you and them if the information arrives as you intended, rather than in a modified form due to someone or something tampering with it.

Security

If your website has any kind of authentication, or session identifiers, it becomes extremely vulnerable to an attacker monitoring the traffic and stealing the credentials. This was starkly demonstrated in 2010 when Firesheep was released. This tool allowed anyone to quickly and automatically hijack social media accounts of anyone on the same network who was using HTTP to access them.

Even if your login pages are served over HTTPS, if you send a single session ID cookie over HTTP (such as a page you decided wasn’t particularly ‘important’) then an attacker can probably spoof the user’s session and gain full access to their account. Again, in the case of open WiFi networks that could be anyone in radio range.

Search engine rankings

Some search engines use HTTPS as a signal in their ranking algorithms. Google announced in 2004 that it was using the presence of HTTPS as a small positive signal, but that it may strengthen that signal over time as more and more websites switch to using a secure transport. It’s not unthinkable that at some point in the future there will be HTTPS-only search engines.

But… But… But…

There are lots of excuses for not implementing HTTPS. Most of them are either misguided or outdated.

It’s too expensive and/or complicated

In the past, getting HTTPS certificates was a pain. A number of free suppliers have existed for a while but the process for getting their certificates wasn’t particularly straight forward, and many imposed arbitrary restrictions on the certificate parameters. Even once you had the certificate, you had to fiddle about with your HTTP server configuration to make it work, remember to manually get a new certificate when the old one expired, and lots of other annoying busywork.

With the arrival of Let’s Encrypt, all that changed. You can retrieve and deploy a free HTTPS certificate with two or three commands. Renewal can be handled completely automatically with a single command executed by cron.

There’s no point; nothing on my site is sensitive

You might not think your content warrants privacy, but can you speak for everyone who accesses it? Even content that seems mundane to you — such as travel advice, or technical writing — could be used to build up a profile of a user. If an attacker is monitoring traffic in a coffee shop and sees a user looking at travel advice and weather forecasts for a foreign country, he could use that information to plan a burglary knowing that the user will be away. Similarly, some content which is perfectly mundane to you may actually be very sensitive in other countries with repressive governments. HTTPS makes it much harder for these people to snoop on traffic.

From another angle, if you’re offering any kind of information, instructions, or especially file downloads, there’s a severe risk to users if the content is modified on its way to them. An evil sysadmin could rewrite your travel advice to suggest visiting the local drug dealer’s hangout, or replace your download with a malware-infested version.

HTTPS is slower, uses more resources, etc

Back in 1995 this might have been a valid argument. Enabling HTTPS on a modern server will make an almost negligible difference to performance. If you also enable HTTP/2 (which most implementations only support over HTTPS), it’s likely to actually use fewer resources, and result in a faster, smoother experience for your users. HTTP/2 was designed to work with HTTPS, and designed with modern requirements and networking techniques in mind.

CloudFlare have an excellent demonstration of the benefits of HTTP/2, and it can show speed improvements of 2-3x in a typical environment. On top of being faster, HTTP/2 uses fewer connections which results in less resource overhead on both the server and the client.

So what are you waiting for?

If you run a website and aren’t using HTTPS, give it a try.