Cryptography: the foundation of e-commerce

Money is the very definition of motivation for many criminals. At least in the movies... In real life, there are plenty of criminals looking for ways to drain money out of bank accounts, buy stuff on other people's credit cards, intercept bank transfers, and more.

There's a whole new generation of crypto-currencies that use encryption in ingenious ways to securely transfer money from one person to another. Remember Bitcoin? It's still around, and the reason Silicon Valley was so infatuated with it is that it uses some really advanced math along with a public record to make it nearly impossible to steal money in transit. A Bitcoin transaction basically uses a public ledger, called the "Blockchain", to transfer value from one wallet directly to another, and do it in a way that it cannot be spoofed, reversed, intercepted, or hijacked. It doesn't prevent somebody from stealing your wallet if you're not careful, or prevent you from transferring that money on to somebody else -- but because it's all essentially public record, nobody simply observing the transaction can steal it.

However, that's not the case with a credit card. If you intercept a credit card number, you can buy stuff with it.

This has led to a huge infrastructure built around protecting credit card numbers, building a lot of anti-fraud protection measures (like validating your address, zip code, and CVV code), and protection of customers so that they aren't afraid to use their cards online. This protection is paid for by the merchants themselves -- if you have an online store and a customer complains about a charge from you, the card companies will pull the money paid straight back out of your checking account and refund the customer.

But what is encryption, really? And how does this affect regular people?

The best metaphor for encryption is simply an envelope. It's a container you put stuff inside, and its goal is to protect its contents from anyone other than the intended recipient, or in some cases, a group of intended recipients. That's really the main thing to does -- but there is one other, critically important feature of how most public key encryption works -- it can be used as a digital signature, proof that it was you who sent it. Generally on the web, this is done through the use of certificates, but the crypto-currencies use a shared "blockchain" for this.

Let's take a quick look at a few encryption concepts, and put this in perspective:

• Site-to-site encryption, e.g. SSL/TLS
• End-to-end encryption, aka E2E, E2EE
• Disk encryption
• Types of certificate authorities

No encryption - Sending postcards through the underworld

The "message" is a two way conversation. Your browser requests a certain resource, or page, and the server returns the HTML for that resource. If there's a form involved, your browser sends over the form contents, in plain text, and the server does something with that data and returns a result of some kind.

If the connection, or "transport," is not encrypted, then these messages can potentially be read by anyone on any network that the message traverses on its way from you to the server.

A web connection may easily involve 15 - 25 "hops" between your browser and the web server -- each hop is another computer which might have some sort of spy software grabbing all that traffic and diverting it somewhere for malicious eyes to see.

So with no encryption, this is like sending postcards back and forth, but in a country where you don't trust the post office. Who is delivering the mail? Is it the mob? Is it somebody looking for a kidnapping target? Is it the government, or a large corporation who wants to sell you something?

Site-to-site encryption - Put your postcards in a mailbag

SSL is the commonly used name for connections that your browser establishes that show a padlock icon indicating a secure connection. SSL is really an obsolete acronym, "Secure Sockets Layer" -- the current name used in the industry is TLS -- "Transport Layer Security." In either case, it's a secure connection between your computer and the web site or server you're connecting to.

When you use a TLS connection, you can be sure that none of those middle "hops" along the way can read the messages going either way. It's like putting your postcards in a secure mailbox, and sending those to the server. It then puts its response back in the mailbox, and sends it back to you. The hops in the middle can see that you're sending a message from you to the remote server, but they can no longer see what the message is.

However, it is possible for there to be a server that decrypts your messages, reads them, and then re-encrypts them and forwards along to the final end. This is called a "Man in the Middle."

TLS protects against man-in-the-middle attacks by using the other property of encryption -- digital signatures -- to prove that a message was encrypted by the actual server at the other end, and not decrypted/re-encrypted by somebody in the middle. And your browser "trusts" a certain number of "certificate authorities" who in turn sign the website's certificate, so your browser can have confidence that the server you connected to is indeed the one that matches the domain name you're on.

End-to-end encryption - Don't trust the post office

There's a whole new generation of messaging apps. If you've been reading our blog, you'll know we're huge fans of Riot, which now has full end-to-end encryption in beta. Signal is perhaps the most used, most respected encrypted messaging service in this realm. And these are among the systems that governments around the world are trying to ban.

To understand E2E, we need to take our postcard metaphor a bit further, and compare it to email. With email, you don't connect from your mail program directly to your friend's computer. You connect to your mail server -- the local post office -- with a postcard that you want to send to your friend. The post office looks up the post office for your friend, and sends the postcard along to that post office -- perhaps in a mail bag, perhaps just loose where everyone in the mail room and airplane could read it. Finally, your friend picks up the postcard from their post office.

That's regular email. Would you put your credit card number on a post card, take it down to a private mail facility and hand it over with no assurance that people wouldn't read it along the way? I certainly wouldn't -- but that's essentially how secure regular email is.

End-to-end encryption is putting that postcard in a tamper-proof envelope that only your friend can open.

This is perhaps the most "dangerous" use of encryption -- it allows terrorists and criminals to communicate beyond the reach of law enforcement. But it also allows for secure transmission of credit cards, medical information, attorney/client secrets, and more.

Disk encryption - Protect your secrets even if you lose your phone

This is the encryption the FBI wanted to get Apple to bypass. With disk encryption, all the data on your phone or laptop becomes completely indecipherable unless/until you unlock it with the key.

Most operating systems now let you choose this as an option when you install them, and many cloud providers do as well. This type of encryption protects against physical theft of your device -- without the key, data on the drive becomes unrecoverable. So then the question becomes, how do you protect the key? On recent IOS devices, the key is generated from a unique, unreadable device key combined with your passphrase. On Amazon, keys are stored/managed through a key server. On many disk encryption systems, a long passphrase is itself used as the encryption key... but usually strong encryption combines a hardware or software key with a passphrase and/or biometrics.

Certificate authorities -- who can you trust?

Site-to-site encryption generally relies upon "trusted third parties" to vouch that the server you're talking to is who they say they are. There are a few dozen of these built into your web browser and operating system. When you visit an SSL-encrypted website, the site sends your browser its certificate. Your browser verifies that the certificate was signed by a "Certificate Authority" it trusts, that it matches the domain name it's on, that the date range is valid, and that it's not present in a revocation list.

Assuming all of that is correct, then your browser negotiates the actual encrypted connection with the website and you start getting the encrypted traffic.

There are different levels of certificate authorities, and when you start working with other systems, entirely different schemes for validating whether the person on the other end of your connection is who you think it is.

Type of validation System How it works Self Disk, files This is mainly a matter of securing keys -- if you're not sharing encrypted data with others, you don't need an authority Domain Validation Web browser Certificate authority verifies that it can control content on the domain Organization Validation Web browser Certificate authority sends an email and checks public records to validate that an organization owns a domain Extended Validation Web browser Certificate authority checks business registrations/other external records to validate ownership of a domain. Browsers show the organization name in a green bar in the lock section. Device/key verification Riot/Matrix, PGP You validate a certificate thumbprint with the person you're talking with, using a different communications platform -- phone, in person, etc Perspectives Matrix, Firefox extension Compare certificate fingerprints with large networks of peer servers, and if it matches the majority, trusts

What now?

If you have a website, there's a huge push on the part of Google, the Electronic Freedom Foundation (EFF), and many others to make all sites encrypted. This is site-to-site encryption, and you're going to start to notice sites that are not encrypted as browsers make it more and more obvious.

The good news is that the cost of a signed certificate has dropped to pretty much nothing! The EFF has provided a trusted Certificate Authority, called "LetsEncrypt," and has built out a system to automatically generate and renew SSL certificates that browsers trust today. A separate initiative has happened between the Comodo certificate authority and the Cpanel project, which should lead to easy-to-obtain, free certificates for many shared hosts.

We have already rolled out LetsEncrypt to all of our hosting servers, as well as to customer servers on our maintenance plan. We have also enabled SSL on all of our maintenance customer sites -- try visiting your website using https, and see if you're set!

With the advent of low/no-cost certificates, we're struggling to see why anybody needs to buy any certificate other than the "Extended Validation" certificates that puts your organization name in green next to the lock. Encryption is becoming ubiquitous, now, and it's easier and cheaper than ever.

There is often additional work involved making your site fully operational under SSL. This is usually due to scripts, images, or other resources embedded on pages but not loaded using SSL. If you need help making your site fully encrypted, with no warnings, please reach out!