Ask HN: I built a Yubikey-based domain controller. Is it sellable? | Hacker News Reader

Ask HN: I built a Yubikey-based domain controller. Is it sellable?

138 pointselevation99 comments

I once worked in R&D where our competitive advantage was in keeping our customer relationships and intellectual property private, so we kept everything on-prem. No cloud, no SaaS, no WFH.

In my own SMB, I still self-host git, CI, chat, etc. I love the privacy and control, but I also needed to open these services to remote workers without exposing them to the world. So I built an appliance to protect my internal web apps by requiring user/pass+yubikey at multiple layers of the stack: L3 (p2p vpn), L4 (mTLS), and L7 (OIDC). The appliance is self contained (VPN, LDAP, NTP, CA, OIDC), like a classic domain controller, and it keeps servers safe from any users without an authorized hardware key.

I'd love to bundle this with an admin panel and sell it, but I forsee problems connecting with the right market:

* Clients who have meaningful IT budgets will require inter-operation with their legacy domain controllers. This means I won't have an MVP without major changes and lots of testing. It also puts my own product at risk: if Microsoft doesn't want to support my integrations, they can disable my product with a software update.

* Clients who are too small to have lots of legacy IT requirements will have small budgets and require lots of support. Some of these clients will grow larger, but this is a long game. I would love to support these clients but don't want to die for lack of revenue in the short term.

How would you sell what I've built?

View on HN

Think about a company like ADT - they are selling security systems, but the people who really really need security (large clients with large IT budgets) would never buy an ADT system.

So like it or not, you're going to be going door to door and helping smaller clients integrate this into their systems.

I think the right way to approach this would be to better understand the problems your clients would face when trying to integrate this kind of system, and then figure out how to solve them at scale in a way that you make customer acquisition and onboarding easier in the future.

Maybe it's things like creating base docker images for common services or OS pairings that have your stack already integrated. Maybe it's turnkey integrations with existing cloud identity providers or SSO. Maybe it's tailscale integration.

In fact tailscale is probably a good model to look at here - no large organization with an existing VPN solution is moving to tailscale, or at least weren't when they first started. But tailscale made a hard thing easy, and that's exactly what you're doing here.

Physical security is probably a bad example, when people need physical security they end up calling installers. ADT got where they are by making their installers lives easier, and make it easier to find those installers.

I am not the market for the OP. Because I want the ability to change MFA vendors or federate, but the strategies of non-software companies is much different IMHO.

What other MFA vendor would you go with? For my own business continuity it might make sense to white-label both yubikeys and an alternative vendor, but Yubico seems to have the best product unless you're wanting to push MFA to user's phones.

It is more about vendor and technology mitigation vs selection.

Companies fail, projects degrade, like lask week quality can go down.

The better question is why would my organization couple their success to you wagon, do you provide them with a way to get their info out in a portable way?

But there are many reasons to maintain the ability of your IAM to access multiple IDPs.

I do think there is a growing market for products that don't use your private data for their own goals.

But coupling a domain controller to a single 2FA provider just doesn't have any value as you have described it, at least for me.

I am not the entire market, just one potential user, so take this as feedback and not outright dismissal.

Perhaps if you develop the idea more I may be interested in the future.

Tailscale is a good model for software businesses in general IMO, but they also have another clear advantage over some project like this: they focus on exactly one thing and do it exceptionally well. There's probably a (small) market for out-of-the-box stuff like this, but I'd imagine it has got to be pretty small.

So caveat that I am not a small business in need of any of this stuff, but I'll give you an example of the kinds of things that I have struggled with in the past where I think a solution like this could add a lot of value if extended in the right ways:

- certificate management amongst a plethora of hosts, both SSL/web certificates for external use, and management and installation of self-signed "root" certs for validating internal applications and services - keymastering server: an appliance that acts as a genuine root of trust for an organization, using a Yubico HSM for key storage, but providing middleware & admin controls to manage issuance and distribution of intermediate certificates - AD/LDAP/SSO/etc user management, key issuance, etc.

If you have a small team and you don't need global redundancy for these functions across a large fleet, then it makes a lot of sense IMO to shell out $5-10k for a set it and forget it security appliance that makes certificate/key management simple and easy.

I think the biggest challenge is that it's hard to build trust as a startup without open-sourcing your stack, but that makes it a lot harder to get buy-in for an appliance model unless you have some creative dual-licensing ideas.

But "your keys/certs are stored securely on your hardware in the room next door" is a compelling value proposition & probably a much easier pill to swallow for certain companies than a cloud HSM or other solutions which sorta boil down to "trust me bro".

Sure, so focus on being a local certificate authority using hardware backed roots. I can see that being valuable, but you'd be competing against companies like Smallstep.

> using a Yubico HSM for key storage, but providing middleware & admin controls

> a compelling value proposition

I completely agree; I'd originally drawn up a design for an offline root CA, then an box with a separate server for an intermediate CA with HSM for intermediate keys, a second, dedicated Secure NTP server (possibly hardware based) so that certificate expiration times could be kept short.

While all that is easy enough to prototype, the complexity of hardware distribution is better left to a later point in the roadmap.

I wouldn’t use the Yubico HSM, because I think it misses a feature that would IMO add considerable value: an enforced CT-style log. If I were paying for a corporate root of trust, I would want very strong auditability. Set it up so that the HSM does not release a signature until presented with an SCT. Make it impossible for buggy or compromised host software to create bad certificates without being detected.

A hardware HSM is not magic or even especially complex. Java cards can do it (slowly). Yubikeys can do it. Other vendors’ devices can do it. Lots of microcontrollers can do it as long as you don’t need resistance to complex physical attack. A startup in this space should seriously consider building its own.

Do you have a recommended vendor that could be made to support hardware signed CT type logs?

Physical security like ADT is so yucky to be honest. It violates _all_ the principles we use in IT security. The vendors are super secretive about their specifications and even basic aspects are usually impossible to figure out / considered a business secret.

Like, I was looking for an RFID entry system for a customer. Some of these are advertised as using DES/AES security (implied to be some version of DESfire). Most aren't. Try figuring out if they actually use DESfire and if the handshake is tunneled to the door controller (placed in a secure area) or the card reader (placed in the vulnerable, insecure area) has the keys and is just sending the UID to the controller. Nobody will answer this question. (Presumably because these secure systems are all actually UID-only on the backend so trivial to bypass if you learn a valid backend UID).

And even then, you're like "Okay, this sounds interesting. I wanna buy it." - "Oh, you can't. We don't sell these. You need a system integrator / installer." And then you go to one of these and it's super obvious they have essentially no clue how any of the stuff they're system-integrating works, but of course they won't give you admin access to the system they wanna install. "How do I configure this?" - "You don't. Only we do. Using a proprietary software." - "Where's the system manual for this?" - "We have it, we can't and won't give it to you."

I mean a lot of stuff works like this, usually with incompetent middle-men fucking up products which aren't all that bad (another most popular example would be HVAC and heat pumps, especially ASHPs) and manufacturers trying to make a SaaS kind of play with hardware you bought. But for security it feels especially egregious. How do you know the installer doesn't have a master key? Well, they usually do. How do you know the ACLs are set up correctly? Trust me bro. And so on.

Reminds me of a time I had a heat pump water system installed with clearly labeled warnings on the outlets that the covers needed to be removed or requirements that the fans be sheltered.

None of this was done. It was out in the sun (laminate on control panel fused to the screen), air intake was factory sealed (system failed after a while) and it was left in the rain after an installer came to remove the covers (air intake / exhaust are top facing).

I could have easily solved the issues myself but didn't want to give them the option of pinning liability on the client.

I'm not sure I understand the product. It kind of sounds like a zero trust VPN, but you're calling it a domain controller which has a different real world use case--does your product actually function as a Windows DC?

What use case + benefit would folks have using this? Why should they trust you?

I call it a "domain controller" because it keeps a directory of users and hosts, accessible via LDAP. This source of truth drives the Certificate Authority role which can cryptographically assert authn/authz and distribute those assertions to member hosts in the form of certificates, password hashes, etc. A DC may also securely distribute time to its hosts, which is important for accurately calculating the validity of a certificate.

A classic DC would authenticate windows logins and rely on an external network. My design authenticates just TLS and web-app logins (not windows) but also provides an authenticated layer 3 network. So it's hardware-attested zero trust -- something that's difficult to securely assemble out of existing SaaS.

This would be overkill for a typical call center (large scale, high churn, low trust) but perfect for a team working on sensitive IP (smaller scale, low churn, high trust.) Research and development, administrating expensive systems (regional manufacturing?) or for collaborative work on sensitive documents (legal?)

Isn't this an idp? I'm totally unclear how this is differentiated from an idp that also requires a hardware key.

It _has_ an IdP, but you have to be authenticated at a lower layer in the stack before you can talk to it.

Think Tailscale+Let's Encrypt+Okta but all in a single package.

I guess it could be categorised as a PAM (privileged access management) solution with a built-in IdP?

I was about to say this sounds like our on prem PAM setup which is integrated with our idp - or some mixture of things folks are asking about. Seems like this is something largely solved regardless of how it's being done, but maybe we're all missing something. Or maybe his implementation is just that slick.

Does your PAM include a data loss prevention feature?

Yes

But that's just certificate auth, which happens during session establishment and before data transmission isn't it? So isn't it an idp with cert auth as the primary first factor?

So for example Shibboleth with privacyIDEA and enabled webAuthn and 2FA for AnyConnect or some other VPN?

This is what I was thinking

Look into products like okta, they have similar functionality. They also sync data from AD. I'd focus on not providing the LDAP management, but instead syncing other LDAP sources in.

I wouldn't sell it for two reasons:

1. The market that needs this will not be capable to use it

2. The market that is capable to use it is also capable to use something like Cloudflare Access.

As for 'domain controller', like others have posted, that is a product or branded product from microsoft that doesn't have much to do with what you described. You could argue that Microsoft Windows Server can host most of those services, and will likely need a Microsoft Active Directory service (which in turn requires at least one Active Directory Domain Controller), it's not really related to what you are doing besides perhaps a user directory.

In a way, your product would address the classic setup that Microsoft (and Apple) have thrown away (many) years ago, companies are very bad at IT, and it gets worse as you focus on smaller companies and companies where IT is rather far removed from their core business. Something that is managed and maintained by someone else, that is where the money is, and in almost all cases that means the services and applications are not co-located in some office somewhere, mostly because the office is pretty much irrelevant these days.

> the classic setup that Microsoft (and Apple) have thrown away (many) years ago

I acknowledge this trend; Microsoft wants everyone in the cloud so their on-prem offerings, while entrenched, are stagnant. This could be an opening that lets me build a quality product for a modest customer base who are unable/unwilling to migrate.

Perhaps your 'best' competition would be more like the Synology and QNAP type of deals. Anything beyond that doesn't fit in an appliance-style product.

Keep in mind that those brands also have connectivity, filing, user directories, network services (DHCP, NTP, NTP, L2 and L3 VPNs), but in practise they suffer from the same things small businesses have for decades: lack of internal knowledge. And since such systems are never set-and-forget, they would either need physical maintenance contracts (which SMBs can't afford) or remote SaaS-style maintenance which somewhat defeats the point.

The gap between people able to buy an appliance and people who know basic routing, DNAT and subnetting is really really big these days, and that's just to get things up and running. The next step up is still bigger gap than it used to be, but also quickly gets you into too-capable-to-be-a-market territory.

Maybe a better model is the one attempted by the private computing brands, I don't know a successful one of the top of my head but they generally have a NUC-like device with Linux on it with hardware root-of-trust and they present it as a portable-but-desktop computer that comes with a more trustworthy OS and network security. Some are based on heads & tails, others on Qubes OS, others just a fork of PostmarketOS with some Graphene in the mix. The early ones all failed because they just weren't useful to the average user, but the later ones didn't fail immediately while they were news.

> The gap between people able to buy an appliance and people who know basic routing, DNAT and subnetting is really really big these days

This is a major advantage of the mesh VPN layer. If your bare metal hosts/guests hardware have internet access via plain old DHCP, they can connect to the mesh network which is where all the special networking happens at the direction of the controller. On the mesh, every node can have a persistent static IP and dns entry, simplifying the network topology for the layers above.

This is exactly why we have build defguard (https://defguard.net - https://github.com/defguard/defguard).

From what I can tell you, good security is hard - we have prepared the product exactly as you describe on various levels (vpn, identity, SSO, Yubikey provisioning, etc) and prepared the architecture to be secure (multiple segments support: intranet, DMZ, proxy for exposing only public endpoints and functionalities publicly)…

What I observe in a year of the project being public and analysing heavily the landscape, similar projects, Reddit of what users are seeking and what problems they have is that: a lot of people and companies value comfort more then security (even if they will not admit it publicly), because security is hard. That also means there is w niche and need, but… it’s really hard to build a secure, easy to use and deploy security system…

Hope you don’t give up and peruse!, as it’s worth fighting about security and privacy

This looks very nice. Comment: there's a whole industry that - whether or not they utterly despise the idea - is required to use FIPS-certified encryption. If you were somehow able to make that a component, you might be able to expand your market significantly.

You are absolutely right! We already have this on our roadmap!

> (even if they will not admit it publicly)

Saying you don't care about your user safety is actually often more costly than pretending you care, and then having a breach.

Defguard looks great, it's got a similar architecture (local first, with a vpn) and your feature list looks like my todo list!

I could see recommending this product to others!

You have a few features that surprised me, like support for "authentication with crypto software and hardware wallets". This seems like the sort of thing a business would never need. Did you have users agitate for this feature? Or is it a direction you're trying to steer clients?

Overall, nicely done, I wish I'd known about this when I started!

Those features you’ve mentioned were done for some customers/projects that deployed defguard - but web3 stack (especially wallet libraries) are so… immature and problematic that we will be most probably removing those features.

Can you share your roadmap? Ideas? Seems we share the same mindset and vision, would be great to exchange knowledge, ideas…

Cheers, Robert

I sent you an email, would love to discuss!

I think this product might be of interest to NitroKey (https://www.nitrokey.com/), a competitor to Yubikey.

Unlike YubiKey they sell a wider range of products, such as secure hardware. It seems if you make it work with NitroKey they might be able to sell it as a bundle.

Probably won't hurt to reach out to them as a potential partner

I was going to mention NitroKey. Their first generation HSM product was very nice. I haven't used the newer one but I'd have high expectations.

My company evaluated both Yubikey and Nitrokey and decided to use Yubikey. While they are both in the same price range, Yubikeys are more durable, whereas the Nitrokey plastic cover began to show cracks. Because our employees wear them on their keychains, that would be a problem, while the Yubikeys were fine.

Also, the cheap Nitrokey FIDO2 key doesn't support ED25519 for SSH keys, only RSA and ECDSA, and even though they are open source, the promised support for ED25519 is still not delivered even after 4 years, so I doubt it will ever come: https://github.com/Nitrokey/nitrokey-fido2-firmware/issues/3...

Ultimately, while I like the idea of open-source, for a company use case, we had to go with Yubikey.

> How would you sell what I've built?

It's interesting. You have built something tightly coupled ("like a classic domain controller") but then it is interacting with inspecific, totally decoupled stuff ("(p2p vpn), L4 (mTLS), and L7 (OIDC)").

"Tightly coupled for me, but not for thee" - why would someone who has adopted a decoupled application infrastructure decide that their domain controller should be coupled? I feel like people want one or the other in totality, they are either completely a Windows shop, or they are completely using bits and pieces of everything from everywhere. Everyone in between is ultimately migrating to one end or the other.

I can't speak for how to sell something I've never used. But I know Okta is very popular, and I encounter many IT people in many tech forums basically describe a feature of Okta. That's a huge scope. But that's a company that has tackled the dichotomy of coupled versus decoupled solutions, by simply providing everything. Is there a little bit of a chance that a single person can make something competitive with Okta? Yes!

> why would someone who has adopted a decoupled application infrastructure decide that their domain controller should be coupled?

You'd really only want the current appliance if you don't have the in house staff to assemble/amalgamate an equivalent setup.

My pitch would be that tight coupling enables major security benefits in the implementation:

* rapidly propagate policy updates (eliminate race conditions caused by changes slowly propagating across SaaS vendors.) * simpler modules with fewer features, less attack surface * rich context in logs (even spoofed packets have a cryptographically verified source) * coherent security controls

> something competitive with Okta

I could imagine building the product into "the Okta of on-prem".

> "the Okta of on-prem"

OK, now that sounds like a real product with a market, unlike your original post. I don't know if or how you can bootstrap to there (I assume Okta took a bunch of money so that they could blitz out to integrating with everything and didn't need to make sales when they couldn't integrate with everything - maybe building the integrations with a customer's systems as you acquire that customer?) - and I don't know how many people have non-legacy prem systems that they're willing to spend money on. But this is the pitch.

There is a market for small businesses who do not want to buy in to the Azure/O365 ecosystem but need a domain controller appliance that is easy to setup and maintain, and will offer VPN connectivity to access central resources.

It's affirming to hear of businesses with a similar disposition. I expect many will be rightly skeptical of an upstart vendor, but this just means establishing the brand for a few years will have its own dividends.

I also hope to evangelize the mentality a bit more. Making the technical approach more feasible for non tech companies could be a boon.

This is an established space, with provides like Okta, Teleport, JumpCloud, and even Microsoft Entra ID. Most of those options have fewer barriers of protection as it's simpler, which leads to better security and reliability in practice.

Your target audience is likely companies running old-school, legacy Microsoft installations. These tend to be on-prem for the reasons you list.

The problem, though, is if these companies want a VPN, they already have it. You'll have to convince them that the VPN they've been using for decades is insecure (it's not).

----

Lastly, at a technical level, I'm not entirely sure what you achieve by requiring user/pass+yubikey on multiple layers of the stack. You don't gain any additional technical protection (since L3 would wrap everything else) while still having a single point of failure.

> You don't gain any additional technical protection

There is strong value in security in layers. While VPN access requires remote users to have a hardware key, internal VMs may need a file based pre-shared key/certificate. If an attacker somehow manages to gain VPN access without a hardware key, they’d still either need a hardware key or they’d have to additionally comprise the TLS PKI be able to complete an mTLS connection to an app. Checking the hardware key on the way up the stack keeps an attacker on the VPN from having a privileged position.

But if an attacker can breach your VPN, why would they not be simultaneously breaching all other layers of the stack?

Running the same, breached check in multiple places doesn’t make anything more secure, it simply runs a vulnerable check more.

——

Layers do add to security, but the argument here is that you’re adding more doors to a bank vault while completely ignoring they all open with the same key.

Let’s say an attacker compromises a machine that was joined to the mesh network via a pre shared key file (not a hardware key). The attacker still doesn’t posses a hardware key, so the higher level checks are still valuable.

Another way to put it is, that attacker is walking a part of the vault floor, but still doesn’t have keys to the lockboxes.

What you’re describing is simply multi-factor authentication.

What I’m focused on is the repeated authentication on multiple layers of the network stack. It just isn’t necessary. Either your authentication mechanisms work at the lowest level, or they’re broken across the entire stack.

I think your analogy is flawed. You assume that any attacker that breaches a layer of defense will do so by breaking the encryption or by stealing the key, but that doesn't have to be the case.

In your analogy of the bank robbers, the robbers might exploit a weakness in an exterior wall, and gain entrance to the lobby. The other locked doors will still prevent them from robbing the vault.

Start but not claiming it's yubikey-based, and instead phrase your product in terms of what category of dependency it has. You built a product that's secured by means of a username, password, and hardware authentication code. Yubikeys are an obvious example of the kind of hardware authenticator that works with, but that's just an example. At no point is your product locked into yubikey as authenticator.

Even if it's the hardware authenticator your product currently works with.

Don't market it on current specifics; anyone not using a yubikey (personally or organisationally) will dismiss your product and never look at it again if you tie it to one specific third party vendor.

Agreed! I used a familiar brand to quickly communicate the main idea to readers here, but potential clients need to be sold on the end result:

Secure remote access to internal applications

Security is a lemon market so vendor reputation and functional results are more important for winning clients than the implementation ever was.

1. This is a reseller opportunity - teach small ISVs what is under the hood, why it’s smaller cleaner better

2. Linked to the above, this is not a competitor to Active Directory. It’s the antithesis. It’s not for a small office of PCs on desktops. It’s to properly secure IoT devices in different locations - sensors, telemetry that niche businesses sell - they sell the service that the device provides, and want a reliable small footprint security solution. Maybe you are it

Edit: I may have misunderstood the use case however - you mention zero trust but I may be missing how it validates at different layers - would love to know more however ! DM me if need be :-)

I think (2) is a misunderstanding and it'll handle something like "a small office with some PCs and some servers and some users connecting remotely" or so.

However, even if I did get that right, your point (1) is excellent.

Smaller ISVs and/or MSPs could quite possibly sell this as part of a bundle, and if you can make it require -less- support than whatever their clients had been using previously that seems like it should make it of significant interest to them.

(I definitely appreciate the 'supporting SMEs is a time suck' concerns in the original post but 'make it less of a time suck for the people already doing it' plus 'turn yourself into 2nd line support only' seems like it could be a way to turn that concern on its head viability wise)

> safe from any users without an authorized hardware key

If you do this, make sure you support multiple hardware keys.

Single Yubikey and no backup is not safe, since the key can be lost or damaged easily.

Single Yubikey and SMS backup or "contact customer service to reset" backup is NOT secure, as it reduces your security to that of SMS or the CS rep.

I'd considered allowing users to provision a additional keys for backup, but only allowing one active key at any given time.

If the active key is lost/destroyed, a self-serve portal allows them to disable their active key at any time. But activating a backup key would require a (different) administrator's approval.

That isn't a good workflow, in case the first administrator is sick or hospitalized and the second administrator needs to access it temporarily and is not in the same city.

Also, I tend to leave Yubikeys permanently plugged into devices (1 per device) and register all the devices I have (4+) with every service. If any device is lost I would just login with another device disable that key. I also don't usually travel with keys unless I'm travelling with a portable device. When I move between two fixed desktops both in secured locations, the two desktops just have permanently-installed keys, I do not carry a key between them as walking around with a key is a liability.

Thanks for this feedback. I'll make sure to support multiple active keys as well.

I want hardware attestation to be first-class, and not an afterthought. Since I'm integrating everything I can support a top-notch "lost key recovery" flow, whatever the requirements are.

Yeah I have been sim swapped and can confidently say that SMS is not a valid form of 2FA.

Interesting, building a YubiKey-based domain controller is on my list of things to do as we slowly work my way up the value chain and go after bigger projects - all on-prem and offline. The problem is we're years away from needing it, and even in the best case scenario our sales pipeline is 3-5 years.

Almost all of our software is in-house as we're very adept and efficient coders and it keeps the dependencies to a minimum, especially with regards to the licensing. We only have a single non-royalty free dependency and it's a total nightmare, the component is probably responsible for 30% of revenue but 95% of headaches.

So I'm trying to think of a hypothetical where we would buy such a product. Basically if I could have the same flexibility of making such software ourselves I would pay up to what we could expect it would cost to make it. If we were to need it it would be for a ~$1-3M USD project which we could carve off ~$100K for something like this due to the expected dev time savings which could be redirected to other areas while we scale up for the project. But for the second time round pony up bigger chunk say ~$200K to cover the cost of building it ourselves.

We were looking on standardizing on YubiKey, probably for the same reasons you went with them. Honestly I don't think my company should be your target market, we make software and are very good at it so it's a bit hard to sell us software, but if you decide to give out your contact details I'll make a note of it and keep an eye on what you choose to do.

FWIW, I would be inclined to standardise on PIV/CAC devices (i.e., smart cards), for which there are standard USB readers and drivers and protocols. You can get started with YubiKeys because they're relatively reliable, if a little expensive, and they have good support for PIV/CAC -- but if you stick to what smart cards can generically achieve you won't get shafted by only having a single supplier in the future when Yubico inevitably becomes less attractive for some reason or other.

Yup, that indeed was the plan and the rationale for that plan

Security first ISP?

Its not quite where you are now but smaller ISP's tend to have a list of bad options when it comes to user authentication. Do you want to support a large microsoft stack for AD and Radius? Do you want to manage one of the several terrible freely available radius implementations? Do you want to just let your billing system do it and hope that their proprietary code always works? Do you do something different thats completely vendor locked? The list goes on.

Meanwhile, small ISPs are a ridiculously soft target for cybercriminals. Most ISP's think they are invisible, and are exempt from hacking while the inverse is true and the inevitable outcome of that mentality results in heaps of customer data getting exposed.

It would take more market research than "Hey Hackernews" but an all in one appliance that secured userdata, applied stringent security to internal staff, authenticated wfh / field staff vpn logins via yubikey and let the ISP advertise optional secure links over their L2 connections would probably go down really well with small to medium ISP's that have only a few hundred customers, but get 80%+ of their revenue from high value business circuits.

> Security first ISP?

The modern technology stack already allows us to treat the ISP as untrustworthy. For example when I am logging into my bank's website, I don't have to worry if my ISP is snooping on that traffic.

Similarly, I don't understand when people say, don't use wifi at coffee shops. If you are depending on wifi security to provide any protection for your data, you may be doing data security wrong.

You arent wrong, just a few things.

1. In terms of the customer facing L3 product: I deleted a whole chunk of this, but the goal isnt so much to deploy this for say your average retail ISP but ISP/MSP hybrids that are offering services to SMEs like L3VPNs, VPLS that sort of thing. Theres been a thrust towards perfecting the fully automated ISP as a service offering where the MSP integrates with the ISP to automate provisioning down to the last mile, have some middle guy designate the correct service definition etc. The problem is that all of these services in practical terms start off swinging terms like SDN around and end up with a half built interface and helpdesk defined networking. Its not even that hard. But its an offering that would take someone who right now pays for say 5 Layer 2 tails in a managed network and convert them over to something like 5 cheaper tails with encrypted by default networking.

Trust me when I say that a lot of people buying products like these trust their ISP implicitly and a service offering that was little to no touch for them to advertise new security features would be well regarded.

2. Even if you have good practices, your ISP is still a risk in terms of PID. This is something that a lot of ISPs want to change about themselves but dont have the time, patience or well lest face it technical capability to resolve. I could fill this forums database with the shit I have seen.

Just a couple of scenarios I have seen that I can easily file the serial numbers off of.

1. Small ISP sold a managed router product. Upon inquiring how they access these managed routers I was given a list of IP addresses and told to use PPTP. The PPTP tunnels were unauthenticated or at best simple creds, running on an alternate port. Saved likely because the vendor used a slightly weird pptp implementation and you may have needed to use their client for some software versions to initiate the tunnel. Customer was also a business with 5 offices and ~ 50 staff.

2. Small ISP exposed its vsphere management to the internet and got completely hosed by cryptolocker.

3. Small ISP stored all its customer details in an excel document in their public web directory.

4. Small ISP would routinely get hosed because they wanted all their infrastructure to be publicly routable, never applied updates and made sure their passwords were simple enough to be memorised by their most venerable field techs.

5. Small ISP provided a "Managed Network" to a serviced office firm. All businesses in the serviced office were layer 2 adjacent.

6. Medium size ISP would pass one clients traffic through up to 3 other customers managed routers before building egress.

7. Medium size ISP had field techs accessing their core network via a shared VPN credential that was not changed during staff turnover.

8. An ISP services platform that is well regarded in a small corner of wisp land uses a single vendors API to do everything. No Radius. No encryption. All tasks are completed by in the clear api calls. There is no vendor supported API based authentication method. So it simply polls every box in the network every minute and updates static ip addresses as needed. The developers have never heard of SNMP, so they just use the vendors built in bandwidth test against every link in your network every few minutes. Dont raise a support ticket, they dont want to know about standards and protocols because they are doing it their way which is the correct way.

The issue is that, depending on where you live in the world, telco can have razor thin margins and the worst salesmen imaginable. They often cant or wont hire a security specialist until its way too late. ISP owners will often just, ask another ISP owner complex technical questions and do whatever the other guy told me. I found a guy selling high value PTP links and he was using a network design that was common for trailer parks, and I asked him how he came up with that, he said he designed his network based around a very convincing facebook post.

You cant fix intentional ignorance. But while its legal for the intentionally ignorant to own and operate telecommunications infrastructure I humbly suggest "The Box" would be a very valuable product.

"The Box" gives you both staff and customer directory services, centralised and encrypted, with access methods requiring a baseline level of security. "The Box" integrates with an idiots favourite network platform for authentication "The Box" gives you super easy to delegate and revokable individually credentialed VPN access for field techs and contractors. "The Box" can handle radius auth or ldap for authentication with most networking hardware

I would actually spend time suggesting this to anyone who has made me facepalm more than 3 times already.

Considering the amount of jargon in this post, I'd say no.

What pain point are you trying to solve?

I can't tell you how to sell it, but I can tell you what you would need to offer me, for me to buy it as a security tool:

Your company must: * be quite large, including dedicated security teams * have a rock solid lengthy reputation (or you would need to be a big name in cybersecurity as its founder) * demonstrable security hygiene & certifications (secure development practices, pentesting, SOC2, etc.) * offer products with flexibility to suit my needs * solve a real problem I have, not a theoretical one

It's going to be an uphill challenge to build a company in the security market, unless you're a really big name in cyber. It's a worthwhile challenge, but expect it will take either big investment or a long time starting out before you see the rewards, especially with such a niche product that doesn't really fit into the large enterprise space, and given most small shops won't want the complexity or have the budget for it.

This is a well articulated enterprise perspective; a huge part of selling "security" to people is trading on trust/reputation which takes time to build, and I would be starting from zero on that plane. And I also don't yet have vast flexibility in the products I offer. It's an uphill battle at first.

I could bypass this by partnering with a strong reputation. Alternatively, I could de-emphasize "security" in my early marketing as I build my brand: "Easy app deployments!" "Set-and-forget wifi certificates!"

Can a customer buy multiple of these and have them automatically synchronize? For the users directory at the very least, and any other resources that need to be shared.

If not, then it's going to constrain businesses who want to open remote offices abroad. For example, having this appliance in a UK office while the US satellite office struggles to use it at latency, isn't a good experience.

Also you haven't mentioned backups. When the appliance eventually fails - which it will - how will a customer restore their data onto a replacement? And if they want to port their data out, how can they easily do this?

I started to consider HA deployments but stopped to make this post; this is a high-effort feature that needs to be well integrated and tested.

Once I can sync two appliances on one site (for rapid failover) the inter-continental syncing should be easy.

Backups are straightforward. A cron job runs a script that dumps all data and builds a debian package with some control files that perform the restoration. The goal was to be able to deploy a new controller with terraform and restore it to a known state. I'm not sure if this is a great production strategy for other companies (do they already have a secure way to sign/encrypt/distribute packages of their clear text configuration data?), it just made my own ops very easy.

Also, for porting out of the product, a seasoned windows admin could probably transfer the LDAP data into Active Directory in an afternoon -- faster, if I took time to document/test the process.

If you want to integrate this into Windows AD look at ADFS[1] and MSAL[2]. Pretty much can give you OIDC from AD, but you'll have to deal with Microsoft licencing :D.

[1] https://learn.microsoft.com/en-us/windows-server/identity/ad... [2] https://learn.microsoft.com/en-us/entra/identity-platform/ms...

For the past several months I've been wanting to build something similar for a use case that I think would be suitable for such an appliance. Mind reaching out to me via the email in my profile?

Similar story for me. Elevation, your post is a form of marketing and you need to give people a way they can contact you. For a start, email address in your profile.

Sounds like you solved a lot of problems. I’d probably give up folding money for a DC with RADIUS solution that didn’t require me to rip hair out to renew the 802.1X certs for our WiFi auth every year.

Is the problem more in generating the certificates? Or in getting them uploaded into the controller?

I'd seriously started to look into 802.1X but in the "remote work" use case, L2 protection doesn't buy you much because outside your building, an attacker can get L2 access at Starbucks. It seemed like a good feature to leave out of the MVP -- but now I'm wondering if it wouldn't be worth prioritizing.

It was already asked, but I'm curious what the actual difficulty is with rotating certificates? Do the clients need certificates issued? Uploading the chain/authenticating certificate to the authenticator?

Even big customers have a use for what you've built in high security areas they might have. Think swift alliance servers in a specialized network segment in financials, or perhaps sensitive medical information in health care?

I think you should not have any issues integrating with legacy AD, but know bigger enterprises have mostly moved to online IdPs. Integrating with legacy AD will make your product also likely less secure. Maybe not the way to go?

For anyone else wondering what IdPs are:

> What is an identity provider (IdP)? > > An identity provider (IdP) is a service that stores and verifies user identity. IdPs are typically cloud-hosted services, and they often work with single sign-on (SSO) providers to authenticate users.

Read a full explanation at: https://www.cloudflare.com/learning/access-management/what-i...

I'd buy this as a one time payment for my homelab.

Perhaps see if you can put together a department-focused bundle — something that can coexist with corporate VPN but be used for a 50-300 person team’s needs. Plenty of big orgs have small-company-scaled deployments within disparate teams, and they often have terrible security / compliance / access policies for some time until they reach a certain scale.

If you’re able to disable user+pass requirement and only require a yubikey for auth, i’d like to buy this. My email is in my profile.

Off hand:

- security product, startup, and platform companies

- political campaign offices

- certain law firms

- private military contractors

Most orgs depend on compliance to defray their net risk instead of going this hard to mitigate it. there are cases I'll leave for others, but what the above have in common is they are mission driven and operate outside the compliance narrative.

You have a lot of assumptions and not a whole lot of actual data at this point.

Go sell it, talk to potential buyers, see what works and what doesn’t, get feedback and adapt depending of that.

There is no point overthinking it especially if you already have a MVP. You will be wrong anyway.

Have you heard of 0pass? Sounds kinda similar to what you're doing, and they are a YC-backed company. Maybe try reaching out to them.

No substitute for talking to potential customers. Find some and ask them about their problems. Don't build the admin panel, but you can mock it up so that people have a better understanding.

How would you find some people who might be interested? This is the crux of marketing!

* find communities where such folks might hang out. This includes looking at places where self hosting is big (reddit, here, slacks, discords). Read stuff. If there's commercial channel, post there but respect the community.

* find in-person folks to talk to. local linux group meetups, local security meetups, etc.

* look up anyone on linkedin or in your work network and ask for 15 minutes of their time to get ideas on who might be interested in talking to you about this product. Stick to the 15 minutes, though.

* do some google searches that your potential customers might perform. From your description, I'm not sure I'd use the term "domain controller". Seems more like an app gateway or smart proxy instead. See who else is out there and who their customers are.

* searching might also turn up some communities for you to join.

* build a landing page explaining your product (as it will be). Add a mailing list. See if you can get anyone to sign up.

* You could buy some ads to drive folks to the landing page too. Use the same keywords you wanted to use. Set a limit as Google is happy to take your money.

* if you have more time than money, write up a few articles about building this, publish and share them. This sounds like a great topic for HN. Make sure you link to the landing page.

It's not easy, and this is why there are entire marketing and sales departments.

This post is a good overview too: https://www.kalzumeus.com/2013/04/24/marketing-for-people-wh...

Here's some classic patio11 wordplay.

> The other way I did, was I went home to Chicago, which is where my family is from, and took out $400 from an ATM, and walked around downtown Chicago and looked for salons and other massage therapists, that sort of thing.

> I walked in and said, “Hey, do you take walk‑ins?” “Yeah.” “Are you free right now?” “Yeah.” “Are you the business owner?” “Yeah.” “OK, I’ve got a weird proposition for you,” and no, not that kind of weird.

> “What’s the rate on a 30‑minute shoulder massage?” She would tell me. It’s almost always a she. I would say, “OK, I’m going to pay you the rate for a 30‑minute shoulder massage, but what I’m really interested in, I’m a small businessman, I live in Japan, I’m interested in the business of massage therapy. How about we just skip to that post‑massage cup of tea that you’re going to offer me,” I have learned this over the years. “Skip to the cup of tea, I’m going to pick your brains about how you run your business, and then I’ll go, no massage needed, and you get your money?” Almost everybody took me up on that, and nobody called the police. Yay.

This is solid advice, thank you! I love the idea of mocking up the admin panel but then circulating it to get feedback from potential customers early.

Glad to help. Two other pieces of advice:

* Put a note in your calendar to follow up this thread in 6 months and let everyone know your progress (or your decision not to progress, either is fine :) )

* If you are moving forward, start a startup accountability email list. Super easy to do, free, but will act as a forcing function for your activities. Wrote more on that here: https://www.mooreds.com/wordpress/archives/3324

> I forsee problems connecting with the right market

Finding the right market is hard work and consists entirely of rejection until you find it and entirely of rejection if you don't.

> * Clients who have meaningful IT budgets...

> * Clients who are too small...

Selling is hard work and mostly or entirely rejection. Finding reasons not to sell is much easier and avoids the hard work and the psychological tolls of rejection.

> How would you sell what I've built?

One customer at a time. That's how selling is.

On a brighter note. Hardware is a useful abstraction. Customers with big budgets will pay handsomely for annual service contracts and you can fly out in business class, stay in a nice hotel and markup the cost 25% in the materials section of your time-and materials invoice.

Good luck.

Nothing is impossible, so best of luck to the OP, but to add to the above, the kind of clients with the budget for your solution might also be the kind where their legal department requires that you have audited compliance procedures for various certs. It sounds like you design your solutions with the tech work for that already in mind, but it’s something that needs extended to the paperwork side of things to get past the gatekeepers

What are you providing that isn't already available with "Smart Card" (PIV) login?

in practical terms. It can sell, but you probably can't sell it. You need to get a ceo partner with serioues experience in the security field. The right person/company could also be a first investor.

Is using on-prem instead of cloud/SaaS a "competitive advantage?"

Get in touch with Yubico

Tinypilot seems like a good companion

Reply on news.ycombinator.com