Installation guide

Content vulnerabilities
Onlinedigitalcontentcanbecompromisedanumberofways:
• Raiding the browser cache—ough the lenames are not easily read, it is relatively simple to
retrieve video les from the browser cache. is vulnerability is only present with progressive
video delivery; streams are never cached.
• Video URI access—VideoURIscanbeeasilydiscoveredusingfree“snier”utilities.
• SWF le re-serving—Your SWF le can be copied and re-served from another domain. SWF
les can also be decompiled, oen revealing your Flash Media Server address, application, and
stream names.
• Replay technologies—Alsoreferredtoas“streamripping,”thisisthemostinsidiousofsecurity
issues because it is more dicult to prevent. Stream ripping utilities intercept the data stream and
record it to a le that can then be played.
Flash Media Server security architecture
Streaming has a higher level of security than progressive delivery, because media les are never
cached to disk. Flash Media Server further enhances protection against other risks with additional
security features:
• Userauthenticationusingserver-sideActionScript
• Authorizationadaptor
• Accessadaptor
• SWFleverication
• Domainaccesscontrol
• Customsolutionsoeredbycontentdeliverynetworks
• StreamencryptionusingRTMPEorRTMPS
First, we’ll look at the overall Flash Media Server security architecture as shown in the following
gure and then examine each of the protection measures in depth. Regardless of the sensitivity
or ownership of your content, you’ll want to implement some level of security when deploying to
theweb.It’sbesttobeginbysecuringyourserver,andthensecuringyourcontent.
Flash Media Server security architecture
Flash Media Server
Web server
Client
Validated
SWF
RTMP
HTTP
Database Authentication
Stream Encryption
Domain Restriction
SWF Hashing
User Authentication
Dynamic Access Control
Unique key/token handshake
53