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.
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.
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.”
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.
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.