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

171–180 of 437 posts

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

#171

Post by JoshTriplett »

fc417fc802 wrote: post #162
JoshTriplett wrote: post #112

Earlier quoted context omitted.

> And can generally be configured by the user not to downgrade to http without an explicit prompt. Absolutely, and this works quite well on the current web. > Honestly I disagree with the refusal to support various APIs over http. There are multiple good reasons to do so. Part of it is pushing people to HTTPS; part of it is the observation that if you allow an API over HTTP, you're allowing that API to any attacker.

> if you allow an API over HTTP, you're allowing that API to any attacker. In the scenario I described you're doing that only after the user has explicitly opted in on a case by case basis, and you're forcing a per-session nag on them in order to coerce mainstream website operators to adopt the secure default. At that point it's functionally slightly more obtuse than adding an exception for a certificate (because tho…

> More generally, I support secure defaults but almost invariably disagree with disallowing users to shoot themselves in the foot.

I agree with this. But also, there is a strong degree to which users will go track down ways (or follow random instructions) to shoot themselves in the foot if some site they care about says "do this so we can function!". I do think, in cases where there's value in collectively pushing for better defaults, it's sometimes OK for the "I can always make my device do exactly what I tell it to do" escape hatch to be "download the source and change it yourself". Not every escape hatch gets a setting, because not every escape hatch is supported.

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

#172

Post by Arnavion »

bananapub wrote: post #54

tangentially, for anyone looking to make their lives easier, you can run `acme-dns` on a spared 53/udp somewhere, CNAME the _acme_challenge. from your real DNS hosting to that, then have `lego` or whatever do DNS challenges via acme-dns - no need to let inscrutable scripts touch your real DNS config, no need for anything to touch your HTTP config.

You can also use an NS record directly instead of CNAME'ing to a different domain.

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

#173

Post by kbolino »

bigstrat2003 wrote: post #137
pixl97 wrote: post #50

Earlier quoted context omitted.

> 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…

> Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM. Rather, it's that most people simply don't need to care about MITM. It's not a relevant attack for most content that can be reasonably served over HTTP. The goal isn't to eliminate every security threat possible, it's to eliminate the ones that are actually a problem for your use case.

MITM is a very real threat in any remotely public place. Coffee shop, airport, hotel, municipal WAN, library, etc. I honestly wouldn't put that much trust in a lot of residential/commercial broadband setups or hosting/colocation providers either. It does not matter what is intended to be served, because it can be replaced with anything else. Innocuous blog? Transparently replaced with a phishing site. Harmless image? Rewritten to appear the same but with a zero-day exploit injected.

There's no such thing as "not worth the effort to secure" because neither the site itself nor its content matters, only the network path from the site to the user, which is not under the full control of either party. These need not be, and usually aren't, targeted attacks; they'll hit anything that can be intercepted and modified, without a care for what it's meant to be, where it's coming from, or who it's going to.

Viewing it is an A-to-B interaction where A is a good-natured blogger and B is a tech-savvy reader, and that's all there is to it, is archaic and naive to the point of being dangerous. It is really an A-to-Z interaction where even if A is a good-natured blogger and Z is a tech-savvy user, parties B through Y all get to have a crack at changing the content. Plain HTTP is a protocol for a high-trust environment and the Internet has not been such a place for a very long time. It is unfortunate that party A (the site) must bear the brunt of the security burden, but that's the state of things today. There were other ways to solve this problem but they didn't get widespread adoption.

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

#174

Post by seanw444 »

donnachangstein wrote: post #131

OpenBSD has a dead-simple lightweight ACME client (written in C) as part of the base OS. No need to roll your own. I understand it was created because existing alternatives ARE bloatware and against their Unixy philosophy. Perhaps the author wasn't looking hard enough. It could probably be ported with little effort.

Yeah, was looking for someone to comment this. I use it. Works great.

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

#175

Post by ryukafalz »

01HNNWZ0MV43FF wrote: post #143
marcosdumay wrote: post #126

Earlier quoted context omitted.

What I don't understand is why you (and a lot of other people) just expect S-expression parsers to not have the exact same problems.

I think they mean that Common Lisp has bigints by default

As do Scheme and most other Lisps I'm familiar with, and integers/floats are typically specified to be distinct. I think we'd all be better off if that were true of JSON as well.

I'd be happy to use s-expressions instead :) Though to GP's point, I suppose we might then end up with JS s-expression parsers that still treat ints and floats interchangeably.

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

#176

Post by tialaramex »

fanf2 wrote: post #168
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…

Tedious and pedantic note: You can’t mindlessly compare the bytes of the host name: you have to know that it’s the presentation format of the name, not the DNS wire format; you have to deal with ASCII case insensitivity; you have to guess what to do about trailing dots (because that isn’t specified); you have to deal with wildcards (being careful to note that PKIX wildcard matching is different from DNS wildcard matc…

In practice it's much easier than you seem to have understood

The names PKIX writes into dnsName are exactly the same as the hostnames in DNS. They are defined to always be Fully Qualified, and yet not to have a trailing dot, you don't have to like that but it's specified and it's exactly how the web browsers worked already 25+ years ago.

You're correct that they're not the on-wire label-by-label DNS structure, but they are the canonical human readable DNS name, specifically the Punycode encoded name, so [the website] https://xn--j1ay.xn--p1ai/ the Russian registry which most browsers will display with Cyrllic, has its names stored in certificates the same way as it is handled in DNS, as Punycode "xn--j1ay.xn--p1ai". In software I've seen the label-by-label encoding stuff tends to live deep inside DNS-specific code, but the DNS name needed for comparing with a certificate does not do this.

You don't need to "deal with" case except in the sense that you ignore it, DNS doesn't handle case, the dnsName in SANs explicitly doesn't carry this, so just ignore the case bits. Your DNS client will do the case bit wiggling entropy hack, but that's not in code the certificate checking will care about.

You do need to care about wildcards, but we eliminated the last very weird certificate wildcards because they were minted only by a single CA (which argued by their reading they were obeying PKIX) and that CA is no longer in business 'cos it turns out some of the stupid things they were doing even a creative lawyerly reading of specifications couldn't justify. So the only use actually enabled today is replacing one DNS label at the front of the name. Nothing else is used, no suffixes, no mid-label stuff, no multi-label wildcards, no labels other than the first.

Edited to better explain the IDN situation hopefully

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

#178

Post by reichstein »

matja wrote: post #102
q3k wrote: post #91

Earlier quoted context omitted.

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.

So a JSON parser that cannot store a 2 is technically compliant? :(

JSON is a text format. A parser must recognize the text `2` as a valid production of the JSON number grammar.

Converting that text to _any_ kind of numerical value is outside the scope of the specification. (At least the JSON.org specification, the RFC tries to say more.)

As a textural format, when you use it for data interchange between different platforms, you should ensure that the endpoints agree on the _interpretation_, otherwise they won't see the same data.

Again outside of the scope of the JSON specification.

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

#179

Post by Bluecobra »

anishathalye wrote: post #165
Arnavion wrote: post #122

If you want to actually implement an ACME client from first principles, reading the RFC (plus related RFCs for JOSE etc) is probably easier than you think. I did exactly that when I made a client for myself. I also wrote up a digested description of the issuance flow here: https://www.arnavion.dev/blog/2019-06-01-how-does-acme-v2-wo... It's not a replacement for reading the RFCs, but it presents the information in th…

Implementing an ACME client is part of the final lab assignment for MIT’s security class: https://css.csail.mit.edu/6.858/2023/labs/lab5.html

Nice thanks! I’ve been wanted to learn it as dealing with cert expirations every year is a pain. My guess is that we will have 24 hour certs at some point.

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

#180

Post by xeromal »

kevingadd wrote: post #149
q3k wrote: post #105

Earlier quoted context omitted.

Yep. Or one that parses it into a 7 :)

I once debugged a production issue that boiled down to "A PCI compliance .dll was messing with floating point flags, causing the number 4 to unserialize as 12"

That sounds awful. lol
Post reply on HN