RTC Client API Security
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/28/2008
The RTC Client API is designed to use a network.
To mitigate potential security risks, use available network security resources.
Best Practices
When using the RTC Client API, keep in mind the following best practices:
Use authentication
The server can ask for authentication in response to a connection request.
After a connection is established, authentication can be challenged for various requests.
The RTC Client API does not respond to a Basic authentication challenge from the server if Transport Layer Security (TLS) is not specified in the profile for the session.
Note
If TLS is not available on all connections on the route between sender and receiver, the credentials remain visible on the segments that do not use TLS.,
Use Transport Layer Security
TLS encrypts data in communication and thereby offers more protection from packet sniffing by anyone with physical access to the network.
TLS is recommended to secure the SIP signaling channel. Otherwise, the server is not authenticated.
Use encryption
If TLS is not available, you can encrypt sensitive information prior to sending it over the network. This prevents unauthorized users from viewing data in transmitted packets.
Enable encryption through the registry.
By default, encryption is turned off.
For more information, see Mode in RTC Client API General Registry Settings.
Ensure that all connections between clients are encrypted
The current version of RTC 1.5 does not support media encryption Therefore all connections between clients should be encrypted. This is to mitigate threats posed by client-to-client communication such as (Spoofing, Tampering, Repudiation, Information Disclosure).
Monitor the number of outstanding requests
If your client subscribes to presence information for multiple contacts, be sure the application processes events in a timely fashion. This prevents the number of outstanding events from becoming too large.
Disable the Static Port
An unauthorized client can contact you when a static port is configured. In order to mitigate possible threats posed by direct client-to-client communication (such as, Denial of Service and Information Disclosure) the static port should be disabled.
Threat model third party CODECs and check them for buffer overflows.
This is to mitigate possible threats posed by access to third party codecs (such as, Spoofing and Elevation of Privilege). If an unauthorized client can contact you through a static port and is granted access, then they are in a position to execute a 3rd party codec.
Default Registry Settings
Be aware of the registry settings that impact security.
If a value has security implications you will find a Security Note in the registry settings documentation.
For registry information, see RTC Client API Registry Settings.
See Also
Other Resources
Real-time Communications (RTC) Client API
Enhancing the Security of a Device