Boing Boing 

Samsung fridges can leak your Gmail logins

Researchers at Pen Test Partners took up the challenge to hack a smart fridge at Defcon's IoT Village, and discovered that they could man-in-the-middle your Google login credentials from Samsung fridges.

Read the rest

Companies should never try to intercept their users' encrypted traffic

Lenovo's disgraceful use of Superfish to compromise its users' security is just the tip of the iceberg: everywhere we look, companies have decided that it's a good idea to sneakily subvert their users' encryption.

Read the rest

Prime Suspect, or Random Acts of Keyness

The foundation of Web security rests on the notion that two very large prime numbers, numbers divisible only by themselves and 1, once multiplied together are irreducibly difficult to tease back apart.

Read the rest

Google implements "forward secrecy" in its encrypted traffic, releases improvements to SSL library for all to use

Google has changed its procedures to enable "forward secrecy" by default on all its search-traffic. This means that part of the key needed to decrypt the traffic is never stored, so that in the event that there is a security breach at Google, older, intercepted traffic can't be descrambled. It's the absolute best practice for secure communications, and Google is to be commended for adopting it.

Other web sites have implemented HTTPS with forward secrecy before — we have it enabled by default on — but it hasn’t yet been rolled out on a site of Google’s scale. Some sites have publicly resisted implementing forward secrecy because it is more CPU intensive than standard HTTP or HTTPS. In order to address that problem, Google made improvements to the open source OpenSSL library, and has incorporated those changes into the library for anybody to use.

Forward secrecy is an important step forward for web privacy, and we encourage sites, big and small, to follow Google’s lead in enabling it!

Long Term Privacy with Forward Secrecy

Twitter buys secure communications company that helped hack the Arab Spring

Twitter has bought a company called Whisper Systems, who make a secure version of the Android operating system as well as suites of privacy tools that are intended to protect demonstrators, especially participants in the Arab Spring. Many speculate that the acquisition was driven by the desire to hire CTO Moxie Marlinspike, a somewhat legendary cryptographer.

At first blush, the move is a bit baffling. Twitter, the quintessential consumer internet service, would seem to have little need for a company that has revamped Android security from the ground up for business use. But the micro-blogging site may simply be acquiring Whisper Systems for its talent — including Marlinspike, who serves as the startup’s chief technology officer, and roboticist Stuart Anderson — and the two companies do have a certain affinity. Both pride themselves on the support they’ve provided to protesters in the Middle East.

Security and privacy guru Chris Soghoian believes Twitter may have brought Moxie Marlinspike into the fold because the micro-blogging site has developed a reputation for not having the best security. Marlinspike is an expert in SSL (secure sockets layer) encryption, and Twitter — which has yet to turn on SSL by default for all users — could use his skills to lock down its services and make life harder for phishers.

I've been worried lately about the crumbling infrastructure of the SSL system, and what it means for our ability to communicate in private, to conduct banking and ecommerce, and to have any assurance of identity online. I've been asking all the security/crypto supernerds I know about this for a few months, and to a one, they've mentioned Marlinspike's Convergence and said, effectively, "I'm not sure if it'll solve this, but there's nothing else I have any hope for."

Twitter Buys Some Middle East Moxie (Thanks, Larry!)

Trusting unknown parties for security? Welcome to the web

ssllockmac.jpg At The Economist, Glenn Fleishman writes about a fundamental flaw in the industry standard security system for websites, SSL, familiar to all of us as the little lock icon that appears for 'secure' websites. Recently, a cracker was able to issue himself security certificates for domains at Skype and elsewhere, making clear the problem of assigning trust to certificating authorities just because.
The secure web infrastructure was designed in part to defend against this. The browser may be tricked into connecting to a server designed to extract your identity or intercept communications, but the browser will see the wolf under the sheep's clothing. It will alert the user and hinder him from connecting to a server that lacks a certificate, issued by some CA, for the domain it claims to be representing. But if a valid certificate can be obtained, neither the user nor the browser have any idea that they have been hijacked.
A big part of the problem seems to be the willingness of browser- and OS-makers to turn a blind eye to sleazy CAs. The web's trust issues [The Economist]

SSL certificate authorities put us all at risk by handing out certs for "mail" "webmail" and other unqualified domains

In the wake of the revelation that a major SSL certificate provider suffered a serious breach, Chris Palmer from the Electronic Frontier Foundation has analysis of the common practice of issuing certificates for unqualified domain names, such as "mail" and "www" and "localhost" (an unqualified domain is one that consists of a single word, without a top- and second-level domain, e.g., "www" instead of ""). These unqualified names should never be issued certificates, as doing so leaves anyone who makes a practice of using them within a company network vulnerable to man-in-the-middle attacks. Palmer found tens of thousands of these certificates, and sounds the alarm that if you're not using fully qualified domains for secure connections, you're very vulnerable.
Although signing "localhost" is humorous, CAs create real risk when they sign other unqualified names. What if an attacker were able to receive a CA-signed certificate for names like "mail" or "webmail"? Such an attacker would be able to perfectly forge the identity of your organization's webmail server in a "man-in-the-middle" attack! Everything would look normal: your browser would use HTTPS, it would show a the lock icon that indicates HTTPS is working properly, it would show that a real CA validated the HTTPS certificate, and it would raise no security warnings. And yet, you would be giving your password and your email contents to the attacker.

To test the prevalence of the validated, unqualified names problem, I queried the Observatory database for unqualified names similar to "exchange". (Microsoft Exchange is an extremely popular email server, and servers that run it commonly have "exchange" or "exch" in their names. Likely examples include "" and "".) My results show that unqualified "exchange"-like names are the most popular type of name, overall, that CAs are happy to sign.

Unqualified Names in the SSL Observatory

Microsoft switches off privacy for Hotmail users in war-torn and repressive states

For reasons unknown, Microsoft has changed the settings on Hotmail to disable HTTPS for users in several countries including Bahrain, Morocco, Algeria, Syria, Sudan, Iran, Lebanon, Jordan, Congo, Myanmar, Nigeria, Kazakhstan, Uzbekistan, Turkmenistan, Tajikistan, and Kyrgyzstan. Hotmail users in those countries can now be readily spied upon by ISPs and their governments. The Electronic Frontier Foundation has some good perspective:
Microsoft debuted the always-use-HTTPS feature for Hotmail in December of 2010, in order to give users the option of always encrypting their webmail traffic and protecting their sensitive communications from malicious hackers using tools such as Firesheep, and hostile governments eavesdropping on journalists and activists. For Microsoft to take such an enormous step backwards-- undermining the security of Hotmail users in countries where freedom of expression is under attack and secure communication is especially important--is deeply disturbing. We hope that this counterproductive and potentially dangerous move is merely an error that Microsoft will swiftly correct.

The good news is that the fix is very easy. Hotmail users in the affected countries can turn the always-use-HTTPS feature back on by changing the country in their profile to any of the countries in which this feature has not been disabled, such as the United States, Germany, France, Israel, or Turkey. Hotmail users who browse the web with Firefox may force the use of HTTPS by default--while using any Hotmail location setting--by installing the HTTPS Everywhere Firefox plug-in.

Microsoft Shuts off HTTPS in Hotmail for Over a Dozen Countries

Understanding the SSL security breach, preparing for the next one

Electronic Frontier Foundation staff technologist Peter Eckersley has a good, in-depth analysis of the revelation that Iranian hackers acquired fraudulent SSL certificates for Google, Yahoo, Mozilla and others by spoofing Comodo, a major Certificate Authority. CAs are companies that are allowed to sell cryptographically signed certificates that browsers use to verify their network connections; with these spoofed certs, the hackers could undetectably impersonate Yahoo and Google (allowing them to read mail even if it was being read over a secure connection), the Mozilla certificate would allow them to slip malicious spyware onto the computer of anyone installing a Firefox plugin.

It appears that the fraud was detected before any harm could be done, but Eckersley explains how close we came to a global security meltdown, and starts thinking about how we can prepare for a more successful attack in the future.

Most Certificate Authorities do good work. Some make mistakes occasionally,2 but that is normal in computer security. The real problem is a structural one: there are 1,500 CA certificates controlled by around 650 organizations,3 and every time you connect to an HTTPS webserver, or exchange email (POP/IMAP/SMTP) encrypted by TLS, you implicitly trust all of those certificate authorities!

What we need is a robust way to cross-check the good work that CAs currently do, to provide defense in depth and ensure (1) that a private key-compromise failure at a major CA does not lead to an Internet-wide cryptography meltdown and (2) that our software does not need to trust all of the CAs, for everything, all of the time.

For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.

Iranian hackers obtain fraudulent HTTPS certificates: How close to a Web security meltdown did we get?