Implementing an ACME client in python using pyca/cryptography (or in Go) would be fine, but why do it in C++ ?
Why I no longer have an old-school cert on my HTTPS site
101–110 of 437 posts
Re: Why I no longer have an old-school cert on my HTTPS site
#102Earlier quoted context omitted.
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.
So a JSON parser that cannot store a 2 is technically compliant? :(
Re: Why I no longer have an old-school cert on my HTTPS site
#103Earlier quoted context omitted.
Some people don't want to be forced to run a bunch of stuff they don't understand on the server, and I agree with them. Sadly, security is a cat and mouse game, which means it's always evolving and you're forced to keep up - and it's inherent by the nature of the field, so we can't really blame anyone (unlike, say, being forced to integrate with the latest Google services to be allowed on the Play Store). At least yo…
> Some people don't want to be forced to run a bunch of stuff they > don't understand on the server, and I agree with them. Honest question: * Do you understand OS syscalls in detail? * Do you understand how your BIOS initializes your hardware? * Do you understand how modern filesystems work? * Do you understand the finer details of HTTP or TCP? Because... I don't. But I know enough about them that I'm quite convince…
An OS is (at least generally) a prerequisite. If minimalism is your goal then you'd want to eliminate tangentially related things that aren't part of the underlying requirements.
If you're a fan of left-pad I won't judge but don't expect me to partake without bitter complaints.
Re: Why I no longer have an old-school cert on my HTTPS site
#104Earlier quoted context omitted.
How do browsers distrust HTTP, exactly?
They show any site served over HTTP as explicitly not secure in the address bar (making HTTPS the "default" and HTTP the visibly dangerous option), they limit many web APIs to sites served over HTTPS ( https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ) , https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ), they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-onl…
> they increasingly attempt HTTPS to a site first even if linked/typed as http
And can generally be configured by the user not to downgrade to http without an explicit prompt.
Honestly I disagree with the refusal to support various APIs over http. Making the (configurable last I checked) prompt mandatory per browser session would have sufficed to push all mainstream sites to strictly https.
Re: Why I no longer have an old-school cert on my HTTPS site
#105Earlier 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? :(
Yep. Or one that parses it into a 7 :)
Re: Why I no longer have an old-school cert on my HTTPS site
#106Earlier quoted context omitted.
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 XChaChaPol…
It's bonkers if you don't need it, just like JSONx (JSON-as-XML) is bonkers if you don't need it. But standards aren't for a single individual need, if they were they wouldn't be standards. And some people DO need these variations.
Take your argument about order of operations or algorithms. Just because you might not need to do it in an alternate order or use a legacy (and broken) algorithm doesn't mean nobody else does. Keep in mind that this standard isn't exactly new, and isn't only used in startups in San Francisco. There are tons of systems that use it that might only get updated a handful of times each year. Or long-lived JWTs that need to be supported for 5 years. Not going to replace hardware that is out on a pole somewhere just because someone thought the RFC was too complicated.
Out of your arguments, none of them require you to do it that way. Example: you don't have to supply d, dq, dp or qi if you don't want to. But if you communicate with some embedded device that will run out of solar power before it can derive them from the RSA primitives, you will definitely help it by just supplying it on the big beefy hardware that doesn't have that problem. It allows you to move energy and compute cost wherever it works best for the use case.
Even simpler: if you use a library where you can specify a RSA Key and a static ID, you don't have to think about any of this; it will do all of it for you and you wouldn't even know about the RFC anyway.
The only reason someone would need to know the details is if you don't use a library or if you are the one writing it.
Re: Why I no longer have an old-school cert on my HTTPS site
#107Earlier quoted context omitted.
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…
Imagine coming from JWK and having to encode that public key into a CSR or something with that attitude.
Imagine writing your own security software when there are proven systems that just take that problem out of your hands so you don't need to complain about it.
Re: Why I no longer have an old-school cert on my HTTPS site
#108Earlier quoted context omitted.
> I don't understand the tone of aggression against ACME and their plethora of clients. > ACME idea good, ACME implementation bad. Maybe I'm misreading but it sounds like you're on a similar page to the author. As they said at the top of the article: > Many of the existing clients are also scary code, and I was not about to run any of them on my machines. They haven't earned the right to run with privileges for my pr…
Im not a container guru by any means (at least not yet?) but would docker not suffice these concerns?
Yes, it does.
I run acme in a non privileged jail whose file system I can access from outside the jail.
So acme sees and accesses nothing and I can pluck results out with Unix primitives from the outside.
Yes, I use dns mode. Yes, my dns server is also a (different) jail.
Re: Why I no longer have an old-school cert on my HTTPS site
#109Earlier quoted context omitted.
> Some people don't want to be forced to run a bunch of stuff they don't understand on the server It's not just about not understanding, it's that more complex stuff is inherently more prone to security vulnerabilities, however well you think you reviewed its code.
> It's that more complex stuff is inherently more prone to security vulnerabilities That's overly simplifying it and ignores the part where the simple stuff is not secure to begin with. In the current context you could take a HTTP client with a formally verified TLS stack, would you really say it's inherently more vulnerable than a barebones HTTP client talking to a server over an unencrypted connection? I'd say ther…
The alternative of the article was ACME vs other ways of getting TLS certificates, not https vs http.
Of course plain http would be, generally, much more dangerous than a however complex encrypted connection
Re: Why I no longer have an old-school cert on my HTTPS site
#110Earlier quoted context omitted.
How do browsers distrust HTTP, exactly?
They’ve been making it harder and harder to serve things over HTTP-only for a while now. Steps like marking HTTP with big “NOT SECURE” labels and trying to auto-push to HTTP have been pretty effective. (With the exception of certain contexts, I think this is a generally good trend, FWIW.)
I have to change two settings to be able to see plain http things, and luckily I only need to a handful of times a year.
If I'm really curious about your plain http site I'll check it out through archive.org, and I'm definitely not going to keep visiting it frequently.
It's been easy to live with forced https for at least five years (and for at least the last ten with https first, with confirmations for plain http).