Step-ca should be able to respond over plain HTTP

[t0xicCode]

As per the discussion #193, step-ca should be able to expose an HTTP port instead of only an HTTPS (or in addition to an HTTPS).

There are situations where the use of HTTPS at the step-ca level is unnecessary or nearly impossible, such as when tls terminating load balancers as used.

If HTTPS is still to be enforced, step could require that either the connection be TLS or that the connection come from a trusted IP and that X-Forwarded-Proto be set to https.

[TheSecMaven]

Can confirm this is the case at my company where this is considered the standard to have the load balancer terminate TLS. X forwarded proto should be confirmed to be https for sure

[mmalone]

Hi folks!

This is a bit of a philosophical issue for us for a couple reasons. We're always learning, so I'm not gonna say we'll never do this, but I want to articulate our position and I'm very interested to hear your thoughts.

First, we aim to make step and step-ca easy to use, and hard to misuse. Assessing whether non-TLS (unencrypted, unauthenticated) HTTP is appropriate in the context of certificate issuance is hard. So, if we were to support HTTP at all, I wouldn't want to make it easy to configure step-ca that way (or, if it was easy, I'd want to gate it with a --subtle or --insecure flag or something similar).

Second, and more importantly, we don't believe the traditional "perimeter security" model being described here is a good idea. We believe people should be using authenticated encryption (e.g., (m)TLS) everywhere. While I understand that a lot of folks terminate TLS at a load balancer and use HTTP internally, the whole purpose of this toolchain is to help folks get away from that (anti-)pattern. I don't mean to be derisive here -- I understand lots of folks have legacy issues to contend with and some of these decisions are out of their control, and every threat model is different -- so please don't take this as an indictment. It's an aspiration. We want mTLS to be so easy that you don't mind using it everywhere.

With that in mind, I wonder whether it's possible for your existing proxies / load balancers to be configured to handle step-ca as is. One way to do this is to configure proxying at L3/L4 (i.e., connection based) instead of L7. Another option is to issue your proxy a certificate and have it MITM the TLS traffic from step-ca. If you can share what you're using as a proxy/LB I'd be happy to investigate.

If you really need a way to connect to step-ca using non-TLS HTTP, it is possible to use a second proxy (e.g., running locally on the same server(s) running step-ca) that can lift your non-HTTPS traffic back to HTTPS. So you'd have your apex load balancer terminate TLS and speak HTTP to another proxy, local to step-ca. The local proxy would then speak HTTPS to step-ca. Most proxies (e.g., nginx or caddy or envoy) can be configured to do this.

One thing to note: if you break the end-to-end TLS connection you're gonna break certificate renewal. The existing renewal mechanism uses mTLS, using the existing cert to authenticate the client and issue a new one. This mechanism would need to be redesigned if we didn't use end-to-end mTLS between client & server. The most obvious alternative, using some sort of bearer token signed by the existing private key, would be harder to implement and weaker than the current mechanism.

Hope this all makes sense. I'm all for being pragmatic, but this touches on a pretty core principal. Please consider this the beginning of the conversation, not the end!

[TheSecMaven]

My main counter point to what you have outlined above would be that if one of the things we want step-ca to be good for is simple setup and configuration, then requiring users to adopt new tools/methodology for getting http to work in one of the ways outlined would not be conducive to this. l7 is the most common place this happens, so if we want to make step-ca easy to use we should follow the most common practices.

Aside from that, I am in agreement with you that we need to make it very clear that we feel this isn't the best practice and that users who choose to enable the http need to be aware of the impact in this in all the ways you mentioned (insecure flag, logging with a note that you have requested unencrypted execution, etc.

[mlazowik]

While I understand that a lot of folks terminate TLS at a load balancer and use HTTP internally, the whole purpose of this toolchain is to help folks get away from that (anti-)pattern.

There's another case – TLS terminated at a load balancer (including for performance reasons – shorter handshake + persistent backend connections when the lb is global with anycast). Then a service mesh that does do mTLS internally, but apps are not aware of that.

[hslatman]

Making note of https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-cert-field/, which aims to standardize HTTP headers a TLS terminating proxy should use to convey the client certificate to upstream servers. This would make it possible to support mTLS renewal, while terminating TLS on a proxy server.

[Jiawei0227]

While I understand that a lot of folks terminate TLS at a load balancer and use HTTP internally, the whole purpose of this toolchain is to help folks get away from that (anti-)pattern.

There's another case – TLS terminated at a load balancer (including for performance reasons – shorter handshake + persistent backend connections when the lb is global with anycast). Then a service mesh that does do mTLS internally, but apps are not aware of that.

This is exactly what I am thinking. We want to put the step ca behind the service mesh which we already have automatic mTLS on the service mesh proxy. So making it support http actually making the configuration story easier + remain the same level of security