no validation of upstream server TLS certificates

[MichaelOultram-pexip]

Helpfully, nginx defaults to not verifying TLS certificates on connections to upstream servers. Thus, this needs to be explicitly enabled with (at least):

# Verify upstream TLS server certificate
proxy_ssl_trusted_certificate /path/to/ca-certificates.pem;
proxy_ssl_verify_depth 5;
proxy_ssl_verify on;

Note, however, that the reverse proxy also configures nginx with the IP addresses of upstream servers, thus enabling certificate verification is guaranteed to break this scheme.

Therefore, either:

• We don't care
• We enable TLS certificate verification and require upstream conferencing nodes to be identified by FQDN in nginx config (and have valid TLS server certificates)
• We allow TLS certificate verification to be opted into by the administrator (which then forces the use of FQDNs and proper certificates for conferencing nodes)

[ajf101]

Option 1 or 3... By using a RP, customers are able to avoid the need for DNS/Certs for nodes which are potentially just internally-facing. We should not cut off this benefit.

[jmb202]

I guess the real questions are:

1. What are the risks of someone on the internal network behind the RP MITMming the traffic between the RP and the conferencing nodes?
2. What valuable information is contained in the traffic?
3. Does this present a problem?

The choice of solution should probably fall out of the answers to those (noting also that if internally-facing nodes are directly addressed from other systems on the internal network, then the same considerations would apply).

[MichaelOultram-pexip]

With a client <-> reverse proxy <-> MITM <-> conference node, an sufficient attacker could:

• see any alias/pins dialled
• potentially phish SSO credentials by redirecting the user to a different domain
• potentially gain access to (+decrypt) the udp media stream with some sdp fiddling.

Whilst this is quite a bad outcome, there should be a very low chance of an attacker being able to gain enough access to MITM inside the customers internal network.

I'm propose that the installwizard should accept both FQDN and ip addresses to relay to. If a FQDN is given, then the TLS verification will be turned on, otherwise it won't.

[jmb202]

Note that WebRTC media uses DTLS-SRTP for key generation (i.e. it does not use SDES-SRTP where the keys are sent verbatim in the SDP). Exploiting this, if you are a MITM requires:

1. Replacing the DTLS certificate fingerprint attribute in the SDP with one for a certificate you own the private key for
2. Potentially modifying media addresses signalled in the SDP
3. Terminating the DTLS handshake from the client yourself
4. Performing a corresponding DTLS handshake to the conferencing node using the certificate fingerprint initially present in the SDP.

Further, if ICE is involved, you'll need to jump through the hoops to make that work, too. None of this is impossible, of course.

[Jamie-]

Re-opening as we've backed the changes out in https://github.com/pexip/rp-turn/commit/673f1a9fa8e735fba881cc235be43b3bce6fb6ed due to #54