Cloud Broadcasting - Integration and Security - SSL Certificates

In the last article on Cloud Broadcasting we looked at integration and how we communicate with SaaS and cloud services in the absence of GPI’s and serial connections. In this article, we introduce secure server access and issues around security.

One of the major benefits of SaaS and cloud services is that they can be communicated with anywhere in the world. The great disadvantage being that they are open to the internet which means anybody with a bit of basic information can access the web servers.

Browsers use session ID’s to authenticate users giving them a level of access defined by their role. But both browsers and API’s suffer from the same problem; the communications between the browser and server, or API and server is achieved using the text based protocol HTTP (Hyper Text Transfer Protocol). Anybody with a network analysis tool, such as Wireshark, can easily intercept the packets and read the commands being sent to the web server.

Private networks are relatively secure as network engineers have absolute control over access and security. WiFi access makes packet sniffing easier and connecting to the internet, without security is akin to giving your car keys to a thief.

Malicious Intercept

HTTPS (Hyper Text Transfer Protocol Secure) is used as the first level of defense. Using SSL certificates to authenticate sites and encrypt messages, HTTPS creates a secure channel over an insecure network, resulting in protection from eavesdroppers and man-in-the-middle attacks.

Man-in-the-middle attacks occur when a third party maliciously intercepts a connection between two computers and makes each think they are the other. The purpose being to extract data that could be used against the server or computer owner, for example user credentials and bank details can be obtained and used fraudulently. 

Diagram 1 - Man-in-the-middle attacks can be devastating for Post Production houses as they have the potential to upload commercially sensitive media to imposter servers when not using SSL certificates.

Diagram 1 - Man-in-the-middle attacks can be devastating for Post Production houses as they have the potential to upload commercially sensitive media to imposter servers when not using SSL certificates.

Post Production houses sending block buster films or commercially sensitive media to servers should be aware of Man-in-the-middle attacks, they can be easily used to intercept the media and obtain it for illegal distribution, or even hold the owner to ransom.

For a user to securely upload media to a video server they should first make sure the site hosting the upload facility is SSL enabled, this is easily verified as the web address will start with HTTPS and not just HTTP. Once a user enters the upload-servers’ URL into the address bar, the SSL handshake is initiated and the server will respond by sending an SSL certificate back to the browser.

Validate Servers

Certificate Authorities, such as GoDaddy.com and GlobalSigh.com govern the publication and validity of SSL certificates. Owners of HTTPS enabled servers must apply to one of the CA’s for an SSL certificate. The application will require information such as the servers IP address, the servers public key, and details of the company. Similar to those banks request when opening an account. Once a certificate has been created it is processed with a hash-function to give it a unique finger print to make it tamper proof and sent to the business owners for installation on their server.

The CA is validating the upload server as a bona fide computer associated with the owners’ business. Clients uploading their media can be confident and assured that they are dealing with the business they expect to be dealing with and not a third-party imposter, or man-in-the-middle attacker.

Public Key Infrastructure

When a browser receives the encrypted SSL certificate it looks for the public key to decrypt it from a list of trusted keys installed in the browser. Once the public key has been found the SSL certificate is decrypted to expose the servers own public key and other company information. Maintaining the validity of this list of trusted CA’s is paramount for security in internet commerce.

The second important aspect of data exchange using HTTPS is encryption using secure keys. Public Key Infrastructure (PKI) is a system used to create, manage, store and distribute digital certificates and public keys. 

Asymmetric encryption uses a unique private-public key pair. If data is encrypted with the public key, only the private key can decrypt it. And if data is encrypted with the private key, only the public key can be used to decrypt it. The private key must remain private to the upload server, but the public key can be given to anybody. This method is as secure as it gets (assuming the private key is not stolen from the server). But it is computationally intensive and your upload-server would grind to a halt if you were to upload a film using it.

Symmetric encryption uses the same key to both encrypt and decrypt data, requiring both the users’ browser and server to have the same key. It’s a computationally fast method of encryption and decryption, but distributing the key on a public internet is very insecure and eaves droppers can easily pick it up, and then get access to your data.

Diagram 2 – HTTPS and SSL certification guarantees validated servers and encrypted media files to stop man-in-the-middle-attacks.

Diagram 2 – HTTPS and SSL certification guarantees validated servers and encrypted media files to stop man-in-the-middle-attacks.

HTTPS uses both asymmetric and symmetric encryption. After the user clicks on the servers’ URL, the encrypted SSL certificate is sent to the browser over an unencrypted link to validate the server and extract the upload-servers public key, then the browsers symmetrical key is encrypted using the public key and sent to the server, the server decrypts the symmetric key using its private key and both the server and browser switch to symmetric encryption to exchange media files using this newly created symmetric key.

Best of Both Worlds

We now have the best of both worlds, asymmetric encryption is highly secure but slow and is used for the initial server validation and exchange of symmetric keys. And symmetric encryption is less secure but much faster and is used to encrypt the media file as its uploaded to the server. Any third party sniffing the IP packets would not be able to decrypt them as they do not have the servers private key.

Use SSL Certification Now

To improve the security of symmetric key systems a time limit is enforced to create new keys to reduce the risk of them being hacked. Each time a user accesses the HTTPS server, a new HTTPS session is negotiated and a new symmetric key created. And timeout’s periodically force the browser to re-negotiate the HTTPS protocol with the server to force the creation of new symmetric keys.

Exchanging commercially sensitive media files carries great risk for the sender.  HTTPS and SSL certificates go a long way to improve security and give the user reassurance that the server they are uploading to is the company they expect, and not a malicious hacker.

You might also like...

Designing IP Broadcast Systems - The Book

Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…

Demands On Production With HDR & WCG

The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.

If It Ain’t Broke Still Fix It: Part 2 - Security

The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.

Standards: Part 21 - The MPEG, AES & Other Containers

Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.

NDI For Broadcast: Part 3 – Bridging The Gap

This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…