RTC Client API Security (Windows Embedded CE 6.0)

[アーティクル]
01/05/2012

1/6/2010

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.

次の方法で共有