Certificates for localhost

So you have to check Origin/Referer at least I think.

Can you be sure Origin/Referer isn’t spoofed?

Then there’s DNS rebinding which can get around the SOP.

What about maybe strange ways that malformed requests could end up being reflected back to 127.0.0.1 through rebinding?

So it just seems to me that even binding to 127.0.0.1 you have to be ready for just about anything to come in on the socket.

Obviously the “server” API is extremely sensitive and I think you have to assume it is effectively exposed to the outside world, even with a 127.0.0.1 binding and a firewall.

I guess if you make localhost users literally login and establish a session then you could consider yourself safe. But it’s a weird experience logging into a local application. So whatever you are doing to authenticate the request as local, it has to be unspoofable.

I just don’t think I trust the HTTP headers enough!

The key isn't even distributed anywhere. It's generated locally and then marked trusted so the browsers don't show warnings.

Checking the list of certificates from time to time is a good idea, although I wonder if anyone really does that very often without some automated help, but in this case Blizzard was doing something that was not only fine (using a self-signed cert to secure local traffic) but the absolutely correct way to do this. (As additionally explained by Let's Encrypt themselves)

edit: I guess the one thing is: If you can find the certificate's private key you can serve your own server at that domain and launch an attack using a trusted certificate without needing admin permission to add your own malicious certificate.

"openssl req x509"

This is a dodge because we don't actually want to write a CSR and then sign the cert, we're going to skip all that so we're using a sub-feature of a different sub-feature. Fine.

"-out localhost.crt -keyout localhost.key"

There surely must be nicer ways to set this, but it's not so objectionable...

"-newkey rsa:2048"

This is arguably boiler-plate, the configuration file can set this default, but there's a good chance "your" config file was pasted in by an OS vendor ten years ago and says e.g. 1024-bit RSA, or worse.

"-nodes -sha256"

Now we're getting into the nonsense. We don't want DES encryption. Nobody wants DES encryption, and if we did want DES encryption we could specify the passphrase for it, which we didn't, so this needn't be here. SHA-256 has been the reasonable baseline choice here for years and so likewise we shouldn't need to specify.

"-subj '/CN=localhost'"

This is pointlessly arcane and shouldn't be needed, but it's only partly OpenSSL's fault. This abuse of X.509 Common Name was obsolete on the Internet last century, and it's annoying the people were still coming to terms with that in the last few years so that certs which lack Common Name often don't interoperate, and thus it's easier to put it in anyway.

"-extensions ...."

This part, which involves a multi-line sub-shell and other shenanigans, is completely out of hand. This is the shortest, least crazy way to ask for the certificate practically everybody running OpenSSL actually wants, and yet instead of being the default or offered with some easy to understand command line parameter, even in brand new versions of OpenSSL it's done only by this arcane hack.

All Web PKI certificates this century are supposed to use SANs (Subject Alternative Names), so you'd expect an openssl feature named say, "-san" which adds one such name, and OK, this being OpenSSL maybe you'd need to manually write "DNS:localhost" rather than it being smart enough to figure it out if you write "localhost". That'd be stupid, but par for OpenSSL. But no, you have to manually specify how SAN extensions even work in the X.509 certificate, as if it has never seen one before, even though every valid cert for the Web PKI has one. It's like if Firefox made you type not just the HTTP port default of 80 into URLs, but actually made you specify that you want to use TCP/IP in case maybe you're using Novell IPX or something.