Configuring security features

Locating SWF files for verification

The server looks for verifying SWF files in the following locations, in order:

1. The application-specific Application.xml file, if it exists. The Application.xml file defines the location of verifying SWF files in the SWFFolder tag. If SWFFolder contains a file path, the server looks for verifying SWF files in that file path. If SWFFolder is empty, the server looks in the default location: /applications/application_name/SWFs.

2. The Vhost-level Application.xml file. This Application.xml file defines the location of verifying SWF files for all applications on the virtual host. The SWFFolder tag defines the location. If SWFFolder contains a file path, the server looks for verifying SWF files in that file path. If SWFFolder is empty, the server looks in the default location: /applications/application_name/SWFs.

3. The server checks the SWFFolder tag in the Server.xml file. This tag specifies a location for global SWF files, which means SWF files that are common to all applications.

4. If a File plug‑in is enabled for retrieval of SWF files, the server calls the File plug‑in. The server passes any values present in Application.xml or Server.xml to the plug‑in. The plug‑in developer overrides these values with paths to the external content repository.

Configure SWF verification for applications

1. Locate the following section of the Application.xml file:

   <Application> 
       ... 
       <SWFVerification enabled="false"> 
           <SWFFolder></SWFFolder> 
           <MinGoodVersion></MinGoodVersion> 
           <DirLevelSWFScan>1</DirLevelSWFScan> 
           <MaxInitDelay>5</MaxInitDelay> 
           <FirstHashTimeout>5</FirstHashTimeout> 
           <FinalHashTimeout>60</FinalHashTimeout> 
           <UserAgentExceptions> 
               <Exception to="" from=""/> 
           </UserAgentExceptions> 
           <Cache> 
               <TTL></TTL> 
               <UpdateInterval></UpdateInterval> 
           </Cache> 
       </SWFVerification> 
   </Application>

2. Edit the following elements.

   Element	Attribute	Description
   SWFVerification	enabled	Set the enabled attribute to "true" or "false" to turn this feature on or off. The default value is "false".
   SWFFolder	None.	A single folder or a semicolon-delimited list of folders that contain copies of client SWF files. These SWF files are used to verify connecting SWF files. They are the verifying SWF files. The default value is the application's folder appended with /SWFs. For example, for an application called myApplication, if there isn’t a value set for this element, verifying SWF files should be placed in the applications/myApplication/SWFs folder. If you are using the File plug‑in to verify SWF files in an external content repository, leave this field blank. If you installed Apache with Flash Media Server, enter the path to the folder from which you are serving SWF files. For example, if you’re serving SWF files from the webroot directory on Windows, enter the path C:\Program Files\Adobe\Flash Media Server 4\webroot. Important: All SWF files in the specified folder are hashed and cached in memory when the server starts and every time the cache TTL expires. A large number of SWF files can result in start-up time delays and high memory usage.
   MinGoodVersion	None.	Specifies the minimum version of this feature to accept. The default value is 0, which allows this and all future versions. This is a reserved field that works with Flash Player; Adobe recommends keeping the default value.
   DirLevelSWFScan	None.	Specifies the number of levels of subfolders within a parent folder to scan for SWF files. The parent folder is specified in the SWFFolder element. Specifying a positive value scans that number of subfolder levels. Specifying zero scans the parent folder and no subfolders. Specifying a negative value scans all subfolder levels. The default value is 1, which means that the server scans only one subfolder level.
   MaxInitDelay	None	The maximum amount of time to process SWF files, in seconds. The default value is 5 seconds.
   FirstHashTimeout	None	The maximum amount of time that a client can use to provide its first verification to the server.
   FinalHashTimeout	None	The maximum amount of time that a client can use to provide its final verification to the server.
   UserAgentExceptions	None.	Container.
   Exception	from to	A user agent to except from verification. Use the from and to attributes to indicate the lowest and highest versions to except. This is a string comparison, with editing to make all numeric fields equal in length. For more information, see the comments in the Application.xml file and “Create verification exceptions” later in this topic.
   Cache	None.	Container.
   TTL	None.	The time to live for the SWF file, in minutes. The default value is 1440 minutes (24 hours). If a SWF file is removed from the server, the verification values stay in the cache for 24 hours; users can connect to the application until the cache expires.
   UpdateInterval	None.	The maximum time in minutes to wait for the server to scan the SWFs folders for updates when there is a miss in the cache. The default value is 5 minutes, which means a SWF file copied to the SWFs folder is picked up by the server within 5 minutes.

Create verification exceptions

 Add Exception elements to the UserAgentExceptions section of the Application.xml file.

Certain applications—for example, Adobe® Flash® Media Live Encoder—do not support the form of SWF verification used by the server. You can add one or more exceptions to the SWF verification rules that allow specified user agents, such as Flash Media Live Encoder, to bypass SWF verification, as in the following:

<SWFVerification enabled="true"> 
    ... 
    <UserAgentExceptions> 
        <Exception to="FME/0.0" from="FME/2.5"/> 
    </UserAgentExceptions> 
</SWFVerification>

Configure SWF verification globally

You can configure verification for a group of SWF files on the server that are common to all applications.

 In the Server.xml file Root/Server/SWFVerification/SWFFolder tag, specify folders that hold the verifying SWF files. You can also configure other values for these SWF files.

Create folders for the verifying SWF files

1. If the SWFFolder value is the default, create a folder called SWFs in the application’s folder on the server.

   For example, for an application called myMediaApp, create the folder applications/myMediaApp/SWFs. SWF files in the SWFs folder verify connections to any instance of the myMediaApp application.

2. To verify SWF files for application instances, create instance folders in the SWFs directory, for example, applications/myMediaApp/SWFs/chat01, applications/myMediaApp/SWFs/chat02, and so on.

SWF files in the SWFs directory can verify all instances of the application; SWF files within an instance folder can verify only that instance.

Certificates

You can get an SSL certificate from a certificate authority or create a certificate yourself. If a certificate is signed by an intermediate Certificate Authority (CA), it must include the intermediate certificate as part of the certificate that the server returns to the client. Your certificate file (if signed by an intermediate CA) should look something like the following:

-----BEGIN CERTIFICATE----- 
... 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
... 
-----END CERTIFICATE-----

The first BEGIN CERTIFICATE/END CERTIFICATE pair is your certificate. The next BEGIN CERTIFICATE/END CERTIFICATE pair is the intermediate CA that signed your certificate. You can add additional sections as needed.

Secure incoming connections

Specify the location of the SSL certificate and the certificate’s private key, and configure the adaptor to listen on a secure port.

1. Open the Adaptor.xml file for the adaptor you want to configure and locate the following code:

   <Adaptor> 
       ... 
       <SSL> 
           <SSLServerCtx> 
               <SSLCertificateFile></SSLCertificateFile> 
               <SSLCertificateKeyFile type="PEM"></SSLCertificateKeyFile> 
               <SSLPassPhrase></SSLPassPhrase> 
               <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
               <SSLSessionTimeout>5</SSLSessionTimeout> 
           </SSLServerCtx> 
       </SSL> 
       ... 
   </Adaptor>

2. Edit the following elements.

   Element	Description
   SSLCertificateFile	The location of the certificate file to send to the client. Specify an absolute path or a path relative to the adaptor folder.
   SSLCertificateKeyFile type="PEM"	The location of the private key file for the certificate. Specify an absolute path or a path relative to the adaptor folder. The type attribute specifies the type of encoding used for the certificate key file. This can be either "PEM" or "ASN1". The default value is "PEM". The private key and the certificate can be combined into one file. If the key file is encrypted, the pass phrase must be specified in the SSLPassPhrase tag.
   SSLPassPhrase	The pass phrase to use for decrypting the private key file. If the private key file is not encrypted, leave this tag empty.
   SSLCipherSuite	The SSL ciphers: a colon-delimited list of components. A component can be a key exchange algorithm, authentication method, encryption method, digest type, or one of a selected number of aliases for common groupings. Do not change the default settings unless you are very familiar with SSL ciphers. The possible values are listed here: SSLCipherSuite.
   SessionTimeout	The amount of time in minutes a session remains valid. Any value less than 1 is read as 1. The default value is 5. If a client reconnects to a session before SessionTimeout is reached, the cipher suite list isn’t sent during the SSL handshake.

3. To configure a secure port for an adaptor, specify a minus sign before the port number in the ADAPTOR.HOSTPORT parameter in the rootinstall/conf/fms.ini file, as follows:

   ADAPTOR.HOSTPORT = :1935,-443

   This configuration tells the server to listen on ports 1935 and 443, and that 443 is a secure port that receives only RTMPS connections. An RTMPS connection to port 1935 fails: the client attempts to perform a SSL handshake that the server fails to complete. An RTMPS connection to port 443 succeeds: the client performs a SSL handshake that the server completes. An RTMP connection to port 443 also fails: the server tries to perform a SSL handshake that the client fails to complete.

4. Restart the server.

5. Check the rootinstall/logs/edge.00.log file to verify that no errors have been reported.

Configure incoming connections when multiple virtual hosts are assigned to one adaptor

You can configure the server to return a certificate based on which port a client connects to. This lets you assign multiple virtual hosts to one adaptor and return a different certificate for each virtual host.

1. Locate the following code in the Adaptor.xml file:

   <Adaptor> 
       ... 
       <Ho4stPortList> 
           <HostPort name="edge1" ctl_channel=":19350">${ADAPTOR.HOSTPORT}</HostPort> 
       </HostPortList> 
       ... 
   </Adaptor>

2. Create new HostPort elements with unique name and ctl_channel attributes and unique port values for RTMP and SSL.

   For example, add the following HostPort tag in addition to the default HostPort tag:

   <HostPort name="edge2" ctl_channel=":19351">:1936,-444</HostPort>

3. For each HostPort element, enter an Edge element under the SSL element with an identical name attribute. If you don’t specify an Edge element, the edge uses the default SSL configuration.

   This sample code demonstrates how to configure edge1 to return cert2.pem when a client connects to it on port 443. Since there is no Edge tag for edge2, edge2 will use the default configuration specified in the SSLServerCtx section that is directly under the SSL container tag. The edge2 server returns cert.pem when a client connects to it on port 444.

   <SSL> 
       <SSLServerCtx> 
           <SSLCertificateFile>cert.pem</SSLCertificateFile> 
           <SSLCertificateKeyFile>private.pem</SSLCertificateKeyFile> 
           <SSLPassPhrase></SSLPassPhrase> 
           <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
           <SSLSessionTimeout>5</SSLSessionTimeout> 
       </SSLServerCtx> 
       <Edge name="edge1"> 
           <SSLServerCtx> 
               <SSLCertificateFile>cert2.pem</SSLCertificateFile> 
               <SSLCertificateKeyFile>private2.pem</SSLCertificateKeyFile> 
               <SSLPassPhrase></SSLPassPhrase> 
               <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
               <SSLSessionTimeout>5</SSLSessionTimeout> 
           </SSLServerCtx> 
       </Edge> 
   </SSL>

4. Validate the XML and save the file.

5. Restart the server.

Secure outgoing connections

1. Open the Server.xml file and locate the following code:

   <Root> 
       <Server> 
           <SSL> 
               <SSLEngine></SSLEngine> 
               <SSLRandomSeed></SSLRandomSeed> 
               <SSLClientCtx> 
                   <SSLVerifyCertificate>true</SSLVerifyCertificate> 
                   <SSLCACertificatePath></SSLCACertificatePath> 
                   <SSLCACertificateFile></SSLCACertificateFile> 
                   <SSLVerifyDepth>9</SSLVerifyDepth>     
                   <SSLCipherSuite>ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH</SSLCipherSuite> 
               </SSLClientCtx> 
           </SSL> 
       </Server> 
   </Root>

2. Edit the following elements.

   Element	Description
   SSLRandomSeed	The number of bytes of entropy to use for seeding the pseudo-random number generator (PRNG). You cannot specify anything less than 8 bytes, and the default value is 16. Entropy is a measure of randomness. The more entropy, the more random numbers the PRNG will contain. The server may take longer to start up if you specify a large number.
   SSLSessionCacheGC	How often to flush expired sessions from the server-side session cache, in minutes.
   SSLVerifyCertificate	A Boolean value specifying whether to verify the certificate returned by the server being connected to (true) or not (false). The default value is true. Disabling certificate verification can result in a security hazard. Do not disable verification unless you are certain you understand the ramifications.
   SSLCACertificatePath	A folder containing certificates. Each file in the folder must contain only a single certificate, and the file name must be hash and the extension ".0", for example, e98140a6.0. On a Windows 32-bit operating system, if this tag is empty, the server looks for certificates in the rootinstall\certs directory. You can import the Windows certificate store to the certs directory by running FMSMaster -console -initialize from a command line. In Linux, you must specify the location of the certificates.
   SSLCACertificateFile	Specifies the name of a file containing one or more certificates in PEM format.
   SSLVerifyDepth	Specifies the maximum depth of an acceptable certificate. If a self-signed root certificate cannot be found within this depth, certificate verification fails. The default value is 9.
   SSLCipherSuite	The SSL ciphers: a colon-delimited list of components. A component can be a key exchange algorithm, authentication method, encryption method, digest type, or one of a selected number of aliases for common groupings. Do not change the default settings unless you are very familiar with SSL ciphers. The possible values are listed here: SSLCipherSuite.

Configure adaptors to manage outgoing SSL connections independently

The SSL section in the Server.xml file configures all adaptors to use the same settings. However, you might want to use a different certificate for each virtual host. In this case, assign one virtual host to each adaptor and configure your adaptors individually to override the settings in the Server.xml file.

 Copy the SSL section in the Server.xml file to the Adaptor.xml files and enter the new values. You don’t need to copy the SSLRandomSeed tag, as this tag is a server-level setting that cannot be overridden in Adaptor.xml.

Configure virtual hosts to manage outgoing SSL connections independently

For example, you can disable certificate checking in one virtual host, use a certificate in a different folder for one virtual host, and implement a different set of ciphers in a third virtual host.

1. Uncomment the SSL section under the Proxy tag in the appropriate Vhost.xml file:

   <VirtualHost> 
       ... 
       <Proxy> 
           <SSL> 
               <SSLClientCtx> 
                   <SSLVerifyCertificate></SSLVerifyCertificate> 
                   <SSLCACertificatePath></SSLCACertificatePath> 
                   <SSLCACertifcateFile></SSLCACertificateFile> 
                   <SSLVerifyDepth></SSLVerifyDepth> 
                   <SSLCipherSuite></SSLCipherSuite> 
               </SSLClientCtx> 
           </SSL> 
       </Proxy> 
   </VirtualHost>

   When the SSL tag is present, the entire SSL section is used to configure the virtual host. If an SSL tag is omitted from this section, the server uses the default settings.

2. Restart the server.

Configure Flash Media Server to work with a hardware SSL proxy

When you use a hardware SSL proxy, you don't need to configure Flash Media Server for SSL. The hardware sits between Flash Media Server and the Internet. Data sent between Flash Media Server and the hardware is unencrypted. The hardware encrypts the data and forwards it to the Internet.

Configure the hardware to listen externally on port 443 to receive encrypted data sent over Internet from clients. Configure the hardware to forward data to Flash Media Server on port 1935. Flash Media Server listens on port 1935 by default. If you’ve changed the default port, configure the hardware to forward data on that port.