The place to look is the TURN proposed standard, RFC 5766. The standard provides a means for relaying UDP packets containing application data between a client and a peer:
Once an allocation is created, the client can send application data to the server along with an indication of to which peer the data is to be sent, and the server will relay this data to the appropriate peer. The client sends the application data to the server inside a TURN message; at the server, the data is extracted from the TURN message and sent to the peer in a UDP datagram. In the reverse direction, a peer can send application data in a UDP datagram to the relayed transport address for the allocation; the server will then encapsulate this data inside a TURN message and send it to the client along with an indication of which peer sent the data.
The highest layer that TURN parses is the UDP layer. It does not understand or modify the application data layer (in your case, the WebRTC protocol). The standard says:
An application wishing to ensure that its data is not altered or forged must integrity-protect its data at the application level.
This implies that you can integrity-protect your application data, and TURN will relay it without modification. You can also look at the details of the TURN protocol (which I won't repeat here) that show that it merely wraps and forwards application data.
Finally, the standard says this on eavesdropping:
Confidentiality for the application data relayed by TURN is best
provided by the application protocol itself, since running TURN over
TLS does not protect application data between the server and the
peer. If confidentiality of application data is important, then the
application should encrypt or otherwise protect its data. For
example, for real-time media, confidentiality can be provided by
using SRTP.
The recommendation in this excerpt is to protect confidentiality by encrypting application data with a protocol such as DTLS-SRTP, which WebRTC uses.
Because TURN does not interpret or modify application data, it doesn't add any security vulnerabilities to WebRTC application data traffic that wouldn't be present without using TURN. WebRTC data is encrypted between WebRTC endpoints.
Now, no one can guarantee that there is "no way for the TURN server to get access to the secret." A rogue TURN server could attempt a man-in-the-middle attack on your connection just as easily as anyone else who can intercept your network packets. It's only true that using a TURN relay doesn't weaken WebRTC security.
As long as DTLS is implemented and used properly and assuming the DTLS algorithms and ciphers are secure, WebRTC traffic should be secured end-to-end. Part of using any SSL-based scheme requires verifying the certificate of the other endpoint, just like HTTPS. And just like HTTPS, this will require a prior out-of-band exchange of certificate identity or use of a trusted third-party. And just like HTTPS, if certificates are not properly verified then the door will be open for a MITM attack (by anyone, not just TURN servers).
