31–40 of 89 posts
For fun, read that last paragraph out loud to a non-techy near by and watch their eyes...
Earlier quoted context omitted.
It's not really a bug in old coturn, just a feature in the protocol. According to the article newer versions just disable routing to 127.0.0.1 by default but there are still other network addresses you might have to consider (see article for a recommended list of "denied-peer-ips").
You may already know this, but it's worth getting the word out. Do not just deny routing to 127.0.0.1. 127.0.0.1 is merely the conventional "localhost" address; however, ALL 127.x.x.x is "localhost". You can check this now on your local command line with "ping 127.1.2.3". (This just seems to be one of those bugs that every proxy goes through at some point, just like pretty much any attempt to write a web server that…
Things like this are why mTLS internally are so important. If a hole is found in your firewall, services still don't trust each other until they have a valid TLS certificate.
I'm still developing on it a bit but my solution is open source [1]. If anybody want to use this I'm happy to provide answers to questions, and quick bug fixes (as this directly benefits my work right now). If you're using kubernetes this is a pretty easy drop in for your pod. It's part of our default setup now.
Things like this are why mTLS internally are so important. If a hole is found in your firewall, services still don't trust each other until they have a valid TLS certificate.
Things like this are why mTLS internally are so important. If a hole is found in your firewall, services still don't trust each other until they have a valid TLS certificate.
I wish there was an easy way to do mutual TLS auth with pre-shared keys that can be stored and copy/pasted just like normal passwords or API keys without having to maintain a CA and handle certificate issuing & renewal (sure, technically forever-lived certificates aren't as secure, but even those would already be a major upgrade compared to the status quo).
MeTaLS won't provide you with client-related stuff, but most clients and client libs make it easy to set a certificate/key with a request.
So Slack's VoIP uses WebRTC, which connects via UDP/TCP to always send SRTP packets through a TURN proxy (which extends STUN via ICE) to work around usual NAT problems. These guys scanned the TURN and found an SSRF which allowed them to connect to Slack's VPC on AWS using IAM temporary credentials. Interesting. For fun, read that last paragraph out loud to a non-techy near by and watch their eyes...
So Slack's VoIP uses WebRTC, which connects via UDP/TCP to always send SRTP packets through a TURN proxy (which extends STUN via ICE) to work around usual NAT problems. These guys scanned the TURN and found an SSRF which allowed them to connect to Slack's VPC on AWS using IAM temporary credentials. Interesting. For fun, read that last paragraph out loud to a non-techy near by and watch their eyes...
So Slack's VoIP uses WebRTC, which connects via UDP/TCP to always send SRTP packets through a TURN proxy (which extends STUN via ICE) to work around usual NAT problems. These guys scanned the TURN and found an SSRF which allowed them to connect to Slack's VPC on AWS using IAM temporary credentials. Interesting. For fun, read that last paragraph out loud to a non-techy near by and watch their eyes...
"Our recommendation here is to make use of the latest coturn which by default, no longer allows peering with 127.0.0.1 or ::1. In some older versions, you might also want to use the no-loopback-peers."