As many of you will know, RTMP itself has been widely reverse engineered and documented, which made alternative RTMP servers such as Wowza and Red5 possible. Adobe have also recently announced that the RTMP specs will be made publicly available very soon, and so far I have heard of no action having ever been taken against anyone that implemented just RTMP. Quite clearly, the fuss is about RTMPE, not RTMP. It is the fact that rtmpdump can circumvent certain access controls that made Adobe react. By posing as a Flash Player, rtmpdump can connect to Flash Media Server and successfully pull and record an encrypted stream. In combination with the get_iplayer project rtmpdump made it possible to record all kinds of RTMP based content from sites such as channel4.com and the BBC iPlayer. The version of rtmpdump used within get_iplayer has now been removed and been replaced with a forked version called flvstreamer.
Flvstreamer only supports RTMP based delivery, it no longer works with RTMPE. SourceForge has also removed the project.
Of course all this comes way too late, and the RTME specs are now widely publicised and available to anyone to view - and implement it into new tools. No doubt it will not take long for alternatives to rtmpdump to emerge. What's more, it seems that Adobe has in fact drawn a whole lot of attention to this topic than it would have received had the takedown notice not been issued.
I cannot help but admire the efforts of the open source community. I think it is important that such weaknesses are made public so that improvements can be made, and standards raised. It now appears that RTMPE, while being able to offer an SSL-equivalent encryption strength during transmission, can be circumvented due to limitations in the handshake and SWF Verification features. It is clear that SWF-Verification is not totally secure since rtmpdump can pose as the authorised SWF - which it obviously isn't.
In this document which seems to originate from the author of rtmpdump and his close friends, Adobe receives quite a battering. Here's an excerpt:
"RTMPE is definitely not a 'Copyright Protection' mechanism.
An analysis of RTMPE [...] shows that RTMPE does nothing more than what SSL already does (provide end-to-end secrecy, except without the protection against man-in-the-middle attacks [...] and simply mathematically links a publicly-downloadable and publicly-obtainable SWF file to the connection.
Bottom line: All the information required to obtain the content is publicly available. There is no 'security'.
If the information isn't publicly available (such as the SWF file to be executed in the web browser) then the content cannot be obtained, either."
Interesting stuff. While I am no encryption expert I think I have a grasp on the weaknesses of this system.
I'm hoping to get an email interview with the author of rtmpdump set up very shortly. If you have any specific questions that you'd like me to put to him then please leave a comment below.
Besides, I think it is impossible to fully protect a media file. There are screen capturers and audio recorders, and lots of other tools.
Waiting forward for the interview.
So, what does that mean for RTMP and open source? Same as it did yesterday. Published or not, Adobe has patent rights to RTMP/T/E/S, so if you implement it in your software, you do so with the understanding you may get a similar letter from Adobe legal.
@Fabio, I think a custom callback method or similar misses the point. The rtmpdump author rightly states that RTMPE plus SWF Verification was sold as a secure solution - and if I read the posted documents correctly it seems like a fairly weak mechanism. The onus should not be on the developer to fix holes in the system. Why else didn't Adobe prescribe the need for custom callbacks? The only time I saw that mentioned was in relation to an 'exploit' where an RTMPE connection was attempted (and succeeded) over RTMP for the same piece of content.
I don't think there's such a thing as a 'simple' RTMPE connection. If I put myself in the shoes of an end user deploying RTMPE plus SWF Verification I would assume that that's good enough. And I have a feeling that Adobe themselves thought it was - until now.
this is a critical distinction. the former implies automatically that rtmpdump is illegal and subversive; the second tells it as it is - that rtmpdump is simply an interoperable tool.
there's a trite phrase that says, "guns don't kill people: people kill people". you _know_ that there's no point in locking up a piece of metal machinery and some gunpowder.
that it was so easy to implement SWFverification and RTMPE should tell you something: that the design of RTMPE and SWFverification is flawed - more specifically, the assumption that purely by trying to be the sole and exclusive implementation, somehow this would make SWFverification "secure".
nothing could be further from the truth. security and mass-distribution of multimedia content are simply mutually exclusively incompatible, and content creators and the designers of content distribution mechanisms are simply going to have to accept this: fact.
precisely. by not consulting anyone, by relying on arrogance instead of cryptographic expertise and public peer-review, adobe's flawed design has been shown to be nothing more than what it is: a mish-mash of crypto primitives, the combination of which clashes irresponsibly with what adobe is stating that the mixture is intended to achieve.
it was only a matter of time that these flaws were discovered, but by drawing my attention to RTMPE by threatening one of my peers with a DMCA takedown notice, Adobe GUARANTEED that those flaws would be discovered earlier rather than later.
so, it's finally been noticed that Adobe have lied to their customers - provably and irrefutably lied to them. i don't expect Adobe to thank me for that, but i _do_ expect them to not try it again, by trying to implement yet _another_ failed DRM mechanism. to try that _again_, when they _know_ that it is impossible to achieve, would expose themselves to massive liability and lawsuits, for deception, fraud and mis-selling.
Adobe did not come up with something entirely new - they simply obfuscated TLS and used an anonymous key exchange. That is well understood from a cryptographic point of view, including the security properties (see appendix F.1.1.1 of RFC 4346).
Besides, what would TLS have given them in this case? It asserts the identity of the server through x509 - which is not relevant if you want to protect the data sent by the server.
For me, there are some unanswered questions:
- how were those "constants" discovered?
- how were the obfuscated locations of the DH keys discovered?
- how is this spec "clean-room"?
Anyway... snake-oil rarely works. That was clear months ago, when Mammoth was published.
Stefan: spoofing agent and referer is trivial - they are arguments to the connect RPC sent by the client.
I'm aware that agent and referrer can be spoofed, I was just trying to make the point that there are other measures that can potentially help raise the barrier a little bit.
Good coverage. RTMPe was always just a transport protection mechanism and never provided any file-level encryption to the actual FLV payload.
Adobe is feverishly working on a new version of Flash DRM that will bring file-level encryption to FLV content for playback in the Flash player.
This will be a major inflection point for people using Flash content as RTMPe will be just a memory at that point.
Christopher
clevy@buydrm.com
http://www.buydrm.com
Wow I just read some of your comments and was kind of shocked.
I take it you are not a fan of DRM or in the Digital Media business?
You can dress it up in all manner of hippy bullshit, it boils down to a discredited communism type of mindset that thinks everything should be free.
I don't doubt that 99.999% of uses that rtmpdump will end up in are illegal or morally dubious ones.
By putting such tools into open source circulation, all they are doing is pandering to crooks and pirates.
Stefan, what is the version of RTMP you are talking about in this post ? May be this information may be useful.
By the way, I didn't know RTMP had versions.
you should ask Steve :) I am not aware of any new versions.
I too am very interested in: -
- how were those "constants" discovered?
- how were the obfuscated locations of the DH keys discovered?
-adamryan