Slowly Moving The Web To HTTPS

The EFF has a pretty good post on the move to make HTTPS closer to the new normal on the web. It’s hardly normal yet, but it’s improving. Already some of the bigger sites on the internet like Google, Facebook and Twitter are serving up HTTPS for almost everything. They do it for security as well as performance (SPDY).

In the longer run (few years from now) I wouldn’t be surprised if the majority of web traffic starts moving over HTTPS. This will not be well accepted by many institutions including all governments, but it’s certainly better for people, especially those in nations who restrict speech and rights the most. We’ll also see a lot of legislation to only use encryption methods with known vulnerabilities and back doors. I wouldn’t even be surprised if some countries try and break the web by using alternate means of encryption similar to what South Korea did years ago. Obviously fighting this is going to prove important.

Silent Circle Finally Bringing Security To Mobile?

Silent Circle is a pretty interesting sounding app:

It’s a model for the nested cryptography of Silent Circle. The “safe room” is the iPhone processor, where all the encryption happens. By the time your text leaves the phone, it’s been completely encrypted, unrecoverable without the key. To keep the key safe, Silent Circle uses the ZRTP protocol, a dance of data drops and verifications that’s every bit as intricate as the Southern Command’s network of swipes and codes. At the end of each call, the keys are erased, so nothing can be decrypted after the fact.

This sounds like security done right. Why this is newsworthy in 2012 is what saddens me. This should be the standard, not the exception. Regardless, kudos to these folks for shedding light on what so many others are doing wrong.

iPhone Too Secure From Law Enforcement?

According to the US Department of Justice (DOJ) the iPhone is largely uncrackable at this point:

“I can tell you from the Department of Justice perspective, if that drive is encrypted, you’re done,” Ovie Carroll, director of the cyber-crime lab for the CCIPS division of the Department of Justice, said earlier this month during his presentation at DFRWS. “When conducting criminal investigations, if you pull the power on a drive that is whole-disk encrypted you have lost any chance of recovering that data.”

Of course there are a fair number of tools out there for iOS 4 and below including UFED Ultimate and XRY. There is a lack of iOS 5 tools, at least that are being publicly advertised.

However, there’s arguably little need for such a tool anymore. As users put data on in “the cloud”, law enforcement doesn’t even need the physical phone, they can just send a request to Apple (or Google) for the data they want. I suspect this is at least part of what Steve Wozniak was talking about when he mentioned “horrible problems” in the next five years. It’s worth noting Apple has almost zero transparency regarding law enforcement requests and how they are vetted. It’s not even clear a warrant is necessary to request data. The law certainly isn’t clear in that regard.

If anything, I think it’s becoming easier for law enforcement, not harder.

GPRS Cracked

I mentioned the work of Karsten Nohl to expose how insecure cell phones really are back in 2009. It’s great work since many people assume cell phones are secure, while they likely aren’t nearly as secure as one would think or hope. He’s done a lot more since then as The Register reports:

“The interception software to be released tomorrow puts GPRS operators with no encryption at an immediate risk,” he told The Register on Tuesday evening. “All other GPRS networks are affected by the cryptanalysis that will be presented but not released at tomorrow’s conference. Those operators will hopefully implement stronger encryption in the time it takes others to re-implement our attacks.”

As the article goes on to say, most use none or weak encryption.

In 2010, he bundled many of the various tools he helped develop into a comprehensive piece of software that gave amateurs the means to carry out many of the attacks. That same year, other cryptographers cracked the encryption scheme protecting 3G phone calls before the so-called Kasumi cipher had even gone into commercial use.

So your best bet to make a secure call right now is to use Skype on a smart phone. So far it doesn’t seem anyone has cracked Skype’s security. If Skype has a backdoor or known vulnerabilities is questionable. If they were considered a phone company (they insist they aren’t) they would be subject to CALEA.

Bottom line: Don’t assume a cell phone call is secure.

Wanted: Native JS Encryption

I’d like to challenge all browser vendors to put together a comprehensive JS API for encryption. I’ll use this blog post to prove why it’s necessary and would be a great move to do so.

The Ultimate Security Model

I consider Mozilla Sync (formerly known as “Weave”) to have the ultimate security model. As a brief background, Mozilla Sync is a service that synchronizes your bookmarks, browsing history, etc. between computers using “the cloud”. Obviously this has privacy implications. The solution basically works as follows:

  1. Your data is created on your computer (obviously).
  2. Your data is encrypted on your computer.
  3. Your data is transmitted securely to servers in an encrypted state.
  4. Your data is retrieved and decrypted on your computer.

The only one who can ever decrypt your data is you. It’s the ultimate security model. The data on the server is encrypted and the server has no way to decrypt it. A typical web service works like this:

  1. Your data is created on your computer.
  2. Your data is transmitted securely to servers.
  3. Your data is transmitted securely back to you.

The whole time it’s on the remote servers, it could in theory be retrieved by criminals, nosy sysadmins, governments, etc. There are times when you want a server to read your data to do something useful, but there are times where it shouldn’t.

The Rise Of Cloud Data And HTML5

It’s no secret that more people are moving more of their data in to what sales people call “the cloud” (Gmail, Dropbox, Remember The Milk, etc). More and more of people’s data is out there in this maze of computers. I don’t need to dwell too much about the issues raised by personal data being stored in places where 4th amendment rights aren’t exactly clear in the US and may not exist in other locales. It’s been written about enough in the industry.

Additionally newer features like Web Storage allow for 5-10 MB of storage on the client side for data, often used for “offline” versions of a site. This is really handy but makes any computer or cell phone used a potentially treasure trove of data if that’s not correctly purged or protected. I expect that 5-10 MB barrier to rise over time just like disk cache. Even my cell phone can likely afford more than 5-10 MB. My digital camera can hold 16 GB in a card a little larger than my fingernail. Local storage is already pretty cheap these days, and will likely only get cheaper.

Mobile phones are hardly immune from all this as they feature increasingly robust browsers capable of all sorts of HTML5 magic. The rise of mobile “apps” is powered largely by the offline abilities and storage functionality. Web Storage facilitates this in many ways but doesn’t provide any inherent security.

Again, I don’t need to dwell here, but people are leaving increasingly sensitive data on devices they use, and services they use. SSL protects them while data is moving over the wire, but does nothing for them once data gets to either end. The time spent over the wire is measured in milliseconds, the time spent at either end can be measured in years.

Enter JS Crypto

My proposal is that there’s a need for native JS Cryptography implementing several popular algorithms like AES, Serpent, Twofish, MD5 (I know it’s busted, but still could be handy for legacy reasons), SHA-256 and expanding as cryptography matures. By doing so, the front end logic can easily and quickly encrypt data before storing or sending.

For example to protect Web Storage before actually saving to globalStorage:

globalStorage[‘mybank.com’].lastBalance = "0.50";
globalStorage[‘mybank.com’].lastBalance = Crypto.AES.encrypt("0.50", password);

Using xmlHttpRequest or POST/GET one could send encrypted payloads directly to the server over http or https rather than send raw data to the server. This greatly facilitates the Mozilla Sync model of data security.

This can also be an interesting way to transmit select data in a secure manner while serving the rest of a site over http using xmlHttpRequest by just wrapping the data in crypto (that assumes a shared key).

I’m sure there are other uses that I haven’t even thought of.

Performance

JS libraries like Crypto-JS are pretty cool, but they aren’t ideal. We need something as fast and powerful as we can get. Like I said earlier, mobile is a big deal here and mobile has performance and power issues. Intel and AMD now have AES Native Instructions (AES NI) for their desktop chips. I suspect mobile chips who don’t have this will eventually do so. I don’t think any amount of JS optimization will get that far performance wise. We’re talking 5-10 MB of client side data today, and that will only grow. We’re not even talking about encrypting data before remote storage (which in theory can break the 10MB limit).

Furthermore, most browsers already have a Swiss Army knife of crypto support already, just not exposed via JS in a nice friendly API. I don’t think any are currently using AES NI when available, though that’s a pretty new feature and I’m sure in time someone will investigate that.

Providing a cryptography API would be a great way to encourage websites to up the security model in an HTML5 world.

Wait a second…

Shouldn’t browsers just encrypt Web Storage, or let OS vendors turn on Full Disk Encryption (FDE)?

Sure, both are great, but web apps should be in control of their own security model regardless of what the terminal is doing. Even if they are encrypted, that doesn’t provide a great security model if the browser has one security model in place for Web Storage and the site has its own authentication system.

Don’t JS Libraries already exist, and isn’t JS getting the point of almost being native?

True, libraries do exist, and JS is getting amazingly fast to the point of threatening native code. However crypto is now being hardware accelerated. It’s also something that can be grossly simplified by getting rid of libraries. I view JS crypto libraries the way I view ExplorerCanvas. Great, but I’d prefer a native implementation for its performance. These libraries do still have a place bridging support for browsers that don’t have native support in the form of a shim.

But if data is encrypted before sending to a server, the server can’t do anything with it

That’s the point! This isn’t ideal in all cases for example you can’t encrypt photos you intend to share on Facebook or Flickr, but a DropBox like service may be an ideal candidate for encryption.

What about export laws?

What about them? Browsers have been shipping cryptography for years. This is just exposing cryptography so web developers can better take advantage and secure user data. If anything JS crypto implementations likely create a bigger legal issue regarding “exporting” cryptography for web developers.

Your crazy!

Perhaps. To quote Apple’s Think Different Campaign

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes.

The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them.

About the only thing you can’t do is ignore them. Because they change things. They invent. They imagine. They heal. They explore. They create. They inspire. They push the human race forward.

Maybe they have to be crazy.

How else can you stare at an empty canvas and see a work of art? Or sit in silence and hear a song that’s never been written? Or gaze at a red planet and see a laboratory on wheels?

While some see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.

Time to enable the crazy ones to do things in a more secure way.

Updated: Changed key to password to better reflect likely implementation in the psudocode.

Decrypting The Internet

Bruce Schneier on the new wiretapping proposal:

Any surveillance system invites both criminal appropriation and government abuse. Function creep is the most obvious abuse: New police powers, enacted to fight terrorism, are already used in situations of conventional nonterrorist crime. Internet surveillance and control will be no different.

Official misuses are bad enough, but the unofficial uses are far more worrisome. An infrastructure conducive to surveillance and control invites surveillance and control, both by the people you expect and the people you don’t. Any surveillance and control system must itself be secured, and we’re not very good at that. Why does anyone think that only authorized law enforcement will mine collected internet data or eavesdrop on Skype and IM conversations?

I 100% agree here. A security vulnerability, intentional or not is a vulnerability. Even systems with no known security holes are eventually broken. Look at the recent reverse engineering of HDCP, which was theorized as vulnerable in 2001 but not broken for several years, a pretty good run. Eventually all security mechanisms will be broken. Starting with something broken just increases the window of opportunity for abuse and misuse.

In theory this proposal could (I’m no lawyer, I don’t even play one on TV) even impact things like Firefox Sync (Formerly Weave) which employs the best security mechanism I’ve seen in a service. To summarize, it works by encrypting your data before transmission to the server. However the key is never sent. That means even if the Gestapo took the servers with your data, they would still need to get the key from you, or do battle with the encryption which isn’t easy. Even Mozilla can’t read your data, unless a flaw were found in the encryption algorithm. The question is if sync were considered to fall under “services that enable communications”. That seems broad enough to leave room to argue that sync facilitates communication since the browser is the ultimate communication client. The browser is also valuable since it potentially has passwords, bookmarks, and history giving a good motivator to make that argument. Argue that to a 75-year-old judge who never used a computer and it might work.

Meanwhile just weeks ago UAE ironically gets criticized by the US for proposing a Blackberry ban for the same reasons.

The Future Of SSL

Google announced the other day that it will now enable HTTPS by default on Gmail. Previously a user had to either manually type in HTTPS or change a setting to default to it, something most people likely never bothered to do. Google says it’s not related but it seems oddly coincidental that this chance coincides with its China announcement.

However Gmail using HTTPS is not the big story here.

The big story is that HTTPS is now being used in places where it before was considered excessive. Once upon only financial information was generally sent over HTTPS. As time went on, so did most website login pages, though the rest of the sites often were unencrypted. The reason for being so selective is that it’s more costly to scale HTTPS due to it’s CPU usage on the server-side, and it’s performance on the client side. These days CPU is becoming very cheap.

In the next few years I think we’ll see more and more of the web switch to using HTTPS. If things like network neutrality don’t work this trend could accelerate at an even quicker rate just like it did for P2P using MSE/PE to mask traffic.

Like I said, these days the CPU impact is pretty affordable, however the performance impact due to HTTP handshaking can be pretty substantial. Minimizing HTTP requests obviously helps. HTTP Keepalive is a good solution however that generally results in more child processes on the server as they aren’t freed as quickly (read: more memory needed).

Mobile is a whole different ballgame since CPU is still more limited. I’m not aware of any mobile devices that have hardware to specifically handle SSL, which does exist for servers. Add in the extra latency and mobile really suffers. Perhaps it’s time to re-examine how various Crypto libraries are optimized for running on ARM hardware? I think the day will come where performance over SSL will matter as it becomes more ubiquitous.

Security Through Obscurity TSA/GSM Edition

It’s impossible to write code these days without having to study security to some extent. The byproduct of this is that since digital security concepts are based largely on real life, you see the obvious gaps in real life “security”. The quotes are intentional because many/most attempts only provide the feeling of security as opposed to real security.

“Security through obscurity” is perhaps one of the most insane of ideas. The principle being that if the implementation is kept secret the entire application is secure (emphasis on if). If it’s compromised, then you’re in trouble.

TSA “Security”

Books have been written about how poor the TSA is at security. Bruce Schneier is likely one of the best when it comes to pointing out the silly practices and how little it actually does for actual security.

The latest security directive was sent to thousands of individuals at airlines around the world. Needless to say it was leaked (imagine that). Of course the TSA wasn’t thrilled about that. What this does show is that the TSA is simply hoping any potential terrorist is too dumb to do something original. See Bruce Schneier’s piece linked above which draws the same conclusion.

The fake boarding pass scheme is another great example.

Millimeter wave scanner’s (those fully body scanners) haven’t even been 100% implemented yet and have been defeated. Al Qaeda has already figured out that they could mimic drug smugglers and place bombs in certain body cavities. A CT scan would detect that but a full body CT scan is too much radiation and too slow for routine use. No sane person would use a CT scan for security. You would certainly kill more than you would save. That means a complementary prostate exam or “bend and spread” (limited success in prison) is pretty much the only solution. Of course surgical implantation would defeat that as well.

Edit 1/1/2010 @ 3:00 PM EST: The TSA has apparently realized how pointless their legal efforts were and have withdrawn its subpoena.

GSMA “Security”

GSMA (GSM Association) are the folks behind GSM A5/1 encryption used in the majority of phones worldwide which is supposed to keep your calls secure and safe from prying ears. Karsten Nohl figured out how it can be broken. It’s noteworthy that this is an 18-year-old standard from days when computing power was much more limited. It’s also noteworthy that most governments and criminals have likely figured this stuff out already (they just aren’t sharing). The GSMA response:

“What he is doing would be illegal in Britain and the United States. To do this while supposedly being concerned about privacy is beyond me.”

Mike Masnick at TechDirt decoded the PR speak decoded:

… First, claiming it’s “theoretically possible, but practically unlikely” means that it’s very, very possible and quite likely. To then say that no one else had broken the code since its adoption fifteen years ago is almost certainly false. What she means is that no one else who’s broken the code has gone public with it — probably because it’s much more lucrative keeping that info to themselves…

Wikipedia has a rundown of the security of A5/1.

Unobstructed HTTPS

There’s an interesting discussion on Slashdot about SSL certificates. It brings up two valid points:

  1. Invalid certificates, while providing a secure mechanism between the client/server are extremely annoying to use in Firefox 3 for many people because of the multi-step process. Previously it was just a warning dialog.
  2. There are no free SSL certificates that are really “usable” (not throwing up warnings in a many browsers). CAcert.org has likely gotten the most inclusion, but it’s barely anywhere.

Certificates not signed by a trusted certificate authority (CA) give up a warning because of the idea that a certificate authority verifies the certificate belongs to the person whose name is on the certificate. This concept was busted a while back as CA’s started doing “domain validation” to offer lower prices. To “remedy” this, they created EV SSL. EV SSL requires more background checking, but at a higher cost. This means there are three tiers of SSL:

  1. Untrusted/Self Signed – Free – The user is strongly discouraged from visiting a site with one of these. Indicates the technologically the channel is secure only.
  2. Signed By CA – Variable Pricing – The user is told this is secure.
  3. EV SSL – Expensive – The user is told these sites are super awesomely amazing and can cure cancer.

Essentially EV SSL is nothing more than a scheme to charge more. EV SSL is supposed to do what a signed certificate should have been doing all along. By 2012 I’d bet there will be a SEV SSL(Super Extended Validation Certificate). Maybe that would require a DNA and fingerprints to prove identity.

The Problem

It’s 2008 (actually more than half way through it). I still can’t use a secure https connection without either throwing up an error to users (who are always confused by it), or paying a fee? It seems right to me it should be free to use https without any barrier for a technical level of security.

Why is “trust” bound so tightly to encryption? Why can’t a medium be encrypted without being trusted? The technology shouldn’t be tied the way it is to the business side of things.

Trust should be bound to encryption, but encryption should not be bound to trust. Trust is the “needy” individual in this relationship. Encryption is strong and confident. At least it should be…

A modest proposal

I propose that browsers should allow for self signed certificates to be used without any dialog, interstitial or other obstruction provided they are properly formed and not expired. The user interface should indicate that the channel is encrypted and communication is unlikely to be intercepted between the user and the server. It should note if there is any change (just like SSH notifies the user if the signature is changed between sessions). Other than that it should be transparent.

SSL certificates and EV SSL certificates should indicate in the user interface the the site being browsed is not only encrypted, but trusted by a third party the browser trusts. These are suitable for ecommerce, banking etc.

This would allow for things like intranets and other places where encryption is desired, paying for a CA to verify identity is overkill, and “domain verification” is just pointless.

Trust should be bound to encryption. Encryption shouldn’t be bound to trust. Encryption shouldn’t require verification. Encryption should be self-serve.

I’d be curious to know what others thought of the issue.