Eric Martindale

I often get asked for my Skype address, sometimes in relation to business or casual conversation. I politely decline with some degree of hand-waving about my reasons, and suggest an alternative form of communication (typically either Google Talk or Google Hangouts, depending on the context—both are built right in to Gmail!). I'd like to outline some of the reasons why I've made the decision to avoid Skype, primarily so I have something to link to when someone asks me about it.

First and foremost, we don't really know what Skype actually does. The binary (the actual program you run on your computer) is obfuscated, so attempts at disassembling it [PDF] to verify some of its strange behavior and the information it is transmitting have so far come up with very little. This is an issue, because Skype produces encrypted traffic even when you are not actively using Skype. This means we can only speculate on what information Skype is collecting about you after you've so graciously chosen to install it, and perhaps more importantly who it is sending that information to.

Quoting Salman Baset:

When a Skype client is not in a call and is running on a machine with public IP address, it has on the average 4-8 active TCP connections and atleast one UDP connection.

While connecting to external IP addresses is normal for a server/client architecture and necessary for receiving notifications, the volume of traffic and number of connections is concerning, considering the compounding issues between Skype's peer-to-peer architecture [PDF] and the "reasonable level of detection accuracy" in snooping on voice calls in Skype [PDF], despite the [purportedly] encrypted nature of the Skype protocol.

Speaking in general terms, Skype is "black box" software which has undergone no public review despite very concerning observed behavior. When new Skype malware (like Skype IMBot, of which an analysis is available, or the more recent Skype account hijacking) is released, there are very few options to protect ourselves if we've got Skype installed. On Linux, tools like AppArmor and TOMOYO exist, but without the ability to easily view the source and understand the attack (per perhaps even fix it proactively, before it occurs) we are at the mercy of Skype's new maintainers to provide a timely resolution in a reactive approach.

If you use a proprietary program or somebody else's web server, you're defenceless. You're putty in the hands of whoever developed that software.

In conclusion, while Skype may be convenient, it presents a series of questions that must be asked and implications to be considered before choosing it over other chat, VoIP, and video chat solutions. I can only hope that more people consider these things before doing so.

There's an interesting thought. Aliens are using perfect encryption, which might be required for a trans-planetary society, thus are hidden.

RT @martindale: There's an interesting thought. Aliens are using perfect encryption, which might be required for a trans-planetary society,…

Also, I really want to be able to view the CGM data on my Droid. I have talked to a few people (Twitter, TuDiabetes) who have attempted, but it seems like everyone who has tried has given up. I really don't think it is more difficult to crack than the AACS Encryption Key, i just don't think the same number of people are trying, or even have the access to the hardware.

After a year and a half working with some of the smartest and most competent engineers I've ever met, it's time for me to part ways with BitPay. I've had the opportunity to be deeply involved in the design, implementation, and deployment of some incredible technologies, but we're turning a page in the story of Bitcoin's rise and it's time to start exploring the new chapter. BitPay continues to paint an incredibly compelling picture as to what the decentralized future looks like – we worked on some incredibly far-reaching and massively impactful ideas, including: - [ChainDB][chaindb], a distributed database backed exclusively by the Bitcoin blockchain. - [Copay][copay], a truly decentralized wallet & identity management platform. - [BitAuth][bitauth], a secure authentication mechanism for peers on the web, using the `k1` curve. - [Impulse][impulse], a method of securing zero-confirmation transactions. - [Foxtrot][foxtrot], a completely encrypted data transmission network. - [Bitcore][bitcore], a library of common software functionality to glue everything together. You might notice a few common themes. Let me point out the two most important. Firstly, that everything here is open source (with the notable exception of ChainDB). Open source, and more importantly [free software][free software], is a very big deal to me. Prior to joining BitPay, I was [open sourcing education][coursefork], [contributing to open source software](https://github.com/martindale), and [speaking on the importance of open source](https://www.youtube.com/watch?v=iuYLWdG-lP0). Some of the things I'm most proud of are the things _other_ people built with the things _we_ gave away – _that's_ the real power of open source. Secondly, that everything here is based on Bitcoin, not some alternative blockchain. BitPay was a firm believer in Bitcoin as the exclusive platform that would secure the post-fiat era, and that belief has held strongly with me before and after my departure. Until a more compelling alternative to Bitcoin emerges, One of the other exciting things to come out of BitPay was the emergence of [DECENTRALIZE][decentralize], which we formed last fall with a few of our fellow employees. DECENTRALIZE has become [an acclaimed content source][cointelegraph:decentralize] in the latest resurgence of decentralized thinking, and now it gets to be a much bigger priority for me. Before I joined BitPay, I'd put a lot of work into [Maki][maki], a framework for making full-stack application development significantly easier. Maki took a bit of a back-burner position while I was focusing on my work at BitPay, so I'll be redoubling my efforts to see that vision through. In fact, I think now's as good a time as any to share that vision. To that end, I'm starting a new project named Fabric. I'd like to entirely eliminate centralized servers on the Internet and catalyze the development of an entirely new class of economic actor. More details soon. As we embark on our next journey, let's always remember the carefully selected input used to create [the Genesis Block][genesis]: > The Times 03/Jan/2009 Chancellor on brink of second bailout for banks [chaindb]: https://bitpay.com/chaindb.pdf [copay]: https://copay.io/ [bitauth]: https://github.com/bitpay/bitauth [impulse]: https://impulse.is/ [foxtrot]: https://github.com/bitpay/foxtrot [bitcore]: https://bitcore.io [decentralize]: https://decentralize.fm [free software]: http://www.gnu.org/philosophy/free-sw.en.html [coursefork]: https://coursefork.org/ [maki]: https://maki.ericmartindale.com/ [cointelegraph:decentralize]: http://cointelegraph.com/news/114496/leaders-in-bitcoin-broadcasting-pandoras-box-is-open-and-theres-no-going-back [genesis]: https://en.bitcoin.it/wiki/Genesis_block

I've been relying heavily on node.js this past year to provide a robust set of tools to solve the problems I encounter on a daily basis. I was pleased to see honorCipherOrder was added to node's TLS library in node.js v0.7.6, and released with node.js v0.8.0.

Late last year, security researcher Juliano Rizzo announced a new attack against the AES encryption used in the SSL/TLS transaction he dubbed BEAST. The details are interesting to those who care, but it turns out that we can mitigate this attack in node.js by enforcing honorCipherOrder on the server. Let's take a look.

If you have an HTTPS server that looks like this:

var https = require('https');
var fs = require('fs');

var options = {
  key: fs.readFileSync('key.pem'),
  cert: fs.readFileSync('cert.pem')
};

https.createServer(options, function (req, res) {
  res.writeHead(200);
  res.end("hello world\n");
}).listen(443);

...you can now manage the cipher order by using the ciphers option. In the following code snippet we're going set the options for the above server to use Steve Caligo's cipher order, which prefers TLS 1.2 ciphers (which are not vulnerable to the BEAST attack) for clients that support TLS 1.2 but falls back to the RC4 ciphers on TLS 1.0 clients.^[...]

var options = {
  key: fs.readFileSync('key.pem'),
  cert: fs.readFileSync('cert.pem'),
  ciphers: 'ECDHE-RSA-AES256-SHA:AES256-SHA:RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM'
};

Finally, we will enforce the cipher order on the server's side of the negotiation:

var options = {
  key: fs.readFileSync('key.pem'),
  cert: fs.readFileSync('cert.pem'),
  ciphers: 'ECDHE-RSA-AES256-SHA:AES256-SHA:RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM',
  honorCipherOrder: true
};

...which leaves us with the following code for a working server that is not vulnerable to the BEAST attack (in node v0.8.0+!):

var https = require('https');
var fs = require('fs');

var options = {
  key: fs.readFileSync('key.pem'),
  cert: fs.readFileSync('cert.pem'),
  ciphers: 'ECDHE-RSA-AES256-SHA:AES256-SHA:RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM',
  honorCipherOrder: true
};

https.createServer(options, function (req, res) {
  res.writeHead(200);
  res.end("hello world\n");
}).listen(443);

Edit, 6/13/2013: Lloyd Watkin has done some research on his own and decided to use a different cipher chain:

ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

You should read into why he chose it and make an educated decision. </edit>

Until node.js implements this as the defaults (they should), this is something you should implement where using HTTPS with node!