1

I have a spring boot app deployed to Swisscom App Cloud that should to be secured with mTLS.

Obviously there's spring security... Specific to Swisscom App Cloud I read about securing traffic on https://docs.developer.swisscom.com/adminguide/securing-traffic.html.

It is unclear to me how the two play together...

  • If I enable mTLS via spring security, would that work as is or would I need additional configuration for the Swisscom App Cloud? (I came across HTTP routing which mentions passing client certificates for mTLS https://docs.developer.swisscom.com/concepts/http-routing.html)
  • Is the configuration of mTLS on Swisscom App Cloud a replacement for what I would otherwise enable with spring security or would I still need to configure something within my application?
  • Securing traffic mentions deployment manifest and BOSH manifest, is the latter (and maybe additional) configuration needed to enable mTLS on Swisscom App Cloud (i.e. would I need to have access to configs besides the deployment manifest) ?

Update

My use case that I have a REST API that will be consumed by a client outside of Swisscom App Cloud. It was decided that it shall be secured using mTLS.

Clauds
  • 950
  • 11
  • 24

1 Answers1

0

The admin guide you're referring to is meant for platform operators (i.e. Swisscom), so it's not a resource that can be leveraged by end users.

What is your use case? If it's only a security requirement to check off a list, be aware that the platform itself will be using mTLS internally soon, so the whole path up until the app container is secured. That might be enough for your auditor.

If you really need to validate client certificates by yourself, CF's way of doing so is leveraging X-Forwarded-Client-Cert (https://docs.cloudfoundry.org/concepts/http-routing.html#-forward-client-certificate-to-applications).

However, we've currently not enabled this (there was no need for it up until now), but we can do so.

Update:

According to this explanation, insertion of X-Forwarded-Client-Cert is actually done transparently by the platform. So if you add the client application's certificate to the server application's truststore, it will verify the client certificate.

Update 2: As you can see in the discussions below, it looks like there is currently conceptually no easy way to allow apps to do proper mTLS using X-Forwarded-Client-Cert. The only option currently is using tcp routes, which is something you can request with your Appcloud support team.

Matthias Winzeler
  • 941
  • 5
  • 5
  • I updated the question with my use case. So in this case I will need to use spring security and check the certificate in the application. It's still unclear to me where I would need to adapt the routing configuration (I might not have access to it at the moment)? – Clauds Oct 17 '18 at 08:08
  • @Matthias - Validation of the cert happens where TLS is first terminated by your platform. Normally it's at a LB, but if you use a layer 4 LB it could happen at the Gorouters. In either case, this device needs to validate the cert presented by the client & if it's valid & trusted, it should add the `x-forwarded-client-cert` headers. If the client cert is not valid or not trusted, the LB/Gorouter would need to reject the request. By the time it gets to the app, it's not possible for the app to do this because the app is not talking directly to the client. – Daniel Mikusa Oct 19 '18 at 12:46
  • Once validation occurs, apps can use the value in `x-forwarded-client-cert` to perform authorization. i.e. look at the common name to identify the user & determine the user's permissions in the app. – Daniel Mikusa Oct 19 '18 at 12:48
  • I think the only way you could push this off to the app is if your app is using a TCP route. In this case, the TLS connection would happen directly with the app and then the app could handle all aspects of mTLS. – Daniel Mikusa Oct 19 '18 at 12:49
  • @DanielMikusa thanks for the explanation! Assuming the LB trusts all client certs, then the app could reject it based on `x-fowarded-client-cert`, for example with a 401? – Matthias Winzeler Oct 20 '18 at 13:06
  • @MatthiasWinzeler - Maybe...but it's not the behavior you'd typically see with mTLS. Normally, the client would try to connect & present it's certs. If the server doesn't trust the client's cert a TLS connection is not even established (handshake fails). I don't know if there are any, but I'd be worried about possible security implications of doing it differently. – Daniel Mikusa Oct 21 '18 at 04:09
  • @DanielMikusa That's interesting. I'm not sure it's so uncommon to enforce authn and authz on the http level for mTLS - i.e. elasticsearch does it that way as well (and percona mysql does it on the mysql level too). What I'm not sure is whether it makes sense that the fronting LB validates for all apps. This might work for CF installations in a single company with a single CA where the platform op can make the decision for apps, but for public clouds, I'd prefer apps being able to bring their own peer validation. Do you have any insight how PWS solves this? – Matthias Winzeler Oct 22 '18 at 07:09
  • I may just be paranoid, but not validating during the initial handshake just makes me feel like I'm leaving a window open, a possibility for someone to break in. I don't know of a way to do it, but it makes me wonder if someone smarter than me would find a way. I guess the other thing that makes me worried is that apps will assume the cert has been validated, since it typically is validated were TLS is terminated. If your LB is trusting everything, no validation really occurs so it's all on the app to do this validation. Failing to do so would leave the app vulnerable to someone faking a cert. – Daniel Mikusa Oct 22 '18 at 15:45
  • In PCF, I think we recommend trusting the Diego Instance ID root & intermediate certs on your LBs. That means any connection from an app (using it's instance ID cert) to another app is automatically validated & supports mTLS. It doesn't cover all situations, but it covers a lot of them and it's a one-time set up. I don't know about PWS. – Daniel Mikusa Oct 22 '18 at 15:49
  • 1
    @DanielMikusa: Thanks! No, you're not being paranoid. That is actually an important distinction that our security officers make: if the TLS socket is open, you can actually speak the protocol to the service, which opens up the attack surface to the protocol layer. Think of a MySQL vulnerability or a HTTP vulnerability which could be exploited. However, I still think we need some kind of "bring-your-own-CA" by Apps for mTLS in the future, otherwise it won't scale. – Matthias Winzeler Oct 23 '18 at 16:11