Giving a damn is the reason Anchor is now a complete certificate management solution for both public and internal certificates. And it’s why we have a new co-founder.

Why Actually Giving a Damn Matters in Software

A publication from the team at Anchor — https://anchor.dev

Anchor Blog

Anchor Gradient Banner

Lcl.host for Teams

We’re excited to introduce lcl.host for Teams, the ultimate solution for setting up HTTPS in local environments seamlessly across your entire GitHub organization. Starting today, your team can effortlessly create secure browsing contexts in development, mimicking production conditions with just a few simple commands. With lcl.host for Teams, this is now a reality.

lcl.host for Teams

We’re excited to introduce lcl.host for Teams, the ultimate solution for setting up HTTPS in local environments seamlessly across your entire GitHub organization.

Introducing Lcl.host for Teams

Steps to build a CLI based on our work at Anchor

Developing CLIs

Building CLI features often boils down to:

- Release new API endpoint(s).
- Build new CLI actions that need the API changes.
- Realize mistakes were made in the API you just released.
- Try to fix the API for this feature without creating more problems in the future.
- Try to remember what you were trying to achieve in the CLI and then actually achieve it.  
- GOTO: realize mistakes were made.

Each step requires the one before and oops we've reinvented waterfall project management. You get worn down by the pain trying to gracefully pave over mistakes until you limp to functional, but bow out well before exceptional. And don’t get me started on maintaining the resulting cluster of ad-hoc “fixes” and warts.

Been there, done that. We knew we needed to move past the waterfall-ish approach.

Here is the story of how we got there and some of the tools that helped along the way.


How Anchor developed a CLI and the tools that helped along the way.

Sonny Sangha

In a recent tutorial, popular developer and YouTuber Sonny Sangha demonstrated how to integrate secure payment methods like Google Pay and Apple Pay using Stripe’s embeddable UI components within a Next.js application. He highlighted the crucial role of running a local development server over HTTPS, which can be challenging to set up. Thankfully, lcl.host simplifies this process. Here’s why you should consider using lcl.host for your local development needs:

A Beginner’s Journey: Testing Apple Pay and Google Pay in Next.js with lcl.host

Streamline Your Development Workflow with Easy HTTPS Configuration

windows+lcl.host

Lcl.Host + Windows

Today we are happy to announce that lcl.host officially supports Windows!

Lcl.host + Windows

Lcl.host + Windows = ❤️

Generate New tokens

NextJS x Lclhost

Next.js has a nifty HTTPS feature, which is nice for quickly testing an app on your local machine. However, its reliance on mkcert prevents its usage with Docker or multiple applications. 

lcl.host is a complete solution for HTTPS-enabled development environments. It handles automatic certificate renewal and works transparently with several setups, including Docker, multiple local applications, and all Next.js commands.

HTTPS on Localhost with Next.js

Setup local HTTPS for Next.js in development with lcl.host.

Architecture

Package Creation V1

Package Download V1

Package Creation V2

Package Download V2

"go test" Process Hierarchy

Anchor + Fastly

Deploying business logic in Wasm VMs with Fastly Compute 

Pushing SaaS to the Edge

Building a smart caching layer with Wasm VMs on Fastly Compute

An image representing the distribution problem with internal CAs 

The Distribution Problem

At Anchor, we see certificate provisioning as table-stakes for any certificate management product, and we’re obsessive about solving these distribution problems. We want to change how developers think about internal CAs.

 What's wrong with internal CAs (and what to do about it)

insecure mixed content allowed

secure mixed content blocked

devtool console

mixed-content-banner

Use lcl.host in local development to prevent "Mixed Content" errors in production.

Squashing Mixed Content in Development with lcl.host

squashing mixed content in development with lcl.host

Use lcl.host in local development to prevent "Mixed Content" errors in production

Lcl.host - The fastest and easiest way to get HTTPS in your local dev environment - completely free

Introducing lcl.host

The fastest & easiest way to get HTTPS in your local development environment.

Introducing lcl host

New service, service name, and client screenshot

Service Setup

Anchor Setup2

Pong!

Pong2

Anchor makes it quick and easy to add TLS encryption between internal services.

Service to Service TLS

In this article we’ll cover setting up TLS between a Ruby on Rails client application and a RESTful Go API application. At the end, the apps will communicate via encrypted HTTPS instead of unencrypted HTTP requests. All entirely within our local development environment.

Service to Service TLS in Development

See how easy it is to secure services with internal TLS using Anchor.

Anchor Get Started 1

Anchor Get Started 2

Getting Started First

Anchor not secure demo

Anchor Rails Demo Secure

Manually setting up HTTPS/TLS on your local machine is really painful. Anchor is here to make this process quick and easy. In this post, I’ll show you how to quickly set up TLS certificates for a local application and get it working with HTTPS in your browser.

Getting Started with Anchor for Local Development

Quickly set up TLS certificates for a local application and get it working with HTTPS in your browser.

Anchor Blast Radius

[![Crypto Tweet](//images.ctfassets.net/znm673hrtlkd/7EYo5abUIrrhrrCkknfJd1/c7c7efd51aa7e8c6de924a53feeee96b/Screenshot_2023-12-04_at_23.31.35.png)](https://twitter.com/LeaKissner/status/1198595109756887040?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1198595109756887040%7Ctwgr%5Efa39e5aa73c3f6df5e9a01d672736fd5d021edc8%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Dd04bfffea46d4aeda930ec88cc64b87cschema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fleakissner%2Fstatus%2F1198595109756887040image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3D4fce0568f2ce49e8b54624ef71a8a5bd)

Experienced security practitioners know that key management is fraught with risk. And systems that build on secure key management, like internal TLS deployments, inherit these risks of key compromise and exploitation. By designing systems with “blast radius” in mind, it is possible to contain these risks. Fortunately, internal certificate authorities have some unique but little-known properties available for shaping the “blast radius” to reduce operational risk.

## Key Management
Key management is hard because it requires both strong technical design and operational expertise, and also carries high risk. These two characteristics (complexity & hazard) together make these systems expensive to operate. For cloud providers, the margins on key management services are enviable, but the value capture is easily justified given the costs & risks of handling key management in-house. And competition between cloud providers and others in the market is driving costs down.

Systems that build on secure key management, like internal TLS deployments, are cheaper today because of the shift to the cloud, but still carry similar levels of risk. Root key exposure is catastrophic. And lateral movement is assumed. __In today’s operating environment, the risks of compromise & exposure are much greater than the operational cost for internal TLS deployments.__ Addressing and reducing the risk in these systems is a more effective way to further reduce their cost.

## Blast Radius
The AWS team has popularized the term “blast radius” as the consideration of impact on a larger system due a failure of a smaller portion of the system. [Embracing failure helps the AWS team deliver industry-leading availability and operational excellence](https://www.youtube.com/watch?v=swQbA4zub20). These same principles work just as well when designing secure systems with failure as a forethought. In the security case, this upfront consideration makes it possible to quantify and reduce risk.

In recent years, there has been a push for cryptographers to design protocols with key compromise as an inevitability. [The Signal Protocol](https://en.wikipedia.org/wiki/Signal_Protocol "Signal Protocol") is one of the most well-known protocols designed for cryptographic resilience. It introduced the novel [Double Ratchet Algorithm](https://signal.org/docs/specifications/doubleratchet/ "Double Ratchet Algorithm"), which provides recovery from key compromise and forward secrecy. This limits the blast radius of device compromise for Signal users to a portion of their messages instead of their full history, past and present.

## WebPKI and Public CAs
In the world of WebPKI and certificate authorities, the [Certificate Transparency](https://certificate.transparency.dev/ "Certificate transparency") (CT) protocol was conceived in an effort to minimize the blast radius of Certificate Authority (CA) compromise. When a CA exposes a signing key, the key can be used to issue publicly trusted end-entity certificates until the corresponding CA certificate is revoked or removed by the root store operators. Likewise, if a CA is fooled into mis-issuing a certificate, the bogus certificate can be used for impersonation until it is detected and revoked. But detecting improperly issued certificates is a difficult problem, since there is no central service involved when setting up TLS connections.

Certificate Transparency was created with the goal of improving detection of compromised or misbehaving certificate authorities. CAs publish an append-only audit log of all certificates issued by the CA, and these logs are monitored for suspicious certificates. When a certificate authority is fooled into forging a certificate, the certificate will show up in a CT log where it can be detected and quickly revoked. Vice versa, if a browser is presented with a certificate that does not have a corresponding entry in the issuer’s CT log, this is a strong indication that the issuing CA has been compromised. To date, Certificate Transparency has been very effective at scoping the blast radius of CA compromise and certificate mis-issuance.

## Internal CAs
However, behind the firewall, Certificate Transparency isn’t so helpful at detecting CA compromise and certificate mis-issuance. Because internal CAs are typically used by a single organization, other organizations have no incentive (or even ability) to monitor their internal CT logs and certificates used internally by an organization. Compared to regular ways to audit an internal CA, CT logs do not offer anything extra to scope blast radius. However, there are some parts of X.509 & [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280 "RFC 5280") not available to public CAs, that can be used to scope blast radius for internal TLS deployments.
## Name Constraints
[Section 4.2.1.10 of RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10 "RFC 5280") defines the name constraints extension for CA certificates. These name constraints allow a CA certificate to encode the set of FQDNs DNS names and CIDR address ranges that are permitted (or excluded). It’s a bit like the [pledge syscall in OpenBSD](https://man.openbsd.org/pledge.2#DESCRIPTION "Open BSD"): the CA certificate self-selects the namespace for all certificates it issues.

If an end entity certificate contains a common name or Subject Alternative Name that does not match one of the issuer’s (or issuer’s issuer, and so on) name constraints, clients will reject the certificate when attempting to validate it. [Here is the relevant C code in OpenSSL](https://github.com/openssl/openssl/blob/ac0677bd2394c04632f7ad526879a866b6ed149f/crypto/x509/x509_vfy.c#L791-L825 "C code in OpenSSL").

For example, we have a root certificate with a permitted name constraint of 
`.mycorp.it`, and two subordinate certificates with the respective name constraints for the staging `.stg.mycorp.it` and production `.prd.mycorp.it` environments. If the staging CA were compromised, the attacker could issue certificates for both the staging `mysrv.stg.mycorp.it` and production `mysrv.prd.mycorp.it` environments, but only the staging certificate would be valid since the production dns name would not match the staging CA’s name constraint. __Name constraints used in this way will scope the blast radius of key material compromise to a single environment.__

Name constraints can also eliminate man-in-the-middle certificate attack surface area. In the previous example, if the root certificate had no name constraint and the signing key were compromised, the attacker could issue a certificate for any domain name–even “gmail.com” or “packages.ubuntu.com”. Any internal systems that trusted the root certificate would in turn trust bogus certificates presented by the attacker. But with the name constraint in place, the attacker could only impersonate subdomains under the internal company domain `*.mycorp.it`.

## Path Length Constraint
[RFC 5280 also defines a path length field](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9 "RFC 5280 defines a path length field") (`pathLenConstraint`) as part of the basic constraints. Path length is an optional unsigned integer that indicates the number of CA certificates allowed in the certificate chain. For example, a path length of zero only allows end-entity certificates to be issued, while a path length of one would allow one more level of subordinate CAs.

The path length constraint can be used to reduce the risk of certificate mis-issuance by a CA certificate. For example, an attacker that manages to fool the CA into issuing a bogus certificate, but is otherwise unable to access the signing key of the CA. If the attacker is able to obtain a CA certificate (with the `cA` field set), it can in turn issue bogus certificates without needing to fool the CA again for each new certificate. This is effectively the same as compromising the CA’s key material. But a CA with a path length constraint of zero will neutralize these bogus subordinate CA certificates because no client will validate the bogus subordinate (even if its `cA` field is set).

## Anchor
At Anchor, we build and operate internal TLS deployments on behalf of our customers. All CA certificates we issue (both root & subordinate) always include name constraints and path length basic constraints. This reduces our customer’s risk to key exposure and certificate mis-issuance, and allows them to scope the blast radius of incidents to individual environments.

You can [sign up for free](https://anchor.dev/) and start using Anchor in your local development environment today. And for staging and production environments, [please reach out to join our early access program](https://mailto:contact@anchor.dev). For more details about what we’re building at Anchor, [stay tuned to our blog](https://blog.anchor.dev/) and join our [discord community](https://anchor.dev/discord).

Experienced security practitioners know that key management is fraught with risk. And systems that build on secure key management, like internal TLS deployments, inherit these risks of key compromise and exploitation. By designing systems with “blast radius” in mind, it is possible to contain these risks. Fortunately, internal certificate authorities have some unique but little-known properties available for shaping the “blast radius” to reduce operational risk.

Blast Radius & Certificate Constraints

Introducing Anchor 3

As of today, Anchor is live with features for local development. Adding TLS/HTTPS to your development process has never been easier or faster. It takes just a few keystrokes to enable your Ruby, JavaScript, Go, and Python apps. No need to deal with DNS, complicated CLI commands, or cypher suites.

Effortless Encryption: Introducting Anchor, Part 3 of 3

Add TLS/HTTPS to your development process easier and faster than ever before

Effortless Encryption: Introducing Anchor, Part 3 of 3

Anchor Intro 2

Anchor centers on the service or application being encrypted instead of on the encryption itself. By focusing on the developer and developer experience, Anchor delivers a very different product than your mental model of a CA. This is a security product built for application developers.

Beyond Baseline Requirements: Introducing Anchor, Part 2 of 3

Focusing on service or application being encrypted instead encryption itself.

Anchor- Mind the Gap

Born out of the problems that developers face building secure applications, Anchor was built and designed by a group of developers who have fought these problems for years. This three-part series will explore these problems, what ideal solutions look like, and how Anchor provides those solutions. In our first post, we share our take on the current landscape of security solutions, and why the time is ripe for something new.

The ACME Gap: Introducing Anchor, Part 1 of 3

Our take on the current landscape of security solutions, and why the time is ripe for something new.