Secure communication

Fnord666 writes with this excerpt from Tech Crunch "Twitter has enabled Perfect Forward Secrecy across its mobile site, website and API feeds in order to protect against future cracking of the service's encryption. The PFS method ensures that, if the encryption key Twitter uses is cracked in the future, all of the past data transported through the network does not become an open book right away. 'If an adversary is currently recording all Twitter users' encrypted traffic, and they later crack or steal Twitter's private keys, they should not be able to use those keys to decrypt the recorded traffic,' says Twitter's Jacob Hoffman-Andrews. 'As the Electronic Frontier Foundation points out, this type of protection is increasingly important on today's Internet.'"

Of course, they are also using Elliptic Curve ciphers.

Demand for encryption apps has increased dramatically ever since the exposure of massive internet surveillance programs run by US and UK intelligence agencies. Now Facebook is reportedly moving to implement a strong, decades-old encryption technique that's been largely avoided by the online services that need it most.

Forward secrecy (sometimes called "perfect forward secrecy") is a way of encrypting internet traffic — the connection between a website and your browser — so that it's harder for a third party to intercept the pages being viewed, even if the server's key becomes compromised. It's been lauded by cryptography experts since its creation in the early 1990's, yet most "secure" online services like banks and webmail still...

Continue reading…

Sparrowvsrevolution writes "At the Fast Software Encryption conference in Singapore earlier this week, University of Illinois at Chicago Professor Dan Bernstein presented a method for breaking TLS and SSL web encryption when it's combined with the popular stream cipher RC4 invented by Ron Rivest in 1987. Bernstein demonstrated that when the same message is encrypted enough times--about a billion--comparing the ciphertext can allow the message to be deciphered. While that sounds impractical, Bernstein argued it can be achieved with a compromised website, a malicious ad or a hijacked router." RC4 may be long in the tooth, but it remains very widely used.

Read more of this story at Slashdot.

Werwin15

Researchers have devised two new attacks on the Transport Layer Security and Secure Sockets Layer protocols, the widely used encryption schemes used to secure e-commerce transactions and other sensitive traffic on the Internet.

The pair of exploits—one presented at the just-convened 20th International Workshop on Fast Software Encryption and the other scheduled to be unveiled on Thursday at the Black Hat security conference in Amsterdam—don't pose an immediate threat to the millions of people who rely on the Web-encryption standards. Still, they're part of a growing constellation of attacks with names including BEAST, CRIME, and Lucky 13 that allow determined hackers to silently decrypt protected browser cookies used to log in to websites. Together, they underscore the fragility of the aging standards as they face an arsenal of increasingly sophisticated exploits.

"It illustrates how serious this is that there are so many attacks going on involving a protocol that's been around for years and that's so widely trusted and used," Matthew Green, a professor specializing in cryptography at Johns Hopkins University, told Ars. "The fact that you now have CRIME, BEAST, Lucky 13, and these new two attacks within the same week really illustrates what a problem we're facing."

Read 14 remaining paragraphs | Comments

A representation of how TLS works.

Nadhem J. AlFardan and Kenneth G. Paterson

Software developers are racing to patch a recently discovered vulnerability that allows attackers to recover the plaintext of authentication cookies and other encrypted data as they travel over the Internet and other unsecured networks.

The discovery is significant because in many cases it makes it possible for attackers to completely subvert the protection provided by the secure sockets layer and transport layer protocols. Together, SSL, TLS, and a close TLS relative known as Datagram Transport Layer Security are the sole cryptographic means for websites to prove their authenticity and to encrypt data as it travels between end users and Web servers. The so-called "Lucky Thirteen" attacks devised by computer scientists to exploit the weaknesses work against virtually all open-source TLS implementations, and possibly implementations supported by Apple and Cisco Systems as well. (Microsoft told the researchers it has determined its software isn't susceptible.)

The attacks are extremely complex, so for the time being, average end users are probably more susceptible to attacks that use phishing e-mails or rely on fraudulently issued digital certificates to defeat the Web encryption protection. Nonetheless, the success of the cryptographers' exploits—including the full plaintext recovery of data protected by the widely used OpenSSL implementation—has clearly gotten the attention of the developers who maintain those programs. Already, the Opera browser and PolarSSL have been patched to plug the hole, and developers for OpenSSL, NSS, and CyaSSL are expected to issue updates soon.

Read 13 remaining paragraphs | Comments

Aurich Lawson

My family has been on the Internet since 1998 or so, but I didn't really think much about Internet security at first. Oh sure, I made sure our eMachines desktop (and its 433Mhz Celeron CPU) was always running the latest Internet Explorer version and I tried not to use the same password for everything. But I didn't give much thought to where my Web traffic was going or what path it took from our computer to the Web server and back. I was dimly aware that e-mail, as one of my teachers put it, was in those days "about as private as sticking your head out the window and yelling." And I didn't do much with that knowledge.

That sort of attitude was dangerous then, and the increasing sophistication of readily available hacking tools makes it even more dangerous now.  Luckily, the state of Internet security has also gotten better—in this article, the first in a five-part series covering online security, we're going to talk a bit about keeping yourself (and your business) safe on the Web. Even if you know what lurks in the dark corners of the Internet, chances are you someone you know doesn't. So consider this guide and its follow-ups as a handy crash course for those unschooled in the nuances of online security. Security aficionados should check out later entries in the series for more advanced information

We'll begin today with some basic information about encryption on the Internet and how to use it to safeguard your personal information as you use the Web, before moving on to malware, mobile app security, and other topics in future entries. 

Read 21 remaining paragraphs | Comments

Enlarge / An overview of a chosen-prefix collision. A similar technique was used by the Flame espionage malware that targeted Iran. The scientific novelty of the malware underscored the sophistication of malware sponsored by wealthy nation states.

Marc Stevens

The dance among blackhat, whitehat, and greyhat hackers grew ever more intricate in 2012, thanks to a steady stream of exploits, vulnerability discoveries, and data breaches. In-the-wild attacks against Internet Explorer, the Java software framework, and other perennial favorites continued, of course. They inflicted plenty of damage on end users, but given their familiarity, they hardly stood out.

What got our attention were attacks on entirely new classes of devices or victims, or in the case of passwords and cryptography, the culmination of new exploit techniques quickly eroding the protection we once took for granted.

From our perspective, here are the five biggest security stories this year.

Read 12 remaining paragraphs | Comments

Image: HolySkittles/Flickr.

The Electronic Frontier Foundation (EFF) has released version 3.0 of its HTTPS Everywhere browser plugin, which will automatically redirect you to secure, HTTPS connections. HTTPS Everywhere 3.0 adds support for 1,500 more websites, twice as many as previous releases.

Firefox users can install HTTPS Everywhere directly from the EFF site. There’s also an alpha release available for Google’s Chrome web browser. Unfortunately, limited add-on APIs mean that HTTPS Everywhere isn’t available for other web browsers.

Once it’s installed, the HTTPS Everywhere extension makes it easy to ensure you’re connecting to secure sites by rewriting all requests to an HTTPS URL whenever you visit one of the thousands of sites HTTPS Everywhere supports.

Why all the fuss about HTTPS? Well, every time you log in to a website through a plain HTTP connection, you expose your data to the world. It’s a bit like writing your username and password on a postcard and dropping it in the mailbox. Think of an HTTPS connection as an envelope to protect your postcard from prying eyes.

The problem gets a bit more complicated than just HTTPS though. Most sites already use HTTPS to handle your login info — that’s a good first step — but once you’re logged in sites often revert back to using an insecure HTTP connection.

So why doesn’t the entire web use HTTPS all the time? The answer is slightly complicated, but the primary reason is speed. HTTPS can’t be cached on CDN networks, which means pages may load slightly slower than they would over standard, insecure connections. For smaller sites the added costs involved with HTTPS certificates make HTTPS more expensive. However neither of those stumbling blocks have stopped Google, Facebook, Twitter, Wikipedia or the thousands of other sites large and small that now offer HTTPS connections.

The EFF is still a long way from its long term goal of encrypting the entire web, but with more sites supporting HTTPS connections every day the web is slowly but surely getting more secure.

From David Dahl's weblog: "Good news! With a lot of hard work – I want to tip my hat to Ryan Sleevi at Google – the W3C Web Crypto API First Public Working Draft has been published.
If you have an interest in cryptography or DOM APIs and especially an interest in crypto-in-the-DOM, please read the draft and forward any commentary to the comments mailing list: public-webcrypto-comments@w3.org"

This should be helpful in implementing the Cryptocat vision. Features include a secure random number generator, key generation and management primitives, and cipher primitives. The use cases section suggests multi-factor auth, protected document exchange, and secure (from the) cloud storage: "When storing data with remote service providers, users may wish to protect the confidentiality of their documents and data prior to uploading them. The Web Cryptography API allows an application to have a user select a private or secret key, to either derive encryption keys from the selected key or to directly encrypt documents using this key, and then to upload the transformed/encrypted data to the service provider using existing APIs."

Update: 09/19 00:01 GMT by U L : daviddahl commented: "I have built a working extension that provides 'window.mozCrypto', which does SHA2 hash, RSA keygen, public key crypto and RSA signature/verification, see: https://addons.mozilla.org/en-US/firefox/addon/domcrypt/ and source: https://github.com/daviddahl/domcrypt I plan on updating the extension once the Draft is more settled (after a first round of commentary & iteration)"

Read more of this story at Slashdot.

The prevalence of free, open WiFi has made it rather easy for a WiFi eavesdropper to steal your identity cookie for the websites you visit while you're connected to that WiFi access point. This is something I talked about in Breaking the Web's Cookie Jar. It's difficult to fix without making major changes to the web's infrastructure.

In the year since I wrote that, a number of major websites have "solved" the WiFi eavesdropping problem by either making encrypted HTTPS web traffic an account option or mandatory for all logged in users.

For example, I just noticed that Twitter, transparently to me and presumably all other Twitter users, switched to an encrypted web connection by default. You can tell because most modern browsers show the address bar in green when the connection is encrypted.

I initially resisted this as overkill, except for obvious targets like email (the skeleton key to all your online logins) and banking.

Yes, you can naively argue that every website should encrypt all their traffic all the time, but to me that's a "boil the sea" solution. I'd rather see a better, more secure identity protocol than ye olde HTTP cookies. I don't actually care if anyone sees the rest of my public activity on Stack Overflow; it's hardly a secret. But gee, I sure do care if they somehow sniff out my cookie and start running around doing stuff as me! Encrypting everything just to protect that one lousy cookie header seems like a whole lot of overkill to me.

Of course, there's no reason to encrypt traffic for anonymous, not-logged-in users, and Twitter doesn't. You get a plain old HTTP connection until you log in, at which point they automatically switch to HTTPS encryption. Makes sense.

It was totally painless for me, as a user, and it makes stealing my Twitter identity, or eavesdropping on my Twitter activity (as fascinating as I know that must sound), dramatically more difficult. I can't really construct a credible argument against doing this, even for something as relatively trivial as my Twitter account, and it has some definite benefits. So perhaps Twitter has the right idea here; maybe encrypted connections should be the default for all web sites. As tinfoil hat as this seemed to me a year ago, now I'm wondering if that might actually be the right thing to do for the long-term health of the overall web, too.

Why not boil the sea, then? Let us encrypt all the things!

HTTPS isn't (that) expensive any more

Yes, in the hoary old days of the 1999 web, HTTPS was quite computationally expensive. But thanks to 13 years of Moore's Law, that's no longer the case. It's still more work to set up, yes, but consider the real world case of GMail:

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

HTTPS means The Man can't spy on your Internet

Since all the traffic between you and the websites you log in to would now be encrypted, the ability of nefarious evildoers to either …

• steal your identity cookie
• peek at what you're doing
• see what you've typed
• interfere with the content you send and receive

… is, if not completely eliminated, drastically limited. Regardless of whether you're on open public WiFi or not.

Personally, I don't care too much if people see what I'm doing online since the whole point of a lot of what I do is to … let people see what I'm doing online. But I certainly don't subscribe to the dangerous idea that "only criminals have things to hide"; everyone deserves the right to personal privacy. And there are lots of repressive governments out there who wouldn't hesitate at the chance to spy on what their citizens do online, or worse. Much, much worse. Why not improve the Internet for all of them at once?

HTTPS goes faster now

Security always comes at a cost, and encrypting a web connection is no different. HTTPS is going to be inevitably slower than a regular HTTP connection. But how much slower? It used to be that encrypted content wouldn't be cached in some browsers, but that's no longer true. And Google's SPDY protocol, intended as a drop-in replacement for HTTP, even goes so far as to bake encryption in by default, and not just for better performance:

[It is a specific technical goal of SPDY to] make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.

There's also SSL False Start which requires a modern browser, but reduces the painful latency inherent in the expensive, but necessary, handshaking required to get encryption going. SSL encryption of HTTP will never be free, exactly, but it's certainly a lot faster than it used to be, and getting faster every year.

Bolting on encryption for logged-in users is by no means an easy thing to accomplish, particularly on large, established websites. You won't see me out there berating every public website for not offering encrypted connections yesterday because I know how much work it takes, and how much additional complexity it can add to an already busy team. Even though HTTPS is way easier now than it was even a few years ago, there are still plenty of tough gotchas: proxy caching, for example, becomes vastly harder when the proxies can no longer "see" what the encrypted traffic they are proxying is doing. Most sites these days are a broad mashup of content from different sources, and technically all of them need to be on HTTPS for a properly encrypted connection. Relatively underpowered and weakly connected mobile devices will pay a much steeper penalty, too.

Maybe not tomorrow, maybe not next year, but over the medium to long term, adopting encrypted web connections as a standard for logged-in users is the healthiest direction for the future of the web. We need to work toward making HTTPS easier, faster, and most of all, the default for logged in users.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.