4 ms·

Show HN: Bifrost MTLS Authentication

1 points by pcpuser 2y ago

Bifrost brings simple mTLS authentication to Go applications.

Grimeton 2y ago
I read this text three times, what problem are we trying to solve here? What am I missing? Yes I understand that this is about "automatically" rolling out certificates, but what problem of that process is solved by this server?
- pcpuser 2y ago
  I'll quote the second para: The idea behind Bifrost is to provide clients a mechanism to create unique identities and register with a central authority, without having to provide sensitive information like passwords or API keys.
  - Grimeton 2y ago
    Yeah I understood this, the issue I'm facing here is the following: When I grant access to services/information based on certificates presented to me by a client, then I want to make damn sure that the certificate is not handed out to someone that shouldn't have it. So reading stuff like this: The server is stateless and doesn’t store any information about clients. The server is also unauthenticated, meaning that anyone can request a certificate. I'm not entirely sure if I want that. Also I'm not entirely sure if I want to sign certificates w/o having any kind of log so that I can revoke those later. Similar to this: Operators use an out-of-band mechanism to verify and trust client UUIDs. and this: Place it behind a network-based protection mechanism (reverse proxy, secure gateway, firewall); So I have to provide a mechanism that allows me to identify the client in the first place to then hand out certificates that are being used to identify the client. It feels like we're either producing a security problem (no checks, see above) or we’re fixing an issue we don’t have as we’re already able to identify the client properly, while that identification needs to be done by other means that usually involve API-keys, passwords or similar things. Which one is it? Don't get me wrong here, I'm sure there are certain scenarios where mutual or client authentication can only be done using X.509 certificates, I’m not denying that, I just don’t understand how this scenario should play out.
    - pcpuser 2y ago
      Yeah that part about deploying could use a lot more context. The idea is that any client can go and get itself a certificate and talk to your application server. All clients start off "un-verified" or "deactivated", until an operator comes around and verifies them by their UUIDs. Once they are trusted, they continue talking to your app servers but now they can access more privileged endpoints. This access control is as simple as storing a trusted boolean alongside client UUIDs. You could also deploy the CA inside an isolated network. Such as deploying it as Kubernetes service, so that only pods running inside the cluster can certify themselves. It's a very simple (and cheaper) alternative to running AWS Private CA instances or hosting SmallStep's CA yourself.
      - Grimeton 2y ago
        Yeah listen, the more I look at this, the less sense it makes. It’s pretty simple: I understand the server running on http only has the possibility in mind that there is a reverse proxy that terminates TLS. That’s fine. Running the server in plain http I’m having problems because the identifying credentials are transfered in plain text, visible for anyone that can monitor the network traffic. Running something like this inside a DC where, in theory, no third party has access to the server or network may be fine as well, but the problem you’re trying to solve here, I don’t see it. The only way to revoke acces in an X.509 environment is by revoking the client’s certificate unless you use some other means to identify the client, which in turn renders X.509 client authentication useless. And using a CRL, even an incremental one, requires the server and the client to periodically fetch this file. Even with one minute intervals, there’s a one minute window were a compromised client can acccess the services and cause damage. Also it seems that your stateless server neither creates a log of created certificates, for traceability, nor a CRL that it offers via HTTP. So w/o CRL you’re handing out certificates that you have zero control over. I don’t know if that’s what you want, not even in a closed environment. Everything you do, can be done with the help of a tab separated text file: Enabled UUID 1 76810c3a-ffbd-4f8b-b836-a14e134b6377 and then the clients just set a HTTP-Header with their UUID. The thing here is: You're not just not solving a problem, you're creating ten new ones.

1 points by pcpuser 2y ago

Bifrost brings simple mTLS authentication to Go applications.

I read this text three times, what problem are we trying to solve here? What am I missing? Yes I understand that this is about "automatically" rolling out certificates, but what problem of that process is solved by this server?

pcpuser 2y ago
I'll quote the second para: The idea behind Bifrost is to provide clients a mechanism to create unique identities and register with a central authority, without having to provide sensitive information like passwords or API keys.
- Grimeton 2y ago
  Yeah I understood this, the issue I'm facing here is the following: When I grant access to services/information based on certificates presented to me by a client, then I want to make damn sure that the certificate is not handed out to someone that shouldn't have it. So reading stuff like this: The server is stateless and doesn’t store any information about clients. The server is also unauthenticated, meaning that anyone can request a certificate. I'm not entirely sure if I want that. Also I'm not entirely sure if I want to sign certificates w/o having any kind of log so that I can revoke those later. Similar to this: Operators use an out-of-band mechanism to verify and trust client UUIDs. and this: Place it behind a network-based protection mechanism (reverse proxy, secure gateway, firewall); So I have to provide a mechanism that allows me to identify the client in the first place to then hand out certificates that are being used to identify the client. It feels like we're either producing a security problem (no checks, see above) or we’re fixing an issue we don’t have as we’re already able to identify the client properly, while that identification needs to be done by other means that usually involve API-keys, passwords or similar things. Which one is it? Don't get me wrong here, I'm sure there are certain scenarios where mutual or client authentication can only be done using X.509 certificates, I’m not denying that, I just don’t understand how this scenario should play out.
  - pcpuser 2y ago
    Yeah that part about deploying could use a lot more context. The idea is that any client can go and get itself a certificate and talk to your application server. All clients start off "un-verified" or "deactivated", until an operator comes around and verifies them by their UUIDs. Once they are trusted, they continue talking to your app servers but now they can access more privileged endpoints. This access control is as simple as storing a trusted boolean alongside client UUIDs. You could also deploy the CA inside an isolated network. Such as deploying it as Kubernetes service, so that only pods running inside the cluster can certify themselves. It's a very simple (and cheaper) alternative to running AWS Private CA instances or hosting SmallStep's CA yourself.
    - Grimeton 2y ago
      Yeah listen, the more I look at this, the less sense it makes. It’s pretty simple: I understand the server running on http only has the possibility in mind that there is a reverse proxy that terminates TLS. That’s fine. Running the server in plain http I’m having problems because the identifying credentials are transfered in plain text, visible for anyone that can monitor the network traffic. Running something like this inside a DC where, in theory, no third party has access to the server or network may be fine as well, but the problem you’re trying to solve here, I don’t see it. The only way to revoke acces in an X.509 environment is by revoking the client’s certificate unless you use some other means to identify the client, which in turn renders X.509 client authentication useless. And using a CRL, even an incremental one, requires the server and the client to periodically fetch this file. Even with one minute intervals, there’s a one minute window were a compromised client can acccess the services and cause damage. Also it seems that your stateless server neither creates a log of created certificates, for traceability, nor a CRL that it offers via HTTP. So w/o CRL you’re handing out certificates that you have zero control over. I don’t know if that’s what you want, not even in a closed environment. Everything you do, can be done with the help of a tab separated text file: Enabled UUID 1 76810c3a-ffbd-4f8b-b836-a14e134b6377 and then the clients just set a HTTP-Header with their UUID. The thing here is: You're not just not solving a problem, you're creating ten new ones.