Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I no longer have an old-school cert on my HTTPS site

rachelbythebay.com

Post reply on HN
Print view View original

91–100 of 437 posts

Re: Why I no longer have an old-school cert on my HTTPS site

#91

Post by q3k »

matja wrote: post #72
eadmund wrote: post #61

> So, yes, instead of saying that "e" equals "65537", you're saying that "e" equals "AQAB". Aren't you glad you did those extra steps? Oh JSON. For those unfamiliar with the reason here, it’s that JSON parsers cannot be relied upon to treat numbers properly. Is 4723476276172647362476274672164762476438 a valid JSON number? Yes, of course it is. What will a JSON parser due with it? Silently truncate it to a 64-bit or 6…

Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float? It's a shame JSON parsers usually default to performance rather than correctness, by using bignums for numbers.

Have a read through RFC7159 or 8259 and despair.

> This specification allows implementations to set limits on the range and precision of numbers accepted

JSON is a terrible interoperability standard.

Re: Why I no longer have an old-school cert on my HTTPS site

#92

Post by DonHopkins »

sam_lowry_ wrote: post #49
g-b-r wrote: post #42

Earlier quoted context omitted.

For god's sake, however complex ACME might be it's better than not supporting TLS

Why? The days of MITM boxes injecting content into HTTP traffic are basically over, and frankly they never were a thing in my part of the world. I see no other reason to serve content over HTTPS.

[flagged]

Re: Why I no longer have an old-school cert on my HTTPS site

#93

Post by ndsipa_pomu »

christina97 wrote: post #8
ndsipa_pomu wrote: post #4

I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu. My favourite client is probably https://github.com/acmesh-official/acme.sh If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should h…

I used to like them, then they somehow sold out to zerossl and switched the default there from LE after an update. Pinned to an old version and looking for a replacement right now.

I only started using it after the default was ZeroSSL, but it's easy to specify LetsEncrypt instead

Re: Why I no longer have an old-school cert on my HTTPS site

#94

Post by codeduck »

horsawlarway wrote: post #70
codeduck wrote: post #56

Earlier quoted context omitted.

Given her experience and work history, it's much more likely that she views any text-based protocol as an unnecessary abstraction over simply processing raw TCP.

Is this a joke? I don't even know where to begin with this comment... It reads like a joke, but I suspect it's not? TCP is just a bunch of bytes... You can't process a bunch of bytes without understanding what they are, and that requires signaling information at a different level (ex - in the bytes themselves as a defined protocol like SSH, SCP, HTTP, etc - or some other pre-shared information between server and clie…

parent mentioned SOAP as an alternative to JSON. I was being glib about the fact that the engineer who wrote this blog post is a highly-regarded sysadmin and SRE who tinkers on things ranging from writing her own build systems to playing with RF equipment.

Re: Why I no longer have an old-school cert on my HTTPS site

#95

Post by RiverCrochet »

pixl97 wrote: post #50
amiga386 wrote: post #35

Things change over time. Part of not wanting to let go is the sunk cost fallacy. Part of it is being suspicious of being (more) dependent on someone else (than you are already dependent on a different someone else). (As an aside, the n-gate guy who ranted against HTTPS in general and thought static content should just be HTTP also thought like that. Unfortunately, as I'm at a sketchy cafe using their wifi, his page c…

> thought static content should just be HTTP Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM. The only way it could possibly work is if the static content were signed somehow, but then you need another protocol the browser and you need a way to exchange keys securely, for example like signed RPMs. It would be less expensive as the encryption happens once, but…

Well there is the integrity atttribute. https://www.w3schools.com/Tags/att_script_integrity.asp

Re: Why I no longer have an old-school cert on my HTTPS site

#96

Post by unscaled »

oneplane wrote: post #15
tux3 wrote: post #6

JOSE/JWK is indeed some galactically overengineered piece of spec, but the rest seems.. fine? There are private keys and hash functions involved. But base64url and json aren't the worst web crimes to have been inflicted upon us. It's not _that_ bad, is it?

I personally don't see the overengineering in JOSE; as you mention, a JWK (and JWKs) is not much more than the RSA key data we already know and love but formatted for Web and HTTP. It doesn't get more reasonable than that. JWTs, same story, it's just JSON data with a standard signature. The spec (well, the RFC anyway) is indeed classically RFC-ish, but the same applies to HTTP or TCP/IP, and I haven't seen the same s…

I would argue that JOSE is complex for the sake of complexity. It's not nearly as bad as old cryptographic standards (X.509 and the PKCS family of standards) and definitely much better than XMLDSig, but it's still a lot more complex than it needs to be.

Some examples of gratuitous complexity:

1. Supporting too many goddamn algorithms. Keeping RSA and HMAC-SHA256 for leagcy-compatible stuff, and Ed25519 for XChaChaPoly1305 for regular use would have been better. Instead we support both RSA with PKCS#1 v1.5 signatures and RSA-PSS with MGF1, as well as ECDH with every possible curve in theory (in practice only 3 NIST Prime curves).

2. Plethora of ways to combine JWE and JWS. You can encrypt-then-sign or sign-then-encrypt. You can even create multiple layers of nesting.

3. Different "typ"s in the header.

4. RSA JWKs can specify the d, p, q, dq, dp and qi values of the RSA private key, even though everything can be derived from "p" and "q" (and the public modulus and exponent "n" and "e").

5. JWE supports almost every combination of key encryption algorithm, content encryption algorithm and compression algorithm. To make things interesting, almost all of the options are insecure to a certain degree, but if you're not an expert you wouldn't know that.

6. Oh, and JWE supports password-based key derivation for encryption.

7. On the other, JWS is smarter. It doesn't need this fancy shmancy password-based key derivation thingamajig! Instead, you can just use HMAC-SHA256 with any key length you want. So if you fancy encrypting your tokens with a cool password like "secret007" and feel like you're a cool guy with sunglasses in a 1990s movie, just go ahead!

This is just some of the things of the top of my head. JOSE is bonkers. It's a monument to misguided overengineering. But the saddest thing about JOSE is that it's still much simpler than the standards which predated it: PKCS#7/CMS, S/MIME and the worst of all - XMLDSig.

Re: Why I no longer have an old-school cert on my HTTPS site

#97

Post by ndsipa_pomu »

skywhopper wrote: post #7
ndsipa_pomu wrote: post #4

I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu. My favourite client is probably https://github.com/acmesh-official/acme.sh If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should h…

Certbot goes out of its way to be inscrutable about what it’s doing. It munges your web server config (temporarily) to handle http challenges, and for true sysadmins who are used to having to know all the details of what’s going on, that sort of script is a nightmare waiting to happen. I assume certbot is the client she’s alluding to that misinterprets one of the factors in the protocol as hex vs decimal and somehow…

> It munges your web server config (temporarily) to handle http challenges

I run it in "webroot" mode on NgINX servers so it's just a matter of including the relevant config file in your HTTP sections (likely before redirecting to HTTPS) so that "/.well-known/acme-challenge/" works correctly. Then when you do run certbot, it can put the challenge file into the webroot and NgINX will automatically serve it. This allows certbot to do its thing without needing to do anything with NgINX.

Re: Why I no longer have an old-school cert on my HTTPS site

#98

Post by tialaramex »

p_ing wrote: post #45
tialaramex wrote: post #34

One of the things this gestures at might as well get a brief refresher here: Subject Alternative Name (SAN) is not an alternative in the sense that it's an alias, SANs exist because the X.509 certificate standard is, as its name might suggest, intended for the X.500 directory system, a system from the 20th century which was never actually deployed. Mozilla (back then the Netscape Corporation) didn't like re-inventing…

Did browsers ever strictly require a SAN; they certainly didn't even as of ~10 years ago? Yes, it is "required", but CN only has worked for quite some time. I find this tricks up some IT admins who are still used to only supplying a CN and don't know what a SAN is.

> Did browsers ever strictly require a SAN;

Yes, all the popular browsers require this.

> they certainly didn't even as of ~10 years ago?

That's true, ten years ago it was likely that if a browser required this they would see unacceptably high failure rates because CAs were non-compliant and enforcement wasn't good enough. Issuing certs which would fail PKIX was prohibited, but so is speeding and yet people do that every day. CT improved our ability to inspect what was being issued and monitor fixes.

> Yes, it is "required", but CN only has worked for quite some time.

No trusted CA will issue "CN only" for many years now, if you could obtain such a certificate you'd find it won't work in any popular browser either. You can read the Chromium or Mozilla source and there just isn't any code to look in CN, the browser just parses the SANs.

> I find this tricks up some IT admins who are still used to only supplying a CN and don't know what a SAN is.

In most cases this is a sign you're using something crap like openssl's command line to make CSRs, and so you're probably expending a lot of effort filling out values which will be ignored by the CA and yet not offered parameters you did need.

Re: Why I no longer have an old-school cert on my HTTPS site

#99

Post by p_ing »

tialaramex wrote: post #98
p_ing wrote: post #45

Earlier quoted context omitted.

Did browsers ever strictly require a SAN; they certainly didn't even as of ~10 years ago? Yes, it is "required", but CN only has worked for quite some time. I find this tricks up some IT admins who are still used to only supplying a CN and don't know what a SAN is.

> Did browsers ever strictly require a SAN; Yes, all the popular browsers require this. > they certainly didn't even as of ~10 years ago? That's true, ten years ago it was likely that if a browser required this they would see unacceptably high failure rates because CAs were non-compliant and enforcement wasn't good enough. Issuing certs which would fail PKIX was prohibited, but so is speeding and yet people do that e…

You're forgetting that browsers deal with plenty of internal-only CAs. Just because a public CA won't issue a CN only cert doesn't mean an internal CA won't. That is why I'm curious to know if browsers /strictly/ require SANs, yet. Not something I've tested in a long time since I started supporting public-only websites/cloud infra.

As you noted about OpenSSL, Windows CertSvr will allow you to do CN only, too.

Post reply on HN