ivanr

April Dunford has two great books. Positioning comes first, then sales.

As a small outfit, you probably don't want to actually sell. The approach that worked for me was to focus on inbound marketing and let customers self-select and come to you. Have a great pitch, ideally right there on your web site. Then get them onto a trial, treat them as customer from day one and get them into your customer success programme.

In essence: build a great product, talk about it, find the right customers and couple with fanatical customer success.

Also, choose a problem for which there is a good audience: https://longform.asmartbear.com/problem/

There is also the third option, when you start off as a partner of a larger business, and it goes well, and they eventually decide that they want to buy you.

It's one of those things... what works for you may not work for other people. For someone who's made-up differently, the right chair can make all the difference in the world.

I do what you do (and more) _and_ I have the best chair _and_ I am still in constant pain.

> 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 :)

Here's another one:

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

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.

I built something similar, perhaps you can use it for further inspiration: https://www.hardenize.com/report/d53.co/1708030537#domain_dn...

It's indeed a fun little project :)

I liked Founding Sales a lot, and, re-reading one chapter today, I still do. In what way do you see it as outdated?

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.

https://www.feistyduck.com/books/openssl-cookbook/

You may also want to look at https://github.com/digicert/pkilint

There are other similar tools (cablint, x509lint, zlint), but there's been a lot of good talk about pkilint recently.

Indeed, you're right. Must-staple and short-lived certificates have the same problem with clock skew.

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.

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.

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.

For reference: https://github.com/chromium/chromium/tree/main/net/data/ssl

It's been a long time since I looked at them, not sure what's in there exactly any more. Ask Ryan perhaps :)

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?

Agreed. I don't see NIST's test suites [1] on the list, though. Maybe they're embedded somewhere and I've missed it?

[1] https://csrc.nist.gov/projects/pki-testing

EDIT If the authors are reading, are any of the test cases taken from Chrome's codebase?

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].

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.

Genuine question: does the `webpki` crate provide a good path building implementation?

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 :)

Any chance you could expand on "In practice, they're both operationally complicated and an unreliable source of truth about certificate validity."?

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.

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.

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.

You're right. I answered in the context of technical books, where you do tend to get a free ebook if you buy the paperback directly from the publisher. Since that response, I checked a few of the other publishers and it's correct.

But, re-reading the top question now, I see that it's not specifically about technical literature.

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.

As a book author and publisher, I don't mind if you do. I would give you the ebook for free if I could [cost-effectively].

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.

You'll find that, often, if not always, if you buy directly from a publisher, the ebook will be free with the paperback purchase. (Manning is one example, not sure about others off hand.) However, if someone is buying your book from Amazon, the paperback is one SKU and the ebook is another, and there's no easy to way to include the book away for free. So I think that's basically your answer.

For some context, after publishing my first book with O'Reilly, I decided to start a small publishing business in an effort to capture more revenue as well as experiment with continuous publishing (you buy one edition, I keep it up to date for a couple of years). I've written three books, with the last (Bulletproof TLS and PKI) being the best and the only one still relevant.

When we first started, we offered paperback and ebook options, with ebook free with paperback purchase. We had 3 virtual warehouses in the US, UK, and Europe. It was fun for a while, but we lost money on every paperback sale as we couldn't compete with Amazon on shipping costs (plus additional overhead of dealing with shipping problems). You have to pay your printer, shipping costs to the warehouses, order fulfilment, and shipping costs. Then insurance when something goes wrong, even if it's not our fault.

At some point we stopped selling paperback books, but we continued to offer free ebooks with a proof of purchase. This, too, ended up being a money-losing venture, because we make little money on each book, with most of the money going to the printer (print on demand is great, but expensive, and Amazon takes 40% of the list price.)

Today, we sell ebooks on our web site, and paperbacks via Amazon. We're nice people so we may give you a free ebook if you ask, but that's not a good way to run a business. It's fortunate, then, that we're not in it for the money.

To sum up it up: Amazon is the dominant sales channel. If they offered paperback and ebook distribution (Kindle, pub, and PDF—mandatory if you care about the user experience), we'd happily sell only through them and give everyone a free ebook with paperback purchase. We'd give Amazon the standard 40% (the minimum for paperbacks, not sure that it is for ebooks these days).

I've been buying lots of cryptography books lately as I wanted to learn about the evolution of our understanding of this topic.

How about some of the following:

- "Real-World Cryptography" is my recommendation for the first book to read, but probably won't work for your friend as it doesn't cover any algorithms in detail. It's a great topic to cover a lot of ground quickly to gain a good understanding of how cryptography is used in practice.

- "Introduction to Modern Cryptography" is used as a textbook on many universities and I recommend it for someone who doesn't mind diving in into the maths. Being a textbook, it's fairly academic.

- "The Code Book: The Secret History of Codes and Code-breaking" covers the history.

- For TLS and PKI, read "Bulletproof TLS and PKI" (disclaimer: I wrote it). It's a good book to understand practical protocol engineering in the context of the evolution of TLS from 1995 until now.

Edits:

- The manga book is very nice and fun, but high level and dated.

- Crypto by Steven Levy also recommended.

- Serious Cryptography is good, but Real-World Cryptography is more recent and provides a better foundation.

- Cryptography Engineering / Practical Cryptography / Applied Cryptography are often recommended, but they're very dated at this point.

- Your friend might enjoy https://cryptopals.com/