> Founded and sold this venture and had a great time doing it. It was a 24/7 on-screen AI therapist/companion for people with extreme anxiety/mental issues. After selling it, I made it public for free to help as many people as possible, and it had a 4.8/5 rating by a total of 50+ reviews and thousands of users. However, I shut it down for good on December 2023 due to server costs
You sold it, but continued to control it and pay for it, and then also made it free? How does that work? What did you sell exactly?
Only asking because others may be as confused as I am :)
Looks very nice and clean visually. I have some suggestions from a lookup or two:
- Add support for SVCB and HTTPS records
- When you lookup CAA, you return flags as a string. It should be an integer.
- JSON is nice as an option, but I would optimise the output for people to read.
- I really like the main font. The subtitle under the logo ("A simple DNS lookup tool") looks thin in comparison. I would consider using the same chunky font for it as elsewhere. It could look nicer.
Just one UI suggestion - in a bright room, I had to spend a few moments to figure out where to type as the borders around the text box was very faint and nearly invisible till I clicked on it. Either make the text border brighter or better still, why not place the cursor in the text box by default on page load so that txt box is highlighted by default?
- Show response status. For example, when you lookup a non-existent domain, you say "No records returned", but that's not accurate. You should show NXDOMAIN so that it's clear the domain doesn't exist. You may get NOERROR and no records.
I am not sure this is a 100% match for what you're looking for, but my OpenSSL Cookbook (free) has a chapter where you go through all the necessary steps to generate a root CA, intermediates, server and client certificates. You'll learn a lot by going through this exercise while paying attention to the configuration files.
I looked at NIST's PKITS while building the test suite. We ultimately decided to punt on it for the first round of tests, primarily because it fell slightly out of scope of our MVP on Python Cryptography (being strictly a RFC 3280 suite). We instead chose to integrate the BetterTLS suite[1] (warning: very large page) for the MVP.
With that being said: x509-limbo is open source, and I would be overjoyed if someone added a new `nist::pkits` or similar namespace for these :-). I can't promise that it's an immediate priority for us to add ourselves, however.
> are any of the test cases taken from Chrome's codebase?
Nope. That would also be a valuable thing to have here.
I'm thinking about CRL update windows: a lot of CAs run weekly updates, meaning that CRL changes don't propagate to end users for up to a week at a time. That's well into "security theater" territory for me, given that a compromised CA or EE only needs to fool me for a matter of seconds, once.
Sure, but then you can just use OCSP. If you care about privacy very much, support only stapled OCSP.
CRL is better suited for "high-volume" exchanges, for example for a CA to publish all their revocations [so that a system such as CRLite can be built].
I am sorry, I can't watch someone else's talk to understand what you mean. If you're willing to engage in a conversation, could you say here what you think the problems with OCSP are? (If you're not, just ignore me.)
As I see it, the main problem is that browsers don't want to do OCSP any more. Sure, we have a problem with how stapling is implemented in _some_ popular platforms (but not Caddy—hi Matt), but today maybe even those are fixed. The main problem IMO is that browsers won't support must-staple.
In the interest of full transparency, I have a pet peeve about people saying revocation doesn't work. I appreciate that that's the current reality, but—again—only because browsers choose not to implement it. Things would change overnight if Chrome (obviously) changed their stance.
Sure! I'm happy to discuss, my reason for referencing the video is because I think 'mcpherrim explains this stuff better than I do :-).
My understanding is that the primary concerns with OCSP (meaning non-stapled OCSP) are that it (1) leaks end user intent to CAs, such as sites being visited, and (2) in its original form with no transport security, it is no stronger than the adversary that it needs to protect TLS/the Web PKI against (i.e., any network adversary can block the OCSP request and everything will fail open).
OCSP stapling avoids both of those concerns, but requires web server and other stack changes that are not on the "enforcement" path in the way that CAs and other "direct" parts of the PKI are. The talk infers that this is why OCSP adoption has been so sluggish (which I didn't realize was the case before).
FWIW, I'm sorry if I came across as dogmatic here -- revocation is conceptually important, and I think it'd be great if we ended up in a Web PKI where revocation was more effective. But I can also see why browsers have fumbled and/or dragged their feet on the CRLs and OCSP for so long.
Yes, agreed on the primary problem with "classic" OCSP. OCSP stapling and must-staple (for the benefit of other readers: a flag that's set on a certificate to indicate that it's only valid with an attached—stapled—fresh OCSP response) solves that.
When must-staple initially came out, it came to light that web servers viewed OCSP stapling as a performance optimisation. When viewed from this perspective, it's not necessary to staple 100% correctly; if you don't, clients just go to the CA directly. Unfortunately, this breaks apart with must-staple and clients who refuse to talk to Cash for privacy reasons.
Browsers refused to enforce must-staple because that would mean broken web sites and they didn't want to be blamed for it. As a result, web servers didn't have an incentive to fix their broken OCSP stapling implementations.
There's also some politics involved. Browsers don't actually want CAs to be able to revoke certificates for reasons other than security. Think one government pressuring a CA in their country to revoke a certificate of an entity outside the country, for political reasons.
(EDIT I don't really support this argument. Any organisation that cares about their availability should always have two active certificates from difference CAs. There's a variety of CA jurisdictions to choose from as well.)
I don't like these long discussion chains as much as the next guy, but there's a lot of nuance and history when it comes to certificate revocation, and I sometimes take the opportunity to gently question people's beliefs. The line "revocation doesn't work" is very often repeated and technically it's not wrong, but I think it's important for people to understand how we got here.
CRL/OCSP (which are the only revocation mechanisms close to being generally used standards today) require either online verification (which is unsuitable or unsafe for many applications) or CRL distribution with CA trust root bundles, which is always in danger of being stale.
Not quite. OCSP responses can be stapled to TLS handshakes to provide fresh revocation information. Online is needed if you want 100% fresh information, of course.
PKI uses are not limited to TLS, and TLS uses are not limited to those where revocation information is readily accessible (due to proxying/distribution/compartmentalization/federation constraints).
There is a variety of signature standards and protocols out there that rely on PKI to manage trust, and whose users are not at all keen on calling an untrusted URL to check an intermediate cert.
That's a fair point [PKI without TLS], but I'd argue that 99.9% of situations will be with TLS. Thus supporting revocation can provide value for those.
Out of curiosity, what without-TLS use cases do you have in mind?
Most SSO runs on SAML, which uses XML Signature, which uses PKI certificate chains without TLS.
Even if you think all SSO will migrate to OIDC, the EU has enacted laws around electronic signatures that basically enshrine the use of XML Signature (with all its problems) for the foreseeable future. A lot of countries beyond the EU (many LatAm countries, for example) have followed suit.
There are other signature protocols that use certificate chains as well, and devices and networks that should not be making network calls when validating such signatures.
And as I mentioned, TLS uses are not limited to those where revocation information is readily accessible.
Do you think that it's possible to implement a good path building algorithm without support for revocation? For example, without revocation checking you may select a chain with a revoked certificate in it, only to discover that later. Then what? :) On the other hand, if you check the revocation status as part of the process, you can pivot to another certificate.
I think so -- I would consider crypto/x509's implementation good, and they similarly don't support revocation. More bluntly: it's not clear that revocation really works at all in the Web PKI; I've heard it described more as "homeopathic" than an actual security mechanism.
What makes a path building implementation good is (IMO) its adherence to the rules Ryan Sleevi enumerates[1]: as long as you conceptualize the path building process as a dynamic search problem rather than a static one with a "single" result, any implementation you build will probably have the right "primitives" for future constraints (like revocations).
I do believe revocation in the webpki is important to implement, but it's not great today.
There are two promising paths forward, which are complementary: The simple option is short-lived certificates (7 days), which essentially don't require revocation as that's the timeline existing revocation technology can revoke on, but that has some adoption hurdles to overcome in the future.
They are collecting all CRLs from all public web CAs and producing a small, compressed representation of all revoked certificates. That can be pushed to clients, so there's no need for any network traffic (like OCSP checks or CRL downloads) to the wide variety of CAs in the ecosystem.
These "CRL Compact and Push" solutions benefit from shorter-lived certificates (eg, 90 days like Let's Encrypt does right now) because the set of revoked certs is smaller as they roll off once they expire.
I suspect platform verifiers like on Windows and Mac will hopefully ship something like this in the future, though they already have CRL and OCSP fetching and caching.
Non-platform verifiers like this one are really the hardest part to solve revocation. I would suggest supporting CRL checks, but that requires having disk space and caching infrastructure, which is hard for a library to know how to do universally. I think the answer is that we need to have most of our software outsource to a platform verifier, or at least some sort of system-wide revocation information cache or daemon. Maybe this means a new systemd component on Linux :)
There is also the third option, via must-staple, where OCSP responses are attached to the TLS handshake. This resolves the privacy issue [because otherwise clients have to talk directly to CAs and reveal what sites they're visiting].
All (big) browsers have mechanisms functionally similar to CRLite. Apple has "valid" (not sure if that's the official name) and Google has CRLSets.
Google's CRLSets don't cover nearly the full set of revocations (AFAIK).
I don't know the details of how "valid" works, but as the Apple root program has recently required CAs to publish full CRLs, I assume they're planning something similar.
I mostly cite CRLite as it's well-documented.
I don't think OCSP must-staple is deployable. It requires code changes to effectively every webserver in the world, and that doesn't seem to be happening. I think it is stuck in a spiral of non-adoption, where there's no incentive for anyone to make progress. I believe short-lived certs (7 days) are more deployable in the ecosystem today than ocsp must-staple, with similar security properties. Certificate automation is already desirable, and it's not as big a leap once flows are automated.
This isn't going to happen overnight at least. Years, probably many. But it's happening.
I think you're right about CRLSets. IMO, Mozilla really wanted to solve the problem, whereas Chrome just wanted to have a solution that they could use for emergency revocation of certificates of high-profile sites (and intermediates/roots). Small-time sites won't be in CRLSets, although if you know the right people and make enough noise you may be added to their list. As for Apple, no one knows what's going on because they don't like to share :)
OCSP must-staple doesn't require code changes. It's a "flag" you set on a certificate. Maybe what you mean is that OCSP stapling is not enabled by default on many installations, and that's true. IIS got it right, and Caddy (obviously, the only platform that got everything right).
Again, we're in this place only because browsers don't care about revocation. If they pushed for it, things would fall into place very quickly. But they're going in the opposite direction.
Short-lived certificates are great, assuming you're fine with a 3.5 day (on average) window of opportunity for exploitation. There's a potentially major problem with clock skew, as many clients have inaccurate clocks. Personally, I recommend that certificates are obtained at least a week before they're deployed; a month would be better. Then rotated a month before they expire. That's how you minimise the problems due to clock skew.
Exactly. Because you currently don't check for revocation, you may end up selecting a path that's a dead end and you won't be able to recover. However, if your implementation has pluggable [dynamic] constraints, once you add support for revocation, it will work optimally.
You can run into the same problem with any other constraint, for example hash function deprecation, CA block, and so on.
Aside: Revocation works just fine, it's just that browsers decided not to implement it.
I don't think pluggability is the important thing here: a good path building implementation doesn't need to be pluggable to handle dynamic constraints correctly. More precisely: a "dead path" is only a problem if it somehow excludes otherwise present valid paths, which is not an issue if you chose to not support CRLs at all (you might accept revoked paths, but you certainly won't exclude non-revoked ones).
One of the problems with X.509 PKIs is that you can make them fractally complex; every implementation ends up setting its own "I give up, doing this is too painful" point. CRLs are a common "give up" point, and that probably won't change until CRLite or similar changes things here.
(AIA chasing and OCSP lookups are also similar pain points.)
Well, yes. If you choose to ignore revocation entirely, you will never have a dead path because of it. That will happen only if you path-build, then check revocation as two steps. (IIRC, Windows used to do this, or is still doing it.)
IMO, a good path building implementation has to support revocation, but that's for another conversation :)
I am not convinced that it's greed. See my longer reply https://news.ycombinator.com/item?id=38882694. We tried our best and wasted a lot of effort in an attempt to do what's right, and still failed in the end. I appreciate that we're an outlier and a tiny speck in the publishing world.
It seems like your problems were with amazon and the costs of printing, not the costs of including ebooks with a purchase. It may be that paperback sales aren't always profitable, and it's certainly true that amazon is ripping off sellers, but since offering the ebook download doesn't add much cost (especially for a major publisher) and even you are able to do it (on demand at least) it seems viable which brings us back to the major publishers simply chasing greater profits. For for small company, that kind of penny pinching may be totally understandable.
I do appreciate the approach you took with your books! If the big guys tried half as hard as you did we'd all be better off.
Yes, it's essentially Amazon. But what can we (or anyone) do about it?
Not sure what the situation is today but, early on, we had to give up 70% of the list price if we wanted Amazon to sell our digital books. It's just mind-boggling.
And that's on top of the suboptimal user experience, because you can't sell a PDF via Amazon, and the Kindle toolchain is just awful. We have our publishing pipeline automated (DocBook to print-PDF, on-screen PDF, and EPUB); for a while we had bad Kindle/Mobi as well, but I don't think even that is possible today.
So, it's not only that Amazon gets a huge chunk of the money, you also have to accept the inferior quality of that particular distribution channel.
You sold it, but continued to control it and pay for it, and then also made it free? How does that work? What did you sell exactly?
Only asking because others may be as confused as I am :)