Encrypted Communications
When running within a browser, Macromedia Flash Player uses the browser's HTTP services to communicate through RTMPT. Since browsers also support SSL, why not add in support for secure encrypted HTTPS tunneling? That is exactly what Macromedia did. You can request an HTTPS tunnel using a third protocol: RTMPS. For example:
nc.connect("rtmps://myHost.myDomain.com/myApp/myInstance");By default, the player attempts to connect to port 443 when you specify RTMPS as the protocol. However, Macromedia Flash Communication Server MX version 1.5 does not support SSL communications—so you might think that encrypted communications with SSL are not possible. But all is not lost. If you want SSL-encrypted communications, there are three ways you can make it work:
-
Install wrapper software such as stunnel (see http://www.stunnel.org/) on your communication server to handle the encrypted traffic on a port such as 443, and pass unencrypted communications back and forth to Macromedia Flash Communication Server on another port, such as 1935.
Figure 9. stunnel running on the same host as Macromedia Flash Communication Server. stunnel listens for encrypted communications on port 443 and passes unencrypted communications to Macromedia Flash Communication Server listening on port 1935. The thicker arrow shows SSL-encrypted communications.
Have the Macromedia Flash movie connect to a second server running software like stunnel. In turn, you can configure the second server to connect to the communication server and pass unencrypted data back and forth. In this scenario the system running stunnel acts as an intermediary for all communications. Encrypted communications data passes back and forth between the Macromedia Flash Player and the server running stunnel. The intermediate host running stunnel and the communication server exchange unencrypted communications.
Figure 10. stunnel running on its own host
Note: stunnel listens for encrypted communications on port 443 and passes unencrypted communications to Macromedia Flash Communication Server listening on port 1935 on a different host.
In this example, the SWF must connect to the host address of the stunnel machine; it does not connect to the address of the host running the Flash Communication Server. For example, if stunnel is running on stunnel.mydomain.com and the communication server is running on fcs.mydomain.com, a valid URI would be in the following form:
rtmps://stunnel.mydomain.com/myapp/myinstance
-
Use a dedicated SSL accelerator tied into a network switch to accept encrypted traffic and decrypt communications before they reach Macromedia Flash Communication Server.
Figure 11. A network switch and SSL accelerator work together to exchange encrypted information with the workstation and to pass unencrypted information back and forth to Macromedia Flash Communication Server. The thicker arrow indicates an SSL connection between the workstation and port 443. The network switch connects to port 80 on the host and passes unencrypted data back and forth to it.
Of the three methods, this third one is by far the best solution, although it is often the most expensive. Dedicated network/SSL hardware performs better than server-side solutions and, in many respects, it is transparent to the communication server, requiring less configuration work.
SSL hardware accelerators that work with network switches are designed to remove the load of processing SSL from web servers. Configuring stunnel can be challenging. For example, if you do not set up transparent proxy mode, which is available only on UNIX systems, every Macromedia Flash client will appear to connect from the IP address of the stunnel machine. Also, clients that disconnect from stunnel may leave ghost connections to Macromedia Flash Communication Server that you have to detect and close.
Finally, regardless of what setup you use, if you issue your own certificates, consider purchasing one from a recognized authority. In our tests we ran into problems with the way Microsoft Windows handles unrecognized certificate authorities. Unfortunately setting up, configuring, and testing stunnel or dedicated network/SSL hardware are subjects that require another article, so I won't tackle those subjects here. Check out http://www.stunnel.org/ as well as http://www.openssl.org/.
Submit feedback on our tutorials, articles, and sample applications.
