3 ms·

Oh man I had a great one last week. We're migrating stuff to a cloud provider, and they wanted to expose an internal only API to the internet so that the thing

Oh man I had a great one last week. We're migrating stuff to a cloud provider, and they wanted to expose an internal only API to the internet so that the things could reach it. I was strongly against that, as it has no security involved at all. Fast and loose and all of that. Two, count them, two people wanted to "just change it to use port 443, that way it's encrypted". I had to explain that you could pick any valid TCP port to pass TCP traffic, but simply changing a nonstandard port to "443" doesn't automatically make it start being encrypted. I had to explain that several times in order for it to sink in.

vngzs 6y ago
If it's AWS, the quickest path to doing this securely is AWS API Gateway mTLS authN[0]. You generate some certs, stuff the public halves in S3, slap an ACM cert on the Gateway, and you're done. I have also used certificate authentication on TLS-terminating reverse proxies (e.g., this is easy to do with HAProxy) to do the same in other environments. You can pin the API's certificate on the client end in order to further reduce MITM risks. If you don't want to supply a client certificate in your client application, Stunnel[1] is an acceptable wrapper that lets your clients remain TLS-unaware. You could use it for both ends of the tunnel, if you felt like it. Either way, you end up with a secure tunnel through the internet to the proxy, at which point you're back inside private networks. (Source: I build this kind of thing for a living.) [0]: https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway/ https://aws.amazon.com/blogs/compute/introducing-mutual-tls-... [1]: https://www.stunnel.org/auth.html https://www.stunnel.org/auth.html
- NDizzle 6y ago
  Thanks a lot for this comment. I really appreciate it. That mTLS solution is something that would solve this problem immediately.
- MayeulC 6y ago
  I'd just like to point out that it's also very easy to do on most reverse proxies. Client cert, or even regular password protection. Client certs are quite easy to setup. Create a CA cert, sign client certs with it, and allow only clients who have a cert signed by you. Client cert on Nginx: https://fardog.io/blog/2017/12/30/client-side-certificate-authentication-with-nginx/ https://fardog.io/blog/2017/12/30/client-side-certificate-au... Bonus about client certs: https://drewdevault.com/2020/06/12/Can-we-talk-about-client-side-certs.html https://drewdevault.com/2020/06/12/Can-we-talk-about-client-...

vngzs 6y ago

If it's AWS, the quickest path to doing this securely is AWS API Gateway mTLS authN[0]. You generate some certs, stuff the public halves in S3, slap an ACM cert on the Gateway, and you're done. I have also used certificate authentication on TLS-terminating reverse proxies (e.g., this is easy to do with HAProxy) to do the same in other environments. You can pin the API's certificate on the client end in order to further reduce MITM risks. If you don't want to supply a client certificate in your client application, Stunnel[1] is an acceptable wrapper that lets your clients remain TLS-unaware. You could use it for both ends of the tunnel, if you felt like it. Either way, you end up with a secure tunnel through the internet to the proxy, at which point you're back inside private networks. (Source: I build this kind of thing for a living.) [0]: https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway/ https://aws.amazon.com/blogs/compute/introducing-mutual-tls-... [1]: https://www.stunnel.org/auth.html https://www.stunnel.org/auth.html

NDizzle 6y ago
Thanks a lot for this comment. I really appreciate it. That mTLS solution is something that would solve this problem immediately.
MayeulC 6y ago
I'd just like to point out that it's also very easy to do on most reverse proxies. Client cert, or even regular password protection. Client certs are quite easy to setup. Create a CA cert, sign client certs with it, and allow only clients who have a cert signed by you. Client cert on Nginx: https://fardog.io/blog/2017/12/30/client-side-certificate-authentication-with-nginx/ https://fardog.io/blog/2017/12/30/client-side-certificate-au... Bonus about client certs: https://drewdevault.com/2020/06/12/Can-we-talk-about-client-side-certs.html https://drewdevault.com/2020/06/12/Can-we-talk-about-client-...