Posted on

HTTP v. HTTPS

In 2018, you should always use HTTPS (Secure Hypertext Transmission Protocol), right? Well how come Marv Waschke on his sites allows connections using either HTTP or HTTPS? He’s the big advocate for caution on computer networks, isn’t he? So why doesn’t he do what he advocates?

First, allow me to explain what HTTP is and the difference between HTTP and HTTPS. HTTP is a set of rules for exchanging information between a client and a server that is the basis for most communication in the World Wide Web, what you see when you bring up a web browser like Chrome or Firefox.

There are many other protocols that are used on computer networks. HTTP is a very general protocol that can handle many different types of information from straight text to more complex data like sound, photographs, and video. It supports many different kinds of interactions like business transactions on Amazon or live chat. However, a simpler and less flexible protocol will often be faster and more efficient. For example, old fashioned FTP (File Transfer Protocol) will move files from one computer to another with less overhead than HTTP.

In the early and mid-nineties when HTTP was created, the designers quickly recognized that HTTP had significant security flaws. Data is exchanged in clear, unencrypted, text. Anyone with access to the network packet stream can use a packet sniffer like Wireshark to intercept a HTTP data transmission and read it. In the simplest form of HTTP, even passwords are sent in the clear.

Secondly, HTTP offers no guarantee that the sender or receiver is who they say they are. Using HTTP, you may think you are depositing funds into your bank account, but you could just as likely be sending your money to a crook on the other side of the world.

HTTPS was created to close those two gaps. I won’t go into how HTTPS works, but it encrypts data sent over the network and it uses a system of certificates to make it difficult to impersonate web sites. HTTPS is not perfect. The encryption methods used in early versions of the HTTPS standard have been broken, but they are still occasionally used by sites that haven’t kept up with the times. Not long ago, a flaw was found in software used to implement HTTPS (the Heartbleed issue). That flaw has been patched, but you never know when new flaws will be found.

In addition, the certification system is not perfect. Criminals can and do sometimes get certificates. And certificates have to be renewed periodically and not all sites are good about keeping their certificates current.

When HTTPS was first used, both computers and networks were much slower than they are today and therefore HTTPS was considerably slower than HTTP. Consequently, HTTPS was used sparingly. A site like vinemaple.net or marvinwaschke.com where no financial transactions take place and no secrets are exchanged doesn’t need security. The only benefit to using HTTPS is to assure users that they are connecting to the genuine sites, and there isn’t much incentive for anyone to put up a fake site. Since nothing is secret, encrypting doesn’t protect anything.

I currently have both sites set up to use both HTTP and HTTPS. Therefore, no one has to change their old links to my sites and those who would prefer HTTPS security assurances can use HTTPS. Eventually, I’ll phase out the HTTP access, but I’m in no hurry. I encourage you to switch to HTTPS every place you can—it’s a good habit to have. And never perform any kind of financial transaction or convey any data that could be sensitive over HTTP.

Posted on

KRACK!

The foundation of secure home wireless networks cracked this week. (I apologize for the pun. Well, No, I don’t!) KRACK is a Key Reinstallation AttaCK on WPA and WPA2 (Wireless Protected Access and Wireless Protected Access II). If you read my book, Personal Cybersecurity, you know that WPA2 is the best choice for protecting your home wireless system from intrusion. It still is, but without some timely updates, WPA2 is vulnerable to hacking.

Don’t panic

No intrusions have been reported yet, although there almost certainly will be some in coming weeks and months. The vulnerability is in the WPA and WPA2 standard. Consequently, everything that follows the standard is vulnerable. The problem is not with particular implementations. Anything that uses WPA or WPA2 correctly is vulnerable. The security of a component that uses WPA or WPA2 incorrectly is anyone’s guess, but there is a good chance it was insecure even before KRACK was discovered.

What must be patched

The Windows operating system (all versions), Linux, and Apple all are affected.  Internet of Things (IoT) gear such as wireless security cameras, smartphone controlled wireless door locks, thermostats, and light switches are also vulnerable. Practically anything wireless must be patched. Fortunately, the necessary patches have already been written for many components that need them.

Your wireless router must be patched. I read a comment in a Comcast forum that the common Xfinity Technicolor TC8305C combined cable modem and wireless router does not need patching, but I haven’t found any acceptable confirmation of that, and therefore I assume it is wishful thinking. I would appreciate a comment here from anyone who knows more.

Microsoft’s automatically delivered October security update fixed the issue for supported versions of Windows, so you are most likely already safe there. Linux distributions have patches written and it is possible your Linux installation is already safe too. I’m not as well tapped in to the Apple world, so I am not sure what the status is there, but I’m sure lights are burning late in Cupertino if they haven’t spiked it already.

The good news is that the patches are backwards compatible— that means patched components can work side by side with unpatched components without interrupting service.

The bad news

The bad news, and very bad news it is, is that a hacker can use the vulnerability to get into your wireless network from any unpatched component. The IoT is scary: Windows is easily patched automatically and is likely to be safe already, but many IoT devices have no automated patch mechanism and the device manufacturer has no means to even inform you that you are vulnerable. White label gear is especially dangerous because you have few ways to contact the manufacturer. In other words, you are on your own in the IoT.

Some reports say that Android phones are the most vulnerable. For them, you are dependent on your cellular carrier for patches to your phone. Some are more prompt than others. If you are worried, to protect yourself, turn off wireless support on your phone and only use the cellular network for network connections. When your carrier gets around to patching your device, turn wireless back on to save on data charges, if that is an issue.

Switch to wire where you can

If you have a means to switch IoT gear to a wired ethernet connection, that will render the device no longer vulnerable. Same applies to any computer or printer that you are unsure of that uses a wireless connection; turn off wireless and jack the device into your wired network if you can. If you can’t connect by wire, turn the device’s wireless service off or turn the device off entirely. You may have to turn wireless back on to download patches when they are available.

Other reasons for optimism

If you live in a low density population area, you may be less vulnerable. In order to exploit the vulnerability, a hacker must have access to your wireless signals in the air. Ordinarily, that is only within 300 feet from your wireless access point (usually your wireless router). Special antennas can extend that limit, but if strangers can’t get closer than 300 feet, you are pretty safe. The exception to that is if a hacker happens to have taken control of a computer within the 300 foot sphere that can connect to your wireless network. Still, many people in low density areas are fairly safe from intrusion.

Final advice

If you know you are in area where wireless hackers are active, turn off all unpatched wireless devices or use a wired connection. Take inventory of your IoT devices and make sure they are all secure. One way to do this is to log on to your wireless router and review the list of attached devices. Some may be turned off and only appear on the inactive list. If there is any chance that the device might connect in the future, put it on your list of devices to be secured. I estimate that you have some weeks to react, but that margin will disappear quickly. You can expect that criminals are working weekends to write cheap exploit kits for sale to script kiddies on the dark web. The kids will then drive around with laptops looking for vulnerable wireless. It has a name: “war driving.” Stay in front of them. If you have to trash some unsafe unpatchable IoT gear, do it now, swallow the loss, and take a lesson.

Even if your network is vulnerable, you are much safer using secure HTTPS connections. If you haven’t installed HTTPS Everywhere from the Electronic Frontier Foundation on your browsers, now would be a good time. Get it here.

For further technical information on KRACK, check out Brian Krebs and this post from the discoverers of the vulnerability.

Late update

A friend pointed me to this article in Ars Technica. The gist is that most Android phones are not yet patched against KRACK as of December 1, 2017, but the Android layers of security are strong enough to render the threat negligible. I will not rest easy until my Android phone is patched, but my fears are likely excessive.

Posted on

Relabel the Email Send Button “Make Public”

Email is not private. Ever.

We’ve heard a lot about email security during this election year and I am afraid people may have gotten some wrong impressions from the discussion. Most of the debate has been over the use of secure email servers. People may get the impression that using a secure email server makes the information on email private. Securing an email server makes it difficult to snoop into email stored on the server, but that is only a fragment of the picture.

Using email for critical private information is unwise under any circumstances. I fear this point is lost in the discussion. An email server is only one vulnerability in the chain of vulnerabilities from sender to receiver. You can never be certain, even reasonably sure, they are all safe.

Sending information in an email exposes the information to unauthorized access that you will not be able to control. In addition to unauthorized snooping, any email sent or received on company email is open to both the employer of the sender and the receiver. A business may be legally required to make their email public in court. An additional danger is the email message you receive may not be the message your correspondent sent to you. The sender in the email header may not be the real sender. Email was designed for convenience, not for integrity or privacy of communications.

My attitude, and that of a few other software and network architects with whom I have discussed it with recently, is to treat an email as a postcard, open to anyone who cares to snoop.

How email snooping works

To understand email security, you have to know a little about the email system architecture. There are five components: the email sending client, the receiving client, the connecting infrastructure, and the sending and receiving servers. Usually the sending and receiving clients are a single piece of software, like Outlook or Thunderbird, but the sender and receiver each has their own. In addition, unless you are sending email to someone in your own domain (the right side of the “@” in both addresses are the same) the email will go from the sender’s client to the sender’s email service to the receiver’s email service to the receiver’s client. The connecting infrastructure is usually the Internet, and it is often the most vulnerable part of the process.

As an email sender, you can protect your email client by choosing a reputable email service, managing your email account passwords carefully, and following good security practices on the devices you use for sending and receiving email, but you do not control the receiver’s elements in the chain. Steps can be taken to increase the security of email, but there is no way to tell if they have been taken at the links you do not control in the chain. In other words, no matter how careful you are, there are still many opportunities for tampering with the email you send and receive.

Email encryption

However, you can do something to protect your privacy: you can send encrypted messages that you encrypt yourself and your recipients must decrypt themselves. Independent encryption that is controlled by you and your recipient eliminates most of the issues. The problem is that you can’t send an encrypted message to just anyone because you and your recipient have to share some secret key to the encryption. This is the method behind PGP (Pretty Good Privacy) that technical types have used for a long time for email privacy. Many off-the-shelf products require less technical skill to use than PGP, but senders and recipients still have to share some secret information before communication can take place. Off the shelf products can hide the sharing and lessen the pain, but you and your correspondents will still have to agree on tools and keys before you can exchange messages privately.

Encrypted email is the only kind that I consider secure. But I also keep in mind that encryption-based systems are still fallible. What is safe today may be vulnerable tomorrow because all encryption can be broken if sufficient computing power is applied. Today, breaking the most secure encryption requires decades of computer time, but tomorrow’s computers are likely to be much more powerful. Emails that are securely encrypted today will be easy to hack in a few years.  Also, if an encryption key gets into the wrong hands, the message is no longer private. If a careless recipient saves an unencrypted copy of a message, it is no longer private. Also, a strong but poorly implemented encryption is still weak. Encryption products that ought to have been secure have turned out to be insecure through implementation errors. Always keep in mind that email places whatever you send into the hands of strangers.

Email was, like the Internet, designed for flexible and open communications. Its complex and sprawling structure changes slowly. Computer and network security in general has improved greatly in recent years, but the criminals have gotten better too.

The upshot is that secure email servers do not secure email. I, and many other software engineers and architects, regard all email as insecure. Period. Always assume that hitting the send button makes the message public.

Email is fast and convenient, but not private.