In case you missed it, Tuesday January 14 was a big day for developers of the roughly 1 million third-party applications that use Twitter’s api.twitter.com. The reason is that – in what is catch-up to Facebook and Google, who started using the SSL (Secure Socket Layer) protocol and its successor, the TLS (Transport Layer Security) protocol, for all data requests in 2011 – Twitter now requires better encryption of all communications with the Twitter API.

The move was described in a blog post by Twitter’s Luis Cipriani to the developer community roughly a month ago. Since it is relatively short, it is worth reading in its entirety if you are one of those third-parties and have not gotten the news.

This is an important notice for developers still using HTTP plaintext connections. On January 14th, 2014, connections to api.twitter.com will be restricted to TLS/SSL connections only. If your application still uses HTTP plaintext connections you will need to update it to use HTTPS connections, otherwise your app will stop functioning. You don't need to wait until deadline to implement this change, given that api.twitter.com already supports the recommended environment.

This SSL requirement will be enforced on all api.twitter.com URLs, including all steps of OAuth and all REST API resources.

Connecting to the API using the SSL protocol builds a safe communication channel between our servers and your application, meaning that no sensitive data can be accessed or tampered by unauthorized agents in the middle of this communication path.

Any well-established HTTP client library already supports the ability to connect to a SSL-enabled server and usually the required change is just a matter of updating a few lines of code or configuration files. For specific details about using SSL to connect at api.twitter.com, please review Connecting to Twitter API using SSL.

A "blackout test" will be performed on Jan 7th, 2014, when HTTP plaintext connections will be unavailable for a time period to be defined and announced in this discussion page and via the @twitterapi account.

If you have any questions or concerns with securely connecting to api.twitter.com over SSL, please post them here.

While a bit of a milestone, it is anticipated that this should not be much of a hardship for developers for the most part. Developers are extremely familiar with SSL and TSL. Plus, the encryption protocols are supported by libraries to manage SSL initialization processes in all of the major Web programming languages including Python, PHP, Ruby and others. It should also be noted that for its part, Twitter likes clients to use the RC4 (Rivest Cipher 4) algorithm for encrypting communications.

Why all of this is important is because of the sophistication of bad actors and their ability to perform their mischief when data is on the move and unprotected. Given that api.twitter.com is used as a conduit to Twitter data that can be augmented by developers, including core capabilities like user timelines and messages, protecting that traffic is a non-trivial closing of a major vector of vulnerability.  

By the way, this does not mean your Twitter account cannot be hacked. What it does mean is that, at least when developers are working their magic, they are no longer providing an opportunity for their ingenuity to be compromised.  And, it should also be noted that SSL and TSL in the view of security experts is table stakes in the area of encryption.  They urge much stronger efforts.  As recent headlines demonstrate, the pros have a well-taken point. 

It is also important to note a comment on the blog that is certainly worth consideration, and not just by Twitter. 

Going forward, as the Tweeter points out, security of data on the fly is not just about you and me sending messages, it is about creating a trustworthy interaction environment for the Internet of Things (IoT). Cipriani has yet to reply.  It will be useful to find out his thoughts on the subject.