agwa

What's particularly crazy about this interchange is that there is going to be a second, elevated peanut roundabout that's rotated 90 degrees, for buses to use: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg...

You would think so, but even an authentication company screwed it up:

https://cybercx.co.nz/blog/json-web-token-validation-bypass-...

The cost is the vigilance required to use them safely. It's not just compute/storage costs.

Fair enough, but those optimizations are basically free. People think stateless tokens are free but they really are not.

As someone who operates a PostgreSQL database containing 27 billion SSL certificates, each 1-2kb each, with a bunch of secondary indexes that get inserted in random order, I find it pretty incredible that people see the need to optimize their session database. At what scale does the size of the session database actually matter?

Those stateless tokens may be "unforgeable", but they are replayable, and if you're not mindful of that you can have security vulnerabilities.

Aw, thanks :-)

The blog post provides a certificate chain that validates in OpenSSL but not in Go.

The reason it doesn't validate in Go is that the Subject field in the CA certificate uses a different string encoding than the Issuer field in the leaf certificate, so the fields are not byte-for-byte equal.

Go requires the Issuer and Subject to be byte-for-byte equal. This was permitted by older specs, but RFC 5280 changed the rules to require the use of RFC 4518 (LDAP stringprep) for comparing strings. This turned a simple memcmp into a complicated algorithm that requires implementing Unicode normalization, for virtually zero benefit. That's the last thing you want in your security-critical certificate verifier, so Go quite sensibly chose to follow the older specs in this regard. The CA/Browser Forum's Baseline Requirements also mandate byte-for-byte equality, so Go's behavior won't cause publicly-trusted certificates to be incorrectly rejected.

Note that LDAP stringprep is so complicated that OpenSSL doesn't even try to implement it properly and uses an approximation instead. So you would also be able to "fool" OpenSSL into rejecting certificate chains that RFC 5280 says are valid.

The blog post says that this is an "ongoing debate" in the Go project but I don't think that's accurate. I'd be shocked if they ever changed this behavior, given that crypto/x509 targets publicly-trusted certificates and the current behavior is so much simpler.

The following go flags let you build statically-linked cgo binaries, provided that all the C libraries that you're using support static linking and don't call the NSS functions in glibc:

-tags netgo,osusergo -linkmode external -extldflags -static

I regularly compile (cross-compile, even) static Go binaries that use the cgo sqlite package. But it's certainly a lot simpler if you can avoid cgo.

I think that on Unixes without overcommit, people allocate massive amounts of swap so that fork never fails.

Yeah, I agree. No criticism of Go's behavior is intended; just pointing out that the RFC is technically dead.

That RFC is obsoleted by https://datatracker.ietf.org/doc/html/rfc9844 which removes all guidance around URIs:

This document completely obsoletes [RFC6874], which implementors of web browsers have determined is impracticable to support [LINK-LOCAL-URI], and replaces it with a generic UI requirement. Note that obsoleting [RFC6874] reverts the change that it made to the URI syntax defined by [RFC3986], so [RFC3986] is no longer updated by [RFC6874]. As far as is known, this change will have no significant impact on non-browser deployments of URIs.

The downside is that to get the size optimization, TLS servers will get moderately more complicated (they'll need to have multiple MTC certificates configured and select the right one depending on the client's state), and TLS clients will get considerably more complicated (they'll need to continuously download landmarks for each CA out-of-band from a trusted source).

I expect many non-browser TLS clients won't support the small landmark-relative certificates, because there isn't a clear party to operate the landmark distribution service (Chrome has Google, and Firefox has Mozilla, but who does curl have?). I'm also worried that support will be lacking in open source TLS servers, though that's a more tractable problem. Consequentially, I expect the large standalone certificates to be quite common outside of connections between browsers and CDNs.

You'll be able to immediately use use a "standalone certificate" while waiting for the batch to be created. The tradeoff is that the standalone certificate will have multiple huge ML-DSA signatures.

Right, I read all that and I didn't see anything to indicate that AI is being used to write code - just one person's unsubstantiated claim.

Where do you see that about Postfix? I followed the links and the only thing I see is that AI is being used to find bugs, not write code.

Those changes were passed during the first Trump administration by a Republican congress, though they didn't go into effect until Biden was in office.

https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2023/tcja-chan...

If you want your dev environment to be as similar to prod as possible, and you use a proxy in prod, then you should use a proxy in dev also. I was presenting a solution to someone who doesn't want to do that.

Do be aware that CGI, unlike FastCGI, has a pretty big footgun due to the use of environment variables to convey HTTP headers: https://httpoxy.org/

Go's CGI server implementation doesn't set $HTTP_PROXY so you're safe from that, but I still don't love how CGI uses environment variables.

Please see the section about untrusted headers - this is not fixed by HTTP/2.

You're right that being able to point your browser right at the app is very convenient. With Go, you can have a command line flag that switches between http.Serve (for development) and fcgi.Serve (for production).

Putting security-critical logic in proxies is a violation of the End-to-End Principle, not an example of it. That doesn't mean it's a bad thing; as ragall notes, the End-to-End Principle doesn't make sense here.

You're correct that if the proxy removes all unknown headers, you're safe (with HTTP/2). But that sounds extremely inconvenient - before your application can use a new header, you have to talk to the team who runs the proxy. And popular reverse proxy software doesn't do that by default so it remains a huge footgun for the unwary. All completely avoided with FastCGI.

Go's embedded HTTP server can handle it just fine: https://blog.gopheracademy.com/advent-2016/exposing-go-on-th...

That is way! Unfortunately, sometimes you have to do path-based routing to different backends, and now you're back to needing a proxy between your clients and your applications.

What you're looking for is mod_proxy_fcgi, not FPM. It's included in Fedora's httpd-core package; I don't know about RHEL: https://packages.fedoraproject.org/pkgs/httpd/httpd-core/fed...

I'll note that while X.509 certificates are deployed widely on the Internet, they are not deployed in the manner the ITU intended. There is no global X.500 directory and Distinguished Names are just opaque identifiers that are used to help find issuers during chain building. That hardly counts as a win for the ITU in my book.

Oh wow, thanks for those numbers!

Since mmbleh mentioned Linode I'm guessing they're more concerned with traffic from servers, where CGNAT is uncommon. But even that may be changing - https://blog.exe.dev/ssh-host-header

I don't doubt your experience, but I wouldn't expect it to continue. I don't think Tuna-Fish is correct that "most" of the IPv4 world is behind CGNAT, but that does appear to be the trend. You can't even assume hosting providers give their subscribers their own IPv4 addresses anymore. On the other hand, there's a chance providers like Linode will eventually wise up and start giving subscribers their own /64 - there are certainly enough IPv6 addresses available for that, unlike with IPv4.

Correct.

Even a million rounds of hashing only adds 20 bits of security. No need if your secret is already 128 bits.

But JWTs are usually used as bearer tokens when doing API authentication. Those are definitely secrets that need to be scanned for.

Or are you suggesting that the API requests are signed with a private key stored in an HSM, and the JWT certifies the public key? Is that common?

Instead of using a CA, why not set the key's PIN policy to "once" and use an agent (e.g. https://github.com/FiloSottile/yubikey-agent/) that holds an active session to the yubikey? You start the agent at the beginning of the day, enter the PIN once, and then stop the agent at the end of the day.

Fun fact - in C++ std::sort has undefined behavior, and can crash[1], if you try to sort a container with NaNs in it.

[1] https://stackoverflow.com/questions/18291620/why-will-stdsor...