I don't know if this is something to be concerned about or not, but I have just noticed that the access to CM and the browsing of pages within CM is not via HTTPS and therefore login details etc are presumably sent in clear text across the internet?
Also, pages displaying API Keys, list IDs and client IDs are also not sent via HTTPS which to me means it is possible for hackers to determine these and then use our API Key to send out their own newsletters from our account using the API?
Is that correct or am I missing something?
Yes it does mean you're open to Man In The Middle Attacks, which are generally pretty rare since it usually requires ISP infrastructure to be compromised. Except of course in public wi-fi areas where it's much easier to eavesdrop.
Dear Campaign Monitor,
Is there a reason the whole site is not run out of HTTPS?
To be honest, if a Man-in-the-middle attack is effective, it won't matter whether you're using HTTPS or not. And you should never use public WiFi for anything that requires a secure connection.
Ultimately Robin, I really wouldn't worry about it. If a hacker is determined to get your details it won't matter whether HTTPS is in place or not, and CM is established enough to deal with hacking attempts.
That said, an extra layer of security is never a bad thing, and I can't see why NOT to add it :)
We use https for the actual payment pages of course, but we are considering making it possible to stay within https the whole time as a future improvement.
There are performance costs to that, and there is also added complexity, so since the risks seemed very low we have prioritised other, much more highly requested, items.
Thanks for the replies.
Stormy, your quote here is of interest to me:
"To be honest, if a Man-in-the-middle attack is effective, it won't matter whether you're using HTTPS or not. "
Probably a little of topic for here, but I thought that was the whole point of HTTPS? That the info is encrypted.
Ok, as an example:
A cracker (let's be dark and forboding and call him 'Mr X') decides to launch a MITM attack on www.vulnerable.com.
First, Mr X makes a birthday attack on vulnerable.com's DNS (though I believe a lot of work has gone recently towards securing this better, most name servers out there are still quite vulnerable. This attack takes advantage of the mathematical phenomenon that in a room of 23 people, the chance of two of them sharing a birthday is greater than 1 in 2. Essentially, a brute force attack on a DNS can get a good rate of success at around 800? or so attempts out of over 65 thousand permutations).
Once successful, anyone trying to visit www.vulnerable.com is now directed instead to Mr X's MITM server.
Mr X's server has an SSL certificate, and a spoofed version of www.vulnerable.com's login page. When a user visits the site, the page looks the same and they see the nice, trusted padlock on the address bar, as it is on an HTTPS page (which, although showing https://www.vulnerable.com, is actually being served from Mr X's server).
When the user logs in, Mr X's server receives the login details and stores them.
If Mr X wanted to stay as low-profile as possible, they would have their server set to then use the details login to the actual www.vulnerable.com site, and begin passing the requests & data back and forth between the user and vulnerable.com. To the user, it would appear as though nothing was wrong (the address bar will still show vulnerable.com's address, including ssl security) and vulnerable.com would have received correct login information and user behaviour.
This is of course a little simplified, but certainly a feasible vector of attack that circumnavigates SSL's security. As noted earlier, this kind of attack is thankfully now recognised and work is being done to reduce its effectiveness, but a lot of places are still vulnerable to it.
Sorry, but the man in the middle discussion is a moot point:
Without SSL, simply sniffing traffic is enough, as the API key granting access to the whole account is transmitted in clear text. A man in the middle attack is not necessary at all, which is exactly why HTTPS is so important in this case. In fact, I don't understand why the API does allow non-encrypted traffic at all.