SSL/TLS and the IoD
One thing that I've learned from examining the software components of all sorts of sites, apps, and devices over the years is that no one seems to know how to do SSL/TLS properly. IoD devices are no different it seems.
SSL/TLS underpins the security of the majority of the internet. It's the 'S' in the 'https://' when you visit a secure website. In 2017, there's very little reason not to send and receive all communications from a website or internet service over this secure channel.
The problem with SSL/TLS is that it's very complex and there are a seemingly infinite number of options. Some of these options have had security issues over the years and have been deprecated and should no longer be used. It's actually very tricky to get all the settings right and achieve the highest level of security. In addition, there may be legacy programs and code that can't support the latest and greatest SSL/TLS security settings.
On January 22nd, 2017 I decided to test the back-end servers of a number of the supporting servers that several IoD vendors apps utilise. Part of this was to get a snapshot of the state of IoD vendors usage, but also fed into an effort to alert vendors with problem SSL/TLS implementations.
I used the website SSLlabs.com which handily assigns a letter 'grade' to a site and notes any deficiencies and vulnerabilities found. Makes life easy for the researcher and creates a nice self-serve report for the vendor to test their fixes and even explains what needs to be changed to get an 'A' rating.
The best grade is an 'A+' and the worst is an 'F', with some ratings pointing to specific, but not show-stopping problems. A scan of the Internet of Dongs site with SSLlabs.com tool shows that the site has an 'A+' rating (we practice what we preach).
URL | Jan 22nd | Feb 25th | Notes |
api.imtoy.com | F | F | IMtoys has not replied to the IoD project yet |
api.missvvsmystery.com | F | A | Fixed after IoD communication of the problem |
api.ohmibod.com | A | A | Dec 20 test was F, fixed after IoD communication of the problem |
apps.lovense.com | A | A | Work in progress, some legacy code to deprecate |
api.vibease.com | A | A | Cert mismatch due to redirect, non-issue |
content.sic-apps.net | A | A | Part of We-Vibe |
im1.lovense.com | F | F | Work in progress, scheduled to be fixed within 30 days |
mm.sic-apps.net | A- | A- | Part of We-Vibe |
secure.vibease.com | A | A | |
tools.sic-apps.net | A | A | Part of We-Vibe |
vibrato-prod.herokuapp.com | A | A | For Mysteryvibe |
Several, as noted, were 'F' grade at one point or another. This was rather epidemic and at the start of the project and it has become a bit of a joke.
Since the project began in September 2016, we've reached out to many vendors. Those that have responded, we've worked to build bridges with them to reach the right people and report any issues we've found, including any SSL/TLS issues we've noted.
As you can see, on January 24th, out of 11 back end servers on this list, 4 were 'F' grade. As of February 25th, only 1 still has an 'F' grade but the vendor is well aware of the issue and a transition is already planned.
At the start of the project (Sept. 2016), there were at least 4 more on this list that were sub-'A' grade that have been corrected after we've been in touch with the vendor.
For the most part it was very easy to get these issues sorted out. It seems that just pointing out the issue was enough to get a quick response. The issues usually are simple upgrades of libraries on the server, and some small configuration changes (i.e. blacklisting algorithms with known issues). Often these can be made without any negative impact on the service or products. You just need to be aware of it and keep on top of it.
As you can see, with a site like SSLlabs, one can quickly and easily check on the status of your own SSL/TLS implementations, or as we have done, check on others. IoD product vendors need to be aware that their customers can just as easily check on the security of their products and that they will demand the best that is possible. Not having an 'A+' rating in your SSL/TLS implementation could be putting your customers data at risk, and also risking your customers trust which is costing you business.