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

321–330 of 437 posts

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

#321

Post by dijit »

foobiekr wrote: post #184
bigstrat2003 wrote: post #135

Earlier quoted context omitted.

There's no good reason to serve a blog over TLS. You're not handling sensitive data, so unencrypted is just fine.

The reason is to prevent your site from becoming a watering hole where malicious actors use it to inject malware into the browsers of your users. TLS isn't for you, it's for your readers.

but like, who’s doing that?

Maybe the answer is disabling the JS runtime on non-TLS sites, maybe that has the added benefit of making the web (documents and “posters”) light again.

SMS is unencrypted, phone calls are unencrypted- yet we don’t worry nearly as much about people injecting content or modifying things. Because we trust out providers, largely, but the capability 100% exists for that; with no actual recourse. With browsing the internet we do have recourse- optionally use a VPN.

All of this security theatre is just moving the trust around, I would much rather make laws that protect the integrity of traffic sent via ISPs than add to the computational waste from military grade encrypting the local menu for the pizza shop.

Worse still, the pizza shop won’t go through the effort so they either won’t bother having a website or will put it on facebook or some other crazy centralised platform.

I’ll tell you something, I trust my ISP (Bahnhof- famous for protecting thepiratebay) a lot more than I trust Facebook not to do weird moderation activities.

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

#322

Post by dwattttt »

int_19h wrote: post #292
deepsun wrote: post #287

Earlier quoted context omitted.

Some parsers, like PHP, may treat 65537 and "65537" the same. Room for vulnerability.

Why would they do so? It's semantically distinct JSON, even JS itself treats it differently?

Time for a trip to the Abbey of Hidden Absurdities.

http://www.thecodelesscode.com/case/161

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

#323

Post by zubspace »

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…

Wouldn't it just solve a whole lot of problems if we could just add optional type declarations to json? It seems so simple and obvious that I'm kinda dumbfounded that this is not a thing yet. Most of the time you would not need it, but it would prevent the parser from making a wrong guess in all those edge cases.

Probably there are types not every parser/language can accept, but at least it could throw a meaningful error instead of guessing or even truncating the value.

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

#324

Post by BlackFly »

anonymousiam wrote: post #277
aaronmdjones wrote: post #223

Earlier quoted context omitted.

If the leading bit is set, it could be interpreted as a signed negative number. Prepending 00 guarantees that this doesn't happen.

Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. I don't really buy this explanation. It's a very large unsigned number. Everyone knows this. Is there some arbitrary precision library in use that forces large integers to be signed? Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the…

Java BigInteger is signed.

https://docs.oracle.com/javase/8/docs/api/java/math/BigInteg...

You deserialize with a leading 0x80 you don't get a working key. You can check the bit or you can just prepend a 0x00.

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

#325

Post by mkup »

nickf wrote: post #282
jchw wrote: post #214

Earlier quoted context omitted.

FWIW, it is ZeroSSL. I want there to be more major ACME providers than just LE, but I'm not sure about ZeroSSL, personally. It seems to have the same parent company as IdenTrust (HID Global Corporation). Probably a step up from Honest Achmed but recently I recall people complaining that their EV code signing certificates were not actually trusted by Windows which is... Interesting.

ZeroSSL is owned by Identrust, but the infra is operated by another CA. Also Microsoft killed EV codesigning early last year - not stopping it working, just making it identical to ‘normal’ codesigning certs.

Could you please provide more info on this topic, e.g. a link? I intended to buy EV code signing certificate as a sole proprietor to fix long-standing problem with my software when Windows Defender pops up every time I release a new version. Is EV code signing certificate no longer a viable solution to this problem? Is there no longer a difference between EV and non-EV code signing certificate?

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

#326

Post by pornel »

tsimionescu wrote: post #276
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…

This seems like a just-so story. Your explanation could make some sense if we were comparing {"e" : "AQAB"} to {"e" : 65537}, but there is no reason why that should be the alternative. The JSON {"e" : "65537"} will be read precisely the same way by any JSON parser out there. Converting the string "65537" to the number 65537 is exactly as easy (or hard), but certainly unambiguous, as converting the string "AQAB" to th…

For very big numbers (that could appear in these fields), generating and parsing a base 10 decimal representation is way more cumbersome than using their binary representation.

The DER encoding used in the TLS certificates uses the big endian binary format. OpenSSL API wants the big endian binary too.

The format used by this protocol is a simple one.

It's almost exactly the format that is needed to use these numbers, except JSON can't store binary data directly. Converting binary to base 64 is a simple operation (just bit twiddling, no division), and it's easier than converting arbitrarily large numbers between base 2 and base 10. The 17-bit value happens to be an easy one, but other values may need thousands of bits.

It would be silly for the sender and recipient to need to use a BigNum library when the sender has the bytes and the recipient wants the bytes, and neither has use for a decimal number.

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

#327

Post by ivanbakel »

zubspace wrote: post #323
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…

Wouldn't it just solve a whole lot of problems if we could just add optional type declarations to json? It seems so simple and obvious that I'm kinda dumbfounded that this is not a thing yet. Most of the time you would not need it, but it would prevent the parser from making a wrong guess in all those edge cases. Probably there are types not every parser/language can accept, but at least it could throw a meaningful e…

I doubt that would fix the issue. The real cause is that programmers mostly deal in fixed-size integers, and that’s how they think of integer values, since those are the concepts their languages provide. If you’re going to write a JSON library for your favourite programming language, you’re going to reach for whatever ints are the default, regardless of what the specs or type hints suggest.

Haskell’s Aeson library is one of the few exceptions I’ve seen, since it only parses numbers to ‘Scientific’s (essentially a kind of bigint for rationals.) This makes the API very safe, but also incredibly annoying to use if you want to just munge some integers, since you’re forced to handle the error case of the unbounded values not fitting in your fixed-size integer values.

Most programmers likely simply either don’t consider that case, or don’t want to have to deal with it, so bad JSON libraries are the default.

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

#328

Post by quicksilver03 »

orion138 wrote: post #47

Not the main point of the article, but the author’s comments on Gandi made me wonder: What registrar do people recommend in 2025?

Distribute your domain across 2, better 3 registrars, so if one does something stupid with your domains at least the others keep working.

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

#329

Post by pornel »

The numbers are sent in this peculiar format, because that's how they are stored in the certificates (DER encoding in x509 uses big endian binary), and that's the number format that OpenSSL API uses too.

It looks silly for a small value like 65537, but the protocol also needs to handle numbers that are thousands of bits long. It makes sense to consistently use the same format for all numbers instead of special-casing small values.

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

#330

Post by immibis »

tialaramex wrote: post #239
ipdashc wrote: post #167

Earlier quoted context omitted.

ACME is cool (compared to what came before it), but I'm kind of sad that EV certs never seemed to pan out at all. I feel like they're a neat concept, and had the potential to mitigate a lot of scams or phishing websites in an ideal world. (That said, discriminating between "big companies" and "everyone else who can't afford it" would definitely have some obvious downsides.) Does anyone know why they never took off?

EV can't actually work. It was always about branding for the for-profit CAs so that they have a premium product which helps the line go up. Let me give you a brief history - you did ask. In about 2005, the browser vendors and the Certificate Authorities began meeting to see if they could reach some agreement as neither had what they wanted and both might benefit from changes. This is the creation of the CA/Browser Fo…

Still sounds better than nothing. And gives companies an incentive to register under their actual names.
Post reply on HN