ivanr

That’s so depressing.

Do you know what's behind the performance degradation of OpenSSL 3.0? Has the problem been documented anywhere?

Take a look instead at the DNS SVCB and HTTPS resource records, which have already been adopted in practice:

- Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...

CAs don't have to report their certificates to CT logs, and actually there is no reporting in a variety of use cases. However, modern browsers no longer trust certificates for which there is no (cryptographic) evidence of logging to CT.

The net result is that CT gives us visibility into all web certificates (and more).

Would you mind sharing the details of the consultant? My email is "ivan.ristic" at gmail. Much appreciated.

We haven't yet gone through any audits [we're small/young], but we've began to prepare for SOC2. The policy itself is absolutely insufficient for anything of the sort and we expect that we will generate a ton of further documentation. After all, SOC2 is essentially all about documenting your processes in detail.

The struggle between security and usability is very real. Personally, I don't think that it's possible to lock dev equipment whilst not significantly impacting productivity. That said, ensuring that high-value environments (e.g., production networks) can't be accessed from dev equipment with elevated privileges, well that's necessary. And I feel often neglected in small companies.

When I needed a security policy for my startup, I looked everywhere and couldn't find anything that made sense. I only found policies that are very, very, verbose, so much that I didn't know what to do with them. And most often outdated. In the end, we wrote our own, focusing on producing something that's comprehensive yet concise. (After all, if it's not concise, no one is going to be able to understand it.)

We're planning to make another round of changes and publish it under a permissive licence. Here it is in case it's useful to someone: https://www.hardenize.com/about/security_policy

A good security policy is very important early on to inform architecture and design. Ours has worked very well for us. It also often helped us get away from having to complete customer security questionnaires.

I imagine that's the limit per client IP address [for a single server port], no? The Linux kernel can use multiple pieces of information to track connections: client IP address, client port, server IP address, server port.

Cloudflare has some interesting blog posts on this topic:

- https://blog.cloudflare.com/how-we-built-spectrum/

- https://blog.cloudflare.com/how-to-stop-running-out-of-ephem...

Hardenize's paid plan is intended for larger businesses, where we combine infrastructure discovery with continuous monitoring and many other things. However, ad-hoc assessments are free for everyone and we intend to keep it that way. I hope that we will in time be able to provide plans at lower price points and maybe a free plan at some point.

(Hardenize founder, previously also SSL Labs founder.)

SSLPing was a tool that was designed to test SSL/TLS/PKI server configuration. According to the author's message, it was built on top of OpenSSL. There have been significant changes made to OpenSSL since 2016, many focused on improving security by removing very old cryptographic primitives that are obsolete and insecure. Think RC4, 3DES, SHA1, and so on. If you're relying on OpenSSL to detect presence of such primitives on a server, upgrading your own (client) OpenSSL version breaks the functionality.

This is a problem for all testing tools that rely on OpenSSL. If you follow this direction, you typically need to use at least two OpenSSL versions, one new to test modern features and one very old to test obsolete features.

Here's a very good guide from GOV UK: https://www.gov.uk/guidance/keeping-your-domain-name-secure

It's written for domains under gov.uk, but, ignoring that, the rest is universal and thorough.

DocBook has served me very well. For my books I put together an automated publishing workflow that starts with DocBook and produces output for both print and digital (in my case, PDF, EPUB, and HTML). For context, I wrote and published two books (4 editions) with more than a 1,000 pages combined. My goal was always continuous writing and publishing where everything is fully automated.

Conceptually, XML is an excellent choice for this sort of thing. If you want to produce a good quality book, you need many features and markup that can support them. For a technically minded person, being able to programmatically inspect and modify the manuscript is awesome.

Unfortunately, the tooling, although very capable and very well documented (via Bob's free book http://www.sagehill.net/docbookxsl/), is very difficult to use unless you're an XML expert already. XSLT really isn't a good choice for this sort of thing. That's what I had to use because CSS-styling wasn't mature enough. These days I'd start with CSS instead of XSLT.

Crucially, I would use a commercial FO processor. I spent a lot of time with Apache FOP and, even though it's a great tool, it lacked a number of features that one needed for a professional use. (It may have improved by now, my experience is from a decade ago.) I eventually purchased a licence for Antenna Formatter, https://www.antennahouse.com/, which has saved me so much time.

You're not meant to write XML by hand, but there aren't that many great editors out there. I use OxygenXML, which is all right. It's expensive. The best thing about OxygenXML is that it supports change tracking. My copyeditor also uses OxygenXML and we have a great workflow that would be impossible to implement in any other way. For me this is the killer feature. A good copyeditor will make thousands of edits to your manuscript. Having an easy way to handle those, respond, and communicate... is key.

There are some other interesting tools out there, for example DocBook Compare, which we use to show exactly what changed between two editions. I have some screenshots of what that looks like in this blog post: https://blog.ivanristic.com/2022/02/bulletproof-tls-and-pki-...

To sum up: Do use DocBook. Use OxygenXML to write your books and collaborate with your coauthors and editors. Use Antenna Formatter and CSS for styling. It's going to cost you about $2,000 in software licences, but it's worth it and it will pay back loads in time saved. I understand that no one will spend this much money for a hobby, but for any sort of professional activity, it's a no-brainer.

Personally I'd go with a third-party service that will manage the PKI side of things, possibly two. That would relieve you of a big burden, leaving you to only invoke their APIs as needed. Most big CAs have specific IoT products.

On the do-it-yourself side, take a look at Google's Certificate Authority Service https://cloud.google.com/certificate-authority-service and the AWS Certificate Manager Private Certificate Authority https://aws.amazon.com/certificate-manager/private-certifica...

Another choice is EJBCA, and here's their documentation for the IoT use case: https://doc.primekey.com/ejbca/solution-areas/iot-and-device... EJBCA is open source, but at least some of the IoT features (specifically those that deal with device enrolment) are enterprise-only.

If you don't want to do mutual authentication then may not need to do anything special. In theory, your servers can get a regular certificate from a public CA. You would get better security with a private CA, ensuring that your devices submit data only to you and not to an impersonator.

Without mutual authentication you won't be able to authenticate the devices themselves. Perhaps you intend to have a different mechanism, perhaps sign the messages? I feel that signing the messages would provide better security guarantees as the signatures will accompany the data.

I think the most important aspect to get right is to have the ability to update the root material. No matter what CAs you end up using, their roots will eventually expire and will need to be replaced. Clearly, you don't want to lose the root material as that would be catastrophic. Using two separately managed roots would probably be a good idea.

AWS and Google have private CA services, and EJBCA is also worth exploring, for example: https://doc.primekey.com/ejbca/solution-areas/iot-and-device...

There isn't a section in the book that covers IoT specifically. Most of the book is relevant to the topic because it provides a generic foundation that's necessary for more specific use cases.

I feel that in many situations the solution for IoT PKI is to find a good vendor who will support you, and there's plenty of those around to choose from.

If you have a moment, I would appreciate if you could share some more specific questions, and perhaps your use cases. That will help me understand if it's something I can cover in a future update. That said, the book is already quite big at 500 pages.

That, too, would be most welcome :)

I think TLS 4 would have been a good choice, given the massive changes made to the protocol. Fun fact: internally, the protocol version still follows the original SSL numbering scheme. TLS 1.3 is actually SSL 3.4 :)

Agreed. Many modern systems need only TLS 1.3 and nothing older. Unfortunately, TLS 1.3 is saddled with the baggage of backward compatibility. This is not something you might care if you're deploying it, but if you're studying how things work, it's still necessary to understand TLS 1.2 and earlier protocols. There are many places where, in the TLS 1.3 chapter, I had to say something along the lines "this design decision ties to this TLS 1.2 behaviour or problem".

Well, ECH (Encrypted ClientHello) got... complicated and it's still in development.

For context: one of the long-standing problems with TLS was and still is the fact that it leaks a lot of metadata. You could say that it's a chicken and egg problem. To encrypt anything you first need to agree on the parameters, which happens during the handshake. TLS 1.3 improved things a lot by encrypting all server handshake traffic that can be encrypted, but a lot of metadata remained in plaintext. That information can be used for client fingerprinting, for example.

Among other things, website name is transported in the clear, in the Server Name Indication (SNI) extension. This is a problem if you want to access a particular website but don't want, say, the authorities to know.

This problem was discussed during the development of TLS 1.3, but didn't make the cut. However, development continued afterwards, with the first attempt being Encrypted SNI. That work eventually evolved into ECH. More powerful, but also more complicated. The basic idea behind both ESNI and ECH is that websites can announce public keys for clients to use to encrypt data even on the first flight. As the name says, ECH is designed to encrypt the entire ClientHello (the first message in a TLS handshake.) ESNI relies on a custom DNS TXT record, but ECH uses the new SVCB DNS RR https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https... (which is interesting for a couple of other features, for example to use as an indication that a website is HTTPS-only).

Cloudflare have been working on ESNI and ECH. Here's one good blog post where they go into detail about how it all works: https://blog.cloudflare.com/handshake-encryption-endgame-an-...

Do you mean the text in the "What's In The Book" section? I adapted that bit from the preface and it was actually written late last year. I'll look into rewording it to read better. Thanks!

I spent a lot of time thinking about that, but, in the end, I don't think anyone could justify the words "bulletproof" and "ssl" next to each other. So that was that. The "SSL" part was in the title chiefly because, colloquially, that's what everyone uses, especially for certificates.

On a positive note, I was able to add "PKI" to the title, which makes sense because the book is actually about PKI as much as it is about TLS. A win-win, I think.

While we're here, please feel free to ask me anything, either about SSL/TLS and PKI or about the publishing process. I'll be around to answer your questions. Thanks.

Are your AAAA records misconfigured?

  $ dig +short antonok.com aaaa @phoenix.ns.cloudflare.com
  fe80::216:3eff:fea9:4e8f

My first question would be: do you really want to self-host? Google have a service that's affordable: https://cloud.google.com/certificate-authority-service AWS has a similar service but, the last time I checked, it wasn't as cheap [because of their minimum monthly cost].

If you really want to self-host, consider the open source step-ca https://smallstep.com/certificates/ If you want to do everything yourself and learn a fair amount about PKI, I provide step by step instructions in my (free) OpenSSL Cookbook: https://www.feistyduck.com/books/openssl-cookbook/

It's difficult to do it right and self-host :)

There's already a system in place to record most public certificates in a way that facilitates monitoring and auditing. It's called Certificate Transparency (CT); you'll find more about it at https://certificate.transparency.dev Google designed it and made it a requirement for certificates to be considered trusted in Chrome. It's since been adopted by Apple and Microsoft.

The basic idea is that participating CAs must publish all certificate information to multiple CT logs. For every issuance they thus receive several proofs of logging [SCTs, one for each CT log they submit to). They then embed those proofs in the actual certificates, enabling browsers to distinguish published certificates from those that haven't been. If you'd like to see the SCTs, go to this page https://www.hardenize.com/report/hardenize.com/1643337370#ww... and open up more certificate information by clicking on "View details". The SCTs are under the "Certificate Transparency" heading.

If you're talking about your own personal web sites, I don't think misissuance is something you need to worry about; someone will need a reason to go after you. For large organisations with large infrastructures, it's another story.

There are free services out there that will send you a notification whenever a new certificate is issued for one of your properties. IIRC, Facebook used to operate one and so does Cloudflare. I haven't tried them myself. It's fun when you get the first couple of notifications but quickly becomes noise. The real challenge is being able to filter out the regular issuance and highlight the unusual ones.

Disclosure: I am the founder of Hardenize, which helps companies handle their certificate infrastructure and we offer CT monitoring as part of our product. We provide free configuration assessments to everyone and without registration from our homepage https://www.hardenize.com

Postmark have a free service: https://dmarc.postmarkapp.com It's simple, but works well for what it is. They added a separate commercial service fairly recently.

When multiple CSRs [and thus multiple private keys] are involved you end up with multiple wildcard certificates. There is no sharing, technically speaking, but obviously the hostnames in all the wildcards are the same. However, that doesn't really buy you much in terms of security as any one of those wildcards can be used in an active network attack against any matching service if compromised.

That is, unless you're using some sort of public key pinning, but that's very rare to find today and works only in a custom application or something that supports DNSSEC/DANE.

> By the way, EasyRSA still isn't that easy, but it's better than using OpenSSL directly.

The trouble with EasyRSA (and similar tools) is that they make decisions for you and restrict what's possible and how. For example, I would always use name constraints with private roots, for extra security. But you're right about OpenSSL; to use it directly requires a significant time investment to understand enough about PKI.

I tried to address this problem with documentation and templates. Here's a step by step guide for creating a private CA using OpenSSL, including intermediate certificates (enabling the root to be kept offline), revocation, and so on: https://www.feistyduck.com/library/openssl-cookbook/online/c... Every aspect is configurable, and here are the configuration templates: https://github.com/ivanr/bulletproof-tls/tree/master/private...

Doing something like this by hand is a fantastic way to learn more about PKI. I know I enjoyed it very much. It's much easier to handle because you're not starting from scratch.

Others in this thread have mentioned SmallStep's STEP-CA, which comes with ACME support: https://smallstep.com/docs/step-ca/getting-started That's definitely worth considering as well.

EDIT The last time I checked, Google's CA-as-a-service was quite affordable https://cloud.google.com/certificate-authority-service AWS has one too, but there's a high minimum monthly fee. Personally, if the budget allows for it, I would go with multiple roots from both AWS and GCP for redundancy.

There are some nuances to Certificate Transparency (CT) that are worth highlighting:

- Technically, certificates are not required to be recorded in CT logs. If not submitted, they're still perfectly valid, but they won't be accepted by clients who insist on CT (e.g., most browsers). They will work perfectly well in all other situations.

- At the point of use, certificates must be accompanied by proofs of submission to several CT logs. These proofs are better known as Signed Certificate Timestamps, or SCTs. SCTs are _promises_ by CT logs to publish, but there is no way to know if the certificates actually had been published. You have to trust the CT logs. This is largely where we're currently with CT.

The main improvement is that a certificate must now be endorsed by min. 3 parties for it to work in a browser (CA + 2 CT log operators at present; 2 parties if a CA also operates one of the logs). At this time, Google must operate one of the CT logs [for the certificate to work in Chrome].

The missing piece (currently in progress) is SCT auditing, where a portion of observed SCTs are continuously checked for presence in CT logs. I wrote a little about it here: https://www.hardenize.com/blog/certificate-transparency-sct-...