#httpsfirst

Would you be OK with your internet bank saying "our position is
that we recommend a private connection over HTTPS but you can
always scrap that and send your private login credentials in
clear text directly in the URL instead. Over HTTP of course, if
you find that convenient. Choice is good and we want to make you
happy"?

I wouldn't, because it would tell me that they are clueless about
security or that they don't care about their user's money and/or
privacy.

Now Nexmo isn't an internet bank, they are "a cloud-based SMS API
that lets you send and receive high volume of messages at
wholesale rate". And they seem to be pretty darn good about
that. Except when it comes to security.

Check out <https://www.nexmo.com/documentation/> and perhaps
<http://nexmo.com/documentation/api/index.html>. It describes
their HTTP API for doing things like sending SMS:es, buying
inbound telephone numbers and such. These operations withdraw
money from the user's Nexmo account.

Until yesterday, these pages used insecure HTTP URL:s for all of
their examples, which is pretty bad in this copy and paste
world. Then they had a minuscule information text about security
saying "To ensure privacy we recommend you to use HTTPS for all
Nexmo API requests". And that's it.

This got me thinking and tweeting.

<https://twitter.com/olov/status/308239471814537216> Perhaps
setting and spreading a mantra would help? I propose "HTTPS
first". RT if you like it. #httpsfirst

<https://twitter.com/olov/status/308240848284438528> #httpsfirst
means that we implement HTTPS first, then HTTP only if it is
required and makes sense from a security standpoint.

<https://twitter.com/olov/status/308241410119847938> #httpsfirst
also means that we always provide examples and tutorials using
HTTPS. Then describe insecure alternatives. Never the opposite.

I pointed this out to them and soon enough most (but not all) of
their documentation pages use HTTPS instead. The security section
is still miniscule. This is a tiny improvement, but their
security is still sub-par.

Remember "makes sense from a security standpoint" from above? In
this case, it does not. HTTP makes no sense. Who of Nexmo's
paying customers wants to send out their credentials in clear
text? Who wants to get their accounts hi-jacked, their money
stolen and spam sent using their accounts?

There are reasonable ways to do this if you're in Nexmo's
situation. Either you just require HTTPS and be done with
it. That's very reasonable. Or you allow HTTP accepting that
requests are sent in the clear and thus can be eavesdropped (and
you educate your customers about that), but at least you protect
your customers against someone in the middle tampering with the
request by requiring all requests to be signed. That also means
that an eavesdropper cannot re-use customer credentials to send
extra requests using their account (because they don't have the
private keys). Check out how Amazon S3 does that for example
<http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html>.

If these two alternatives doesn't cover 100% of Nexmo's users
needs (for reasons I don't yet understand) so that plain unsigned
HTTP is desirable, then at least Nexmo should make it very clear
that the user is opting-in for something crazy. That means: 1)
all references to REST URL:s in their documentation should be
HTTPS with no exceptions, 2) there should be a security section
in their docs describing why using a secure connection is
important, 3) enabling HTTP should be an active choice
accompanied by a big ugly warning and 4) their existing customers
that already use HTTP should get an email telling them about this
and recommending them to switch to HTTPS unless they now exactly
what they are doing.

Nexmo, do you really want to be a better Twilio? Then you've got
some catching up to do <http://www.twilio.com/docs/api/rest>.