Up next in exploring Oyster's intricacies, we're taking a look at CAA Account Binding Dive in: https://twitter.com/MarlinProtocol/status/1680701743661735938 After looking into Oyster’s networking stack (here and here), we saw how connections can be secured using protocols like TLS (here). Let’s see what it looks like in practice by serving a website from an enclave with full TLS support 👀

Up next in exploring Oyster's intricacies, we're taking a look at CAA Account Binding Dive in: https://twitter.com/MarlinProtocol/status/1680701743661735938 After looking into Oyster’s networking stack (here and here), we saw how connections can be secured using protocols like TLS (here). Let’s see what it looks like in practice by serving a website from an enclave with full TLS support 👀

✅ This binding of the ACME account within the enclave to the CAA record guarantees that the domain can only be issued certificates within the enclave and not on the host. Attempts to intercept requests are futile, ensuring tamper-proof services. 🌟

😉 Lastly, some food for thought for your security team lest you think Oyster is somehow uniquely vulnerable to this kind of interception. Remember our analogies between the untrusted host and your ISP or other internet routers? Same applies to this.

💡 Here's the magic: Caddy automatically generates an ACME account key pair within the secure enclave. We add a helper program to expose the account ID and simply add a CAA record and bind this account. Critically, the host does not have the same key pair.