Misconceptions about network security

When looking for a secure Flash protocol for our audio and video call transcoding server we preferred supporting RTMPE (and the tunnelled version RTMPTE) since this was more lightweight than the SSL versions. However users didn’t want to use these protocols, and preferred Adobe's media protocol over HTTPS and SSL (both called RTMPS, though the latter one is also known as native RTMPS). They read online (even on wikipedia) that the RTMPE version were not secure. It is hard to argue with users when they have already read the "truth" on internet. While there certainly are issues with the protocol when you don't know what you are doing, it showed that users have a lot of misconceptions about security.

 

A secure connection does not equal DRM.

Some of the complaints are that RTMPE is a broken DRM solution. However RTMPE is not a DRM solution (Adobe’s Flash Access is). DRM protects the content at each stage, from the moment it leaves the server until it is displayed. DRM does not necessarily encrypt the connection, it encrypts the content. This means the content should stay encrypted until the stream is decoded for viewing, and even then might be protected until it reaches a (secure) display device. The content might be stored locally in an encrypted format and viewed later with the correct credentials. A secure connection only tries to avoid eavesdropping, once the data arrives, it is no longer protected. It is more akin to downloading mail over an SSL connection. The mail can’t be read while in transfer, but once on your disk, it’s just a readable file.

A public protocol is not necessarily insecure.

SSL and TLS are both public protocols as well, though once it was known how RTMPE worked internally, it was seen as insecure. The reason Adobe developed RTMPE was not to have an another proprietary protocol, but to avoid the overhead of an SSL or TLS connection, and to make it easier to deploy. Both SSL and TLS maintain a session, which means extra CPU, traffic and interrupts. They also need certificates, which makes deployment more of a hassle, and more expensive. RTMPE just needs to be enabled, and it works. According to some, the lack of certificates makes it possible to eavesdrop on the connection. This is not entirely true however. If the connection is already established, it is no longer possible to get access to the stream. One would need to impersonate both parties at the time of the handshake, to obtain access. Even in that case, without a certificate, the parties can discover the eavesdropper.

Eavesdropping can be detected without a certificate.

 

An RTMPE connection is encrypted using RC4, a stream cipher which is also used by SSL. The keys are asymmetric, meaning the encryption keys are different from the decryption keys. The encryption key is needed by each client to encrypt the data for the other client, which only that client can decrypt. However just exchanging the public keys would be insecure, since without certificates you don't know who you are exchanging keys with. If Alice tries to exchange keys with Bob, but Eve is in the middle, Alice might be exchanging keys with Eve, and Bob as well. Then Eve can read their traffic without them knowing. Therefore keys in RTMPE are exchanged using Diffie-Hellman. With Diffie-Hellman key exchange, you exchange public keys to obtain a shared secret, only known to the party with which you do the exchange with. From this shared secret, you can then derive keys to use for the encryption. If Eve is in the middle of Alice and Bob, she will have two key pairs, one to talk with Alice and one to talk with Bob. However when Alice and Bob would compare their shared secrets, they would discover that they don't match, thus knowing that Eve is listening. They can do this over another channel (out of band) using a secure https service for example, both posting a value derived from the shared secret, like a secure hash of known data. While the API does not expose the shared secret, a shared secret derived data pair is exposed as a near and far nonce. For an audio/video call one could derive a word or code from the nonce which both parties read to each other if no extra secure channel is available. If they don’t match, they know the channel is compromised.

 

Certificates aren't as secure as once thought.

A digital certificate is a way to identify the other end of a connection. This is possible because its address is contained in the certificate, and the certificate is signed by an authority, which has a certificate signed by an authority higher in the hierarchy, forming a chain of signed certificates until a certificate is signed by a root authority. The weakness of this system is that every authority and all the people with access to the private keys need to be trusted. the year 2011 has known quite some breaches at various CA's, and early 2012 it became known that even the root authority VeriSign might have been compromised in 2010.