4

We're trying to migrate our system from a private data center to a public one (AWS). There are other systems we have no control over that communicate with the one in the private data center. They communicate to us using Mutual Authentication. We want to make the migration have as little effect on them as possible.

enter image description here

One of my biggest concerns is that they won't be able to communicate with our system in the new data center for security reasons. I'm looking for a way of testing that we accept their calls in the new environment before we cut over to it so that we can minimize the risk and find issues without it effecting people.

I'm unsure of my options, given that this is Mutual Auth/SSL. Ideally (from a risk mitigation perspective), I would be able to capture some of requests sent by them to our existing proxy and replay it on our new proxy and see if it accepts the traffic. But, I have a feeling that this wouldn't work because it would be a security vulnerability to replay networking traffic. But, I'm no security expert. They will not share their private keys with us.

What are some ways I could test that Mutual Auth connections that work in one environment still work in a new environment?

Daniel Kaplan
  • 143
  • 5
  • Replay likely wouldn't work, due to replay attack protection, like transient data like DHE session keys. Even if you manage to instrument your system to capture these, you'll be raising doubts whether these would've still worked after the instruments are dismantled. Safest trade-off, is to retain the SSL terminator on the old place, and then proxy to the new infrastructure. Second safest solution is to forward the TCP/IP packets. After setting up these, migrate your partners one by one over time to connect directly to new infrastructure. – Lie Ryan Nov 24 '16 at 03:36

1 Answers1

3

So you're essentially doing a MiTM for mutual TLS connections. For this you need 2 things:

  1. You'd need the private key of the client, which is used to encrypt data with.
  2. You need to intercept their connections to your proxy endpoint. This could mean that you need to accept your proxy certificate as a valid CA.

This ways, you would be able to decrypt it (they're connected to you, you're the endpoint, it's encrypted with your public key), "Analyze it", re-encrypt it (with the private key from the clients) and send it to the real endpoint.

ndrix
  • 3,206
  • 13
  • 17
  • They are unwilling to share their private key. Does that mean there's no way to realistically test as them? – Daniel Kaplan Nov 23 '16 at 19:43
  • That's correct, hence it's end-to-end encrypted. There's no (easy) way to perform MiTM on TLS connections, especially if they perform proper validation (pinning / chain validation, ...). – ndrix Nov 24 '16 at 00:47
  • @DanielKaplan: IMO, the biggest risk here is that they might have an outbound firewall rule or if your side might have a inbound firewall that you might not be aware of, and changing the IP address will break due to that. In terms of the SSL itself, as long as both sides used sane configuration and both SSL stack are not terribly ancient, then you should be fine. – Lie Ryan Nov 24 '16 at 11:01
  • @LieRyan unfortunately, we already discovered that NGINX and our old proxy handle SSL differently. – Daniel Kaplan Feb 17 '17 at 21:37