19 April 2014

IT’S TIME TO ENCRYPT THE ENTIRE INTERNET


It’s Time To Encrypt The Entire Internet

Klint Finley has an online article in this morning’s (April 17, 2014) Wired.com with the title above. Mr. Finley cites the HeartBleed bug as the latest in a line of bad cyber viruses/bugs (CryptoLocker) that demonstrate the need to “encrypt the entire Internet.” “Most major websites use either the SSL, or TSL, protocol to protect your password, or credit card information as it travels between your browser and their servers,” he writes, “but, only a few sites — like FaceBook and Gmail — actually use HTTPS to protect all their traffic, as opposed to just passwords and payment details.” “Many [cyber] security experts — including Google’s in-house search guru — Matt Cutts — think its time to bring this style of encryption to entire worldwide web. That means secure connections to everything, from your bank account — to Wired.com, to the online menu at your local pizza parlor,” he adds.

“If Cutts, who runs Google’s web spam team, had his way,” Mr. Finley writes, “Google would prioritize sites that use HTTPS over those that don’t.” Mr. Cutts has acknowledged in the past that this idea is “controversial, and faces opposition even within Google. White Hat hacker Moxie (got to love that name) Marlinspike knows as well as anyone how insecure SSL/TSL can be,” adds Mr. Finley. “A former Twitter engineer, he’s uncovered multiple critical bugs in the protocols over the course of his career; and, has proposed an alternative way of handling verification and trust. though he still believes HTTPS should be used ubiquitously.

“Most major websites use only HTTPS to protect your password when you login, or your credit-card information when you make a purchase. But, that started to change in 2010 when software developer Eric Butler released a free tool called Fire Sheep to show just how easy it was to temporarily take control of someone else’s account over a shared network — such as a public WiFi connection,” notes Mr. Finley.

“Butler agrees that more use of the HTTPS to protect your password would be a good thing, pointing out that using HTTPS makes it easier for governments or criminals to spy on what Internet users are doing online. And Micah Lee, a technologist for The Intercept, points out there are many situations in which it makes sense to use HTTPS besides just protecting passwords, or other sensitive information. For example, HTTPS doesn’t just encrypt the information passing between a server and your computer. It also verifies that the content you are downloading is coming from the people you expect it to be coming from — again in theory.

“Any sort of attacks that involve tricking the victim into connecting to the attackers server — instead of the real server, gets halted by HTTPS.,” Lee told Wired. “And, it is really important, even for non-secret content, because of integrity; you really don’t want attackers modifying the content of websites you’re visiting without your knowledge.”

“But,” as Mr. Finley asks, “if HTTPS is so great then why don’t all websites use it already?” There are several disadvantages explains Mr. Finley. including cost, increased server resource consumption which can slow down web traffic; but, Mr. Marlinslike and Mr. Butler say these costs are exaggerated.

Mr. Finley concludes, “even if the entire web isn’t ready to switch completely to HTTPS, there are plenty of reasons that more sites should start using HTTPS by default — especially sites that provide public information and software.”

And, I would add, that encryption isn’t the panacea that some think. It takes two to tango goes the old saying. Both parties (the sender and the receiver) both need to have the same software installed on their devices in order for this kind of widespread encryption to work. There is also a performance tradeoff (unless technology has substantially improved), as reading and sending encrypted email, etc. results in slower performance. And, as noted cyber security guru Bruce Schneier says, “it isn’t so much the data in transit that is at risk; but, the data at rest.” V/R, RCP

No comments: