3 ms·

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 serve

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.
- pcpuser 2y ago
  Which server is running plain HTTP? What credentials are transmitted over plaintext? I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear. I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though.
  - Grimeton 2y ago
    I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear. Nobody suggested that. But I said that it is said in the article that the UUID needs to be sent to the server to get the request signed and that the UUID is the only identifier while the server itself runs on HTTP, which is also said in the article. Now go and put 1&1 together. Btw, I read the RFCs, that's why I don't see the point in this setup. I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though. There is no misguided feedback here. You want to go back to the drawing board and read up about x.509 and think stuff through. All you do is overcomplicating things by using x.509 instead of the UUID directly being blinded by the idea of some kind of security.
    - pcpuser 2y ago
      The UUID is "sent" to the server in the signed certificate. Not in the clear or over an app protocol like HTTP. There's no way to fake this UUID.
      - Grimeton 2y ago
        I'm talking about sending the CSR to the server that runs on http. Bifrost CA server is a plain HTTP server that responds to X.509 Certificate Signing Requests (CSRs) sent via POST requests. The server validates CSRs, signs them, and returns signed certificates to clients. *PLAIN* http server. and also mentioning how operators can secure access to the server. Also it says: Bifrost recognises clients by their ECDSA P-256 key pairs. A client’s UUID is the hash of the public key and the namespace. The namespace is any UUID that identifies a domain or application. When you send a CSR, the CSR contains the public key. You __REALLY__ need to read up on x.509.

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.

pcpuser 2y ago
Which server is running plain HTTP? What credentials are transmitted over plaintext? I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear. I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though.
- Grimeton 2y ago
  I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear. Nobody suggested that. But I said that it is said in the article that the UUID needs to be sent to the server to get the request signed and that the UUID is the only identifier while the server itself runs on HTTP, which is also said in the article. Now go and put 1&1 together. Btw, I read the RFCs, that's why I don't see the point in this setup. I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though. There is no misguided feedback here. You want to go back to the drawing board and read up about x.509 and think stuff through. All you do is overcomplicating things by using x.509 instead of the UUID directly being blinded by the idea of some kind of security.
  - pcpuser 2y ago
    The UUID is "sent" to the server in the signed certificate. Not in the clear or over an app protocol like HTTP. There's no way to fake this UUID.
    - Grimeton 2y ago
      I'm talking about sending the CSR to the server that runs on http. Bifrost CA server is a plain HTTP server that responds to X.509 Certificate Signing Requests (CSRs) sent via POST requests. The server validates CSRs, signs them, and returns signed certificates to clients. *PLAIN* http server. and also mentioning how operators can secure access to the server. Also it says: Bifrost recognises clients by their ECDSA P-256 key pairs. A client’s UUID is the hash of the public key and the namespace. The namespace is any UUID that identifies a domain or application. When you send a CSR, the CSR contains the public key. You __REALLY__ need to read up on x.509.