Archive for the ‘Security’ Category

File Under: Browsers, Security
Feb
7
2012

Google to Strip Chrome of SSL Revocation Checking

By

Google’s Chrome browser will stop relying on a decades-old method for ensuring secure sockets layer certificates are valid after one of the company’s top engineers compared it to seat belts that break when they are needed most.

The browser will stop querying CRL, or certificate revocation lists, and databases that rely on OCSP, or online certificate status protocol, Google researcher Adam Langley said in a blog post published on Sunday. He said the services, which browsers are supposed to query before trusting a credential for an SSL-protected address, don’t make end users safer because Chrome and most other browsers establish the connection even when the services aren’t able to ensure a certificate hasn’t been tampered with.

“So soft-fail revocation checks are like a seat-belt that snaps when you crash,” Langley wrote. “Even though it works 99% of the time, it’s worthless because it only works when you don’t need it.”

SSL critics have long complained that the revocation checks are mostly useless. Attackers who have the ability to spoof the websites and certificates of Gmail and other trusted websites typically have the ability to replace warnings that the credential is no longer valid with a response that says the server is temporarily down. Indeed, Moxie Marlinspike’s SSL Strip hacking tool automatically supplies such messages, effectively bypassing the measure.

“While the benefits of online revocation checking are hard to find, the costs are clear: Online revocation checks are slow and compromise privacy,” Langley added. That’s because the checks add a median time of 300 milliseconds and a mean of almost 1 second to page loads, making many websites reluctant to use SSL. Marlinspike and others have also complained that the services allow certificate authorities to compile logs of user IP addresses and the sites they visit over time.

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch. The time frame for the Chrome changes to go into effect are “on the order of months,” a Google spokesman said.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Tags:
File Under: Security, servers, Web Basics
Jan
31
2012

Google, Microsoft, Yahoo, PayPal Go After Phishers With New E-Mail Authentication Effort

By

Major e-mail providers, including Google, Microsoft, and Yahoo are teaming up with PayPal, Facebook, LinkedIn, and more, to implement a new system for authenticating e-mail senders to try to prevent the sending of fraudulent spam and phishing messages.

The protocol that powers e-mail, SMTP, dates back to a more trusting era; a time when the only people who sent you e-mails were people you wanted to send you e-mails. SMTP servers are willing to accept pretty much any e-mail destined for a mailbox they know about (which is, admittedly, an improvement on how things used to be, when they’d accept e-mails even for mailboxes they didn’t know about), a fact which spammers and phishers exploit daily.

Making any fundamental changes to SMTP itself is nigh impossible; there are too many e-mail servers, and they all have to interoperate with each other, an insurmountable hurdle for any major change. So what we’re left with is all manner of additional systems that are designed to give SMTP servers a bit more information about the person sending the e-mail, so that they can judge whether or not they really want to accept the message.

The two main systems in use today are called SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). Both systems use DNS to publish extra information about the e-mail sender’s domain. SPF tells the receiving server which outgoing servers are allowed to send mail for a given domain; if the receiving server receives mail from a server not on the list, it should assume that the mail is fraudulent. DKIM embeds a cryptographic signature to e-mail messages and an indication of which DNS entry to examine. The receiving server can then look up the DNS entry and use the data it finds to verify the signature.

These systems are not perfect; though both are used widely, they haven’t been adopted universally. This means that some legitimate mail will arrive that doesn’t have SPF or DKIM DNS entries, and so mail servers can’t depend on its presence. Common legitimate operations can also break them; many mailing list programs add footers to messages, which will cause rejection by DKIM, and forwarding e-mails causes rejection by SPF. As a result, failing one or other test is not a good reason to reject a message.

These systems also make it hard to diagnose misconfigurations; receiving servers will typically just swallow or ignore mails sent by systems with bad SPF or DKIM configurations.

The large group of companies, which includes the biggest web mail servers and some of the most common corporate victims of phishing attempts, is proposing a new scheme, DMARC (“Domain-based Message Authentication, Reporting & Conformance”), in an attempt to tackle these problems. DMARC fills some of the gaps in SPF and DKIM, making them more trustworthy.

DMARC's position within the mail receipt process (illustration by dmarc.org)

DMARC is based on work done by PayPal in conjunction with Yahoo, and later extended to Gmail. This initial work resulted in a substantial reduction in the number of PayPal phishing attempts seen by users of those mail providers, and DMARC is an attempt to extend that to more organizations. As with SPF and DKIM, DMARC depends on storing extra information about the sender in DNS. This information tells receiving mail servers how to handle messages that fail the SPF or DKIM tests, and how critical the two tests are. The sender can tell recipient servers to reject messages that fail SPF and DKIM outright, to quarantine them somehow (for example, putting them into a spam folder), or to accept the mail normally and send a report of the failure back to the sender.

In turn, this makes SPF and DKIM much safer for organizations to deploy. They can start with the “notification” mode, confident that no mail will be lost if they have made a mistake, and use the information learned to repair any errors. DMARC also allows recipients to know if a domain should be using SPF and DKIM in the first place.

Without a global rollout, DMARC can’t solve all phishing and spam problems. The companies that have signed up to support the project include major recipients of phishing attempts—the various free e-mail providers—and sites against which phishing attacks are regularly made. Mail sent between the organizations will be verified using the SPF/DKIM/DMARC trifecta. Anyone using the major mail providers and the major services should see a substantial reduction in fraudulent mail. Senders and recipients who want to receive similar protection can implement DMARC themselves by following the specification that the DMARC group is working on.

Given the constraints imposed by SMTP, we may never get an e-mail system that is entirely free of malicious and annoying junk. SMTP e-mail was never designed to be trustworthy, and systems like SPF and DKIM are constrained by the inadequacies of SMTP’s design. Nonetheless, mechanisms such as DMARC can still make a big difference, and with the support of these major companies, e-mail might get that little bit safer.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Illustration by dmarc.org

Tags:
File Under: privacy, Security, Social
Jan
5
2012

Worm Steals 45,000 Facebook Login Credentials, Infects Victims’ Friends

By

A worm previously used to commit financial fraud is now stealing Facebook login credentials, compromising at least 45,000 Facebook accounts with the goals of transmitting malicious links to victims’ friends and gaining remote access to corporate networks.

The security company Seculert has been tracking the progress of Ramnit, a worm first discovered in April 2010, and described by Microsoft as “multi-component malware that infects Windows executable files, Microsoft Office files and HTML files” in order to steal “sensitive information such as saved FTP credentials and browser cookies.” Ramnit has previously been used to “bypass two-factor authentication and transaction signing systems, gain remote access to financial institutions, compromise online banking sessions and penetrate several corporate networks,” Seculert says.

Recently, Seculert set up a sinkhole and discovered that 800,000 machines were infected between September and December. Moreover, Seculert found that more than 45,000 Facebook login credentials, mostly in the UK and France, were stolen by a new variant of the worm.

“We suspect that the attackers behind Ramnit are using the stolen credentials to log-in to victims’ Facebook accounts and to transmit malicious links to their friends, thereby magnifying the malware’s spread even further,” Seculert said. “In addition, cybercriminals are taking advantage of the fact that users tend to use the same password in various web-based services (Facebook, Gmail, Corporate SSL VPN, Outlook Web Access, etc.) to gain remote access to corporate networks.”

Facebook fraud, of course, is nothing new. Facebook itself has acknowledged seeing 600,000 compromised logins each day, although that accounts for just 0.06 percent of the one billion Facebook logins each day.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Tags:
File Under: privacy, Security
Sep
8
2011

Why Wait for Google? Use Encrypted Search Today

By

Google appears to be expanding the use of its encrypted search page, automatically redirecting some Chrome users to the HTTPS version of Google search. The company has also expanded the number of Google search tools that work with the encrypted page to include Google Image Search, Google Instant and Google Instant Preview.

Using Google search over SSL means that your search terms are encrypted, so prying eyes can’t see what you’re searching for, nor can they see the results you get back. Google’s efforts to provide an encrypted search page are just one part of a broader move afoot on the web to shift more traffic over to the more secure HTTPS protocol.

Why all the fuss about HTTPS? Well, every time you search Google or log in to Twitter or Facebook over 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. There is a better way, the secure version of HTTP — HTTPS. That extra “S” in the URL means your connection is secure, and it’s much harder for anyone else to see what you’re doing. Think of the extra “S” as the envelop that keeps prying eyes from looking at your postcards.

Although the HTTPS version of Google does, in Google’s words, “provide you with a more secure and private search experience,” it’s worth noting that it doesn’t stop Google from tracking your search terms and other data.

Google Operating System, which tracks all things Google, dug up a post on the Google Support Forums where a Google employee says that Google is “running an experiment with some percentage of Chrome 14 users where we send them to SSL search.” That means that some Chrome users may find themselves using the HTTPS search page without even realizing they are.

Chrome 14 is still in beta, so in order for this to affect you, you’ll need to be using the beta channel.

Of course even if you aren’t part of Google’s effort to expand Google Search over SSL, doesn’t mean you can’t configure your browser to use the HTTPS search page by default. Firefox fans can just install the HTTPS Everywhere extension. Chrome and Chromium users can simply right-click the URL bar, choose “edit search engines” and then look for the Google entry. Just click edit, add an “s” to the end of the “http” and you’re done. Internet Explorer users can head to the IE add-ons page and create a new search provider using the form.

Photo: Joffley/Flickr/CC

See Also:

Tags: ,
File Under: Browsers, Security, Web Basics
Aug
5
2011

Firefox Security Tool HTTPS Everywhere Hits 1.0

By

After a year of beta testing the Electronic Frontier Foundation’s HTTPS Everywhere Firefox add-on has reached stable, 1.0 status. 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 sites HTTPS Everywhere supports.

If you’re using Firefox, head over to the EFF’s website and install HTTPS Everywhere. If you’re not using Firefox you’re unfortunately out of luck. The limited add-on APIs of browsers like Chrome and Safari mean that HTTPS Everywhere can’t be ported to those platforms (see the HTTPS Everywhere site for more info).

Why all the fuss about HTTPS? Well, every time you log in to Twitter, Facebook or any other service that uses 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.

With HTTPS Everywhere installed, if you type, for example, “twitter.com” in the Firefox URL bar, the browser will automatically connect to https://twitter.com rather than http://twitter.com. Think of an HTTPS connection as an envelope to protect your postcard from prying eyes.

With the 1.0 release, HTTPS Everywhere now supports some 1000 websites, including the web’s most popular like Google Search, Facebook and Wikipedia. One thing to keep in mind though, not every website supported serves all of its content over HTTPS, which can still leave you open to some vulnerabilities (the Chrome web browser now warns when a site serves HTTP content alongside HTTPS, a feature other browsers will hopefully copy).

Still, even if not every website supports HTTPS completely, Firefox with HTTPS Everywhere is more secure than most browser setups. If you’re using Firefox anyway, it’s well worth installing HTTPS Everywhere, particularly if you frequently use wifi networks you don’t control.

Photo: Joffley/Flickr/CC

See Also:

Tags: , ,
File Under: Identity, Security, Web Basics
Apr
22
2011

EFF Wants to Secure the Web With “HTTPS Now” Campaign

By

The Electronic Frontier Foundation (EFF) has kicked off a new “HTTPS Now” campaign to educate consumers and help “make web surfing safer.”

The new campaign is a two part effort. First the EFF would like to encourage users to install the HTTPS Everywhere Firefox add-on, which will automatically redirect you to https connections. HTTPS Everywhere makes sure you’re always using a secure connection when you visit Gmail, Twitter and several dozen other sites; you don’t need to worry about checking the URL everytime you login.

While HTTPS Everywhere is a good suggestion for users, the primary thrust of the HTTPS Now campaign is aimed at popular websites. After all, HTTPS Everywhere only works if your favorite sites offer secure connections, and an alarming number of sites do not.

The EFF has partnered with Access, a digital freedom activist group, to create the new HTTPS Now website. The new site will keep track of which sites offer HTTPS connections, how much of the site is secure and whether or not the site mixes secure and insecure content.

Why all the fuss about HTTPS? Well, every time you log in to Twitter, Facebook or any other service that uses 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.

There is a better way, the secure version of HTTP — HTTPS. That extra “S” in the URL means your connection is secure, and it’s much harder for anyone else to see what you’re doing. Think of the extra “S” as the envelop that keeps prying eyes from looking at your postcards.

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 the sites often revert back to using an insecure HTTP connection. That means you’re vulnerable to simple attacks like those made possible by the Firesheep Firefox plugin. Firesheep sniffs network traffic and looks for insecure cookies which it then uses to spoof your login credentials to the site. Firesheep allows other people to quickly and easily become you on the web.

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 and there are also some (minor) costs involved with HTTPS certificates.

But obviously neither cost nor minor speed hits have stopped big sites like Twitter, Facebook, Gmail and Flickr from implementing HTTPS. The EFF would like to encourage other sites to follow suit.

If you’d like to see how your favorite sites fair when it comes to protecting your data from traffic snoops, head on over to the HTTPS Now website.

Photo: Joffley/Flickr/CC

See Also:

Tags: ,
File Under: Security
Mar
31
2011

It’s World Backup Day, Do You Know Where Your Files Are?

By

This is your PC.

Amazon’s recent leap into the world of online backups, with its new CloudDrive service, is just one of several dozen ways you can backup your files. And, as anyone with a failed hard drive can tell you, there’s no such thing as too many backups. Sadly, most of us discover the value of good backups only after tragedy strikes.

That’s why a group of Reddit fans were inspired to launch the first ever World Backup Day — today, March 31st 2011.

If you’re not an rsync master with RAID drives, tape machines and servers around the world making copies of your files, the Reddit thread that started the idea of a world backup day is well worth a read. Not only are there plenty of suggestions for automated cloud backup services like Dropbox or Backblaze, there are some great tricks and tips for making sure your files never go missing (like checking your restores — when was the last time you actually tried to recover from your backups?)

If you’ve been a bit lax in your backups, head over to WorldBackupDay.net for some discounts from online backup services and more tips for making sure that even if your computer disappears tomorrow your files won’t go with it.

Now go back up your data. Seriously.

Photo: alexmuse/Flickr/CC

See Also:

File Under: HTML, Programming, Security
Mar
18
2011

HTTPS Is More Secure, So Why Isn’t the Web Using It?

By

You wouldn’t write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection, that’s essentially what you’re doing.

There is a better way, the secure version of HTTP — HTTPS. That extra “S” in the URL means your connection is secure, and it’s much harder for anyone else to see what you’re doing. But if HTTPS is more secure, why doesn’t the entire web use it?

HTTPS has been around nearly as long as the web, but it’s primarily used by sites that handle money — your bank’s website or shopping carts that capture credit card data. Even many sites that do use HTTPS use it only for the portions of their websites that need it — like shopping carts or account pages.

Web security got a shot in the arm last year when the FireSheep network-sniffing tool made it easy for anyone to detect your login info over insecure networks — your local coffeeshop’s hotspot or public Wi-Fi at the library. That prompted a number of large sites to begin offering encrypted versions of their services on HTTPS connections.

Lately even sites like Twitter (which has almost entirely public data anyway) are nevertheless offering HTTPS connections. You might not mind anyone sniffing and reading your Twitter messages en route to the server, but most people don’t want someone also reading their username and password info. That’s why Twitter recently announced a new option to force HTTPS connections (note that Twitter’s HTTPS option only works with a desktop browser, not the mobile site, which still requires manually entering the HTTPS address).

Google has even announced it will add HTTPS to many of the company’s APIs. Firefox users can go a step further and use the HTTPS Everywhere add-on to force HTTPS connections to several dozen websites that offer HTTPS, but don’t use it by default.

So, with the web clearly moving toward more HTTPS connections, why not just make everything HTTPS?

That’s the question I put to Yves Lafon, one of the resident experts on HTTP(s) at the W3C. There are some practical issues most web developers are probably aware of, such as the high cost of secure certificates, but obviously that’s not as much of an issue with large web services that have millions of dollars.

The real problem, according to Lafon, is that with HTTPS you lose the ability to cache. “Not really an issue when servers and clients are in the same region (meaning continent),” writes Lafon in an e-mail to Webmonkey, “but people in Australia (for example) love when something can be cached and served without a huge response time.”

Lafon also notes that there’s another small performance hit when using HTTPS, since “the SSL initial key exchange adds to the latency.” In other words, a purely security-focused, HTTPS-only web would, with today’s technology, be slower.

For sites that don’t have any reason to encrypt anything — in other words, you never log in, so there’s nothing to protect — the overhead and loss of caching that comes with HTTPS just doesn’t make sense. However, for big sites like Facebook, Google Apps or Twitter, many users might be willing to take the slight performance hit in exchange for a more-secure connection. And the fact that more and more websites are adding support of HTTPS shows that users do value security over speed, so long as the speed difference is minimal.

Another problem with running an HTTPS site is the cost of operations. “Although servers are faster, and implementations of SSL more optimized, it still costs more than doing plain HTTP,” writes Lafon. While less of a concern for smaller sites with little traffic, HTTPS can add up, if your site suddenly becomes popular.

Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn’t work with virtual hosts. Virtual hosts, which are what the most common cheap web-hosting providers offer, allow the web host to serve multiple websites from the same physical server — hundreds of websites all with the same IP address. That works just fine with regular HTTP connections, but it doesn’t work at all with HTTPS.

There is a way to make virtual hosting and HTTPS work together — the TLS Extensions protocol — but Lafon notes that, so far, it’s only partially implemented. Of course that’s not an issue for big sites, which often have entire server farms behind them. But until that spec — or something similar — is widely used, HTTPS isn’t going to work for small, virtually hosted websites.

In the end there is no real reason the whole web couldn’t use HTTPS. There are practical reasons why it isn’t happening today, but eventually the practical hurdles will fall away. Broadband speeds will improve, which will make caching less of a concern, and improved servers will be further optimized for secure connections.

In the web of the future the main concern won’t just be how fast a site loads, but how well it safeguards you and protects your data once it does load.

Photo: Joffley/Flickr/CC

File Under: Browsers, Identity, Security
Jan
25
2011

Chrome Add-on Kills Tracking Cookies

By

Not to be outdone by Mozilla, Google has released a new add-on for its Chrome web browser that allows users to opt-out of online advertising tracking. While Mozilla’s privacy tool is still just a proposal, and involves a new HTTP header, Google’s add-on uses the more practical, cookie-based approach and works today.

The Keep My Opt-Outs add-on works like a very persistant cookie, but this one is working in your favor. The add-on uses Chrome’s internal cookie APIs to set the opt-out flag for each advertising network that participates in the opt-out program created by the ad industry. Not only is it easier than setting those cookies yourself, the add-on ensures that, even if you clear the rest of your cookies, the opt-out cookies remain intact.

While it works, Google’s approach is something of a hack. The add-on intercepts and rewrites cookies, which is not exactly an ideal solution. Still, if you’re a Chrome user and you’ve been looking for a way to stop advertising cookies today, the Keep My Opt-Outs add-on has you covered.

Keep My Opt-Outs also makes a viable alternative to ad-blockers, particularly for those concerned that ad-blocking add-ons are denying their favorite sites much needed revenue. Provided you don’t mind a few advertisements here and there, using the new add-on in conjunction with some smart cookie settings, you can support your favorite sites without forfeiting your privacy. And for those that do use ad blockers, keep in mind that just because the ad is not shown, doesn’t always mean it can’t set cookies.

In the long term, Mozilla’s header-based approach to stopping cookie-based tracking is a better solution, and we expect, if the idea catches on, Chrome and other browsers will support it as well. For those who want something that works today, Google’s new add-on fits the bill.

Footprints photo by Vinoth Chandar/Flickr/CC

See Also:

Tags: ,
File Under: Browsers, Identity, Security
Jan
24
2011

Mozilla Plans ‘Do-Not-Track’ Privacy Tools for Firefox

By

Mozilla wants to create a new HTTP header that will allow Firefox and other browsers to shut off web tracking tools like cookies. The new header would offer a universal way to tell websites that a user wishes to opt-out of third party, advertising-based tracking.

Behavioral advertising, as such tracking is known, is becoming increasingly common on the web. Advertisers use cookies to follow you around the web, tracking which sites you visit, what you buy and even, in the case of mobile browsers, where you go. The U.S. Federal Trade Commission has already outlined a Do Not Track mechanism (PDF link), which would work much like the FTC’s Do Not Call list, offering a way to opt-out of online tracking.

The proposed do-not-track HTTP header is one of several ways Mozilla plans to implement the FTC’s suggestions. While the header idea has been around for a while — the Do Not Track Firefox add-on from the Stanford Law School is one example — currently most online opt-out schemes use cookies to set user preferences. Mozilla believes “the header-based approach has the potential to be better for the web in the long run because it is a clearer and more universal opt-out mechanism than cookies or blacklists.”

While the new header is just a proposal at the moment, Mozilla already has some code ready and is considering adding the feature to future versions of Firefox. The current plan is to create a new preferences option that would allow you to opt-out from tracking. Check the box in the preferences and Firefox will start sending the do-not-track header each time you request a new page.

Interestingly, the header Mozilla proposes is not the same as the “X-Do-Not-Track” proposal, which is already implemented in Firefox add-ons NoScript and Adblock Plus. For more details on how Mozilla’s new HTTP header will work, see Mozilla developer Sid Stamm’s blog post.

Like Mozilla’s proposed privacy icons, the problem with the new header is getting third-party ad sites to obey it. Mozilla calls it a “chicken and egg” problem and hopes to jumpstart the idea by including the header in future releases of Firefox. At that point it would be up to third party websites to support the header and, as Mozilla puts it, “honor people’s privacy choices.”

See Also:

Tags: , ,
« OLDER POSTS