Streaming API Security

At Initial State, we take security very seriously. We're constantly re-evaluating current trends and vulnerabilities in the mechanisms available to insure the confidentiality and integrity of the data you and your devices send to us.

How does Initial State protect confidentiality and integrity sending data over the Internet?

We exclusively support TLS v1.0 and TLS v1.1 and higher. If you're performing any secured HTTPS connection to an Initial State API, you can assure that we do not allow the client to downgrade the protocol in the handshake to a lower version like SSLv1, SSLv2, or SSLv3.

Do you support SSL? And what's the difference between SSL and TLS?

In order to secure communications from client devices to Initial State's APIs, we utilize TLS (Transport Layer Security). TLS is the newer, more secure evolution of the SSL (Secure Socket Layer) protocol. SSLv3 has been around for nearly 18 years and therefore is widely supported by many legacy clients. Because of this, many servers will build support for SSLv3 in order to accommodate as many clients as possible. However, SSLv3 was discovered to have a severe vulnerability that compromised it's confidentiality by some Google engineers back in 2014 in an attack they nicknamed POODLE. Because of this, security researchers recommended the immediate discontinuation of support and use of SSLv3. As of 2015, most major internet services discontinued their support and offering of SSLv3. Initial State discontinued support for SSLv3 as soon as POODLE was announced.

Why should I not use SSL, specifically SSLv3?

Disable SSLv3 is a website provides some great resources to answer that question.

What can I do if my device has only implemented SSL and not TLS and I don't have the ability to implement support for TLS?

We recognize that some lower powered or under-supported devices and libraries may simply not have the ability to perform - at minimum - TLS v1.0 yet. As such, we've created an alternative endpoint *only* for streaming data to Initial State at This alternate endpoint allows users in this situation who also do not have a confidentiality requirement or have accepted the great risk of no-confidentiality to still stream data to our service. However, as soon as it's hit our first piece of networking equipment, it's kept safe and secure from then on. There are no APIs whatsoever for accessing data over a connection that is not a minimum of TLS v1.0. We call the endpoint insecure because we want to ensure that everyone who uses it understand's that data sent to that endpoint over the Internet is sent in plaintext.

Wouldn't SSLv3 be better than nothing?

This is a great question. And common sense would make you think the answer is yes. However, in our expert security opinion, broken security is the worst kind of vulnerability. A false sense of confidentiality and integrity potentially cause blind risk acceptance. So, since SSLv3, much less SSL in general, is no longer a valid way to secure communications over the Internet, it should be considered as confidential and a plaintext alternative.

Feedback and Knowledge Base