Government Shutdown Means Government Website Security Certs Aren't Being Renewed

from the it's-the-little-things dept

With all the news about the ongoing government shutdown and the big messes it has caused, it's creating lots of little messes with potentially big impact as well. For example, scammers and robocallers have upped their game during the shutdown, knowing that (1) there's no one investigating these scams right now, and (2) as I discovered when I tried to report one, the FTC has literally shut down the web portal where you used to be able to submit complaints.

Another one, however, pointed out last week by Netcraft, is the fact that government website security certificates are expiring... and there's no one around to renew them:

Dozens of U.S. government websites have been rendered either insecure or inaccessible during the ongoing U.S. federal shutdown. These sites include sensitive government payment portals and remote access services, affecting the likes of NASA, the U.S. Department of Justice, and the Court of Appeals.

With around 400,000 federal employees currently furloughed, more than 80 TLS certificates used by .gov websites have so far expired without being renewed. To compound the situation, some of these abandoned websites can no longer be accessed due to strict security measures that were implemented long before the shutdown started.

As Netcraft notes, some of those sites you can't even get around the security warning, such as certain DOJ sites:

There are some government websites that you can click through on, but as Netcraft notes, this could allow for man-in-the-middle attacks or other security risks:

This introduces some realistic security concerns, as task-oriented users are more likely to ignore these security warnings, and will therefore render themselves vulnerable to man-in-the-middle attacks.

If the shutdown continues for a while, this problem could get significantly worse. I know that Wall Street put pressure on the government to make certain IRS employees suddenly deemed "essential" to help Wall Street keep functioning smoothly, perhaps someone might want to deem the people renewing security certs similarly essential? Or, you know what, maybe just re-open the damn government.

Filed Under: encryption, government shutdown, https, security certificates, tls

Ted Cruz's New Presidential Campaign Donation Website Shares Security Certificate With Nigerian-Prince.com

from the feeling-safe-donating-yet? dept

Update: Yes, as lots of angry people are screaming at us (including with detailed explanations of how incredibly, unbelievably, astoundingly stupid I must be), this is a result of Cruz using Cloudflare, which lumps unrelated domains onto the same HTTPS certificate. And yes, Techdirt.com's certificate is hosted by Cloudflare also, and we share it with other domains as well. Feel free to continue to read the original story below and contribute to how stupid you think I am in the comments...

We're big believers in using HTTPS to secure websites (even if HTTPS certificates have their problems -- it's still better than the alternative). But there are pitfalls in setting up your certificate correctly as newly announced presidential candidate Senator Ted Cruz apparently discovered this morning. Because along with his campaign launch speech (which was widely mocked by the Liberty University students who were forced to attend), he put up a website for donations. And that website didn't default to HTTPS and also listed nigerian-prince.com as an alternate domain on the security certificate, as first noted by the Twitter feed @PwnAllTheThings: A few hours after this was first noticed, the Cruz campaign appears to have removed nigerian-prince.com from its certificate, but it still raises some questions about just who he has hired to build his websites. I guess that's what happens when even the technologists in your own party openly mock Ted Cruz's ignorance when it comes to technology issues like net neutrality.

Filed Under: donations, https, internet security, nigerian prince, presidential campaign, security, security certificates, ssl, ted cruz, tls

Chief Information Officers Council Proposes HTTPS By Default For All Federal Government Websites

from the being-the-change-people-have-been-waiting-for dept

In a long-overdue nod to both privacy and security, the administration finally moved Whitehouse.gov to HTTPS on March 9th. This followed the FTC's March 6th move to do the same. And yet, far too many government websites operate without the additional security this provides. But that's about to change. According to a recent post by the US government's Chief Information Officers Council, HTTPS will (hopefully) be the new default for federal websites.

The American people expect government websites to be secure and their interactions with those websites to be private. Hypertext Transfer Protocol Secure (HTTPS) offers the strongest privacy protection available for public web connections with today’s internet technology. The use of HTTPS reduces the risk of interception or modification of user interactions with government online services.

This proposed initiative, “The HTTPS-Only Standard,” would require the use of HTTPS on all publicly accessible Federal websites and web services.

In a statement that clashes with the NSA's activities and the FBI's push for pre-compromised encryption, the CIO asserts that when people engage with government websites, these interactions should be no one's business but their own.

All browsing activity should be considered private and sensitive.

The proposed standard would eliminate agencies' options, forcing them to move to HTTPS, both for their safety and the safety of their sites' visitors. To be sure, many cats will still need to be shepherded if this goes into effect, but hopefully there won't be too many details to trifle over. HTTPS or else is the CIO Council's goal -- something that shouldn't be open to too much interpretation.

As the Council points out, failing to do so places both ends of the interaction at risk. If government sites are thought to be unsafe, it has the potential to harm citizens along with the government's reputation.

Federal websites that do not use HTTPS will not keep pace with privacy and security practices used by commercial organizations, or with current and upcoming Internet standards. This leaves Americans vulnerable to known threats, and reduces their confidence in their government. Although some Federal websites currently use HTTPS, there has not been a consistent policy in this area. The proposed HTTPS-only standard will provide the public with a consistent, private browsing experience and position the Federal government as a leader in Internet security.

The CIO's short, but informative, explanatory page lists the pros of this proposed move, as well as spells out what HTTPS doesn't protect against. It also notes that while most sites should actually see a performance boost from switching to HTTPS, sites that gather elements for other parties will be the most difficult to migrate. And, it notes, the move won't necessarily be inexpensive.

The administrative and financial burden of universal HTTPS adoption on all Federal websites includes development time, the financial cost of procuring a certificate and the administrative burden of maintenance over time. The development burden will vary substantially based on the size and technical infrastructure of a site. The proposed compliance timeline provides sufficient flexibility for project planning and resource alignment.

But, it assures us (at least as much as any government entity can...), the money will be well-spent.

The tangible benefits to the American public outweigh the cost to the taxpayer. Even a small number of unofficial or malicious websites claiming to be Federal services, or a small amount of eavesdropping on communication with official US government sites could result in substantial losses to citizens.

The CIO is also taking input from the public, at Github no less.

A very encouraging -- if rather belated -- sign that the government is still making an effort to take privacy and security seriously, rather than placing those two things on the scales for intelligence and law enforcement agencies to shift around as they see fit when weighing their desires against Americans' rights and privileges.

Filed Under: encryption, federal government, ftc, https, ssl, tls, websites, white house

Encryption Backdoors Will Always Turn Around And Bite You In The Ass

from the golden-keys dept

As you may have heard, the law enforcement and intelligence communities have been pushing strongly for backdoors in encryption. They talk about ridiculous things like "golden keys," pretending that it's somehow possible to create something that only the good guys can use. Many in the security community have been pointing out that this is flat-out impossible. The second you introduce a backdoor, there is no way to say that only "the good guys" can use it.

As if to prove that, an old "golden key" from the 90s came back to bite a whole bunch of the internet this week... including the NSA. Some researchers discovered a problem which is being called FREAK for "Factoring RSA Export Keys." The background story is fairly involved and complex, but here's a short version (that leaves out a lot of details): back during the first "cryptowars" when Netscape was creating SSL (mainly to protect the early e-commerce market), the US still considered exporting strong crypto to be a crime. To deal with this, RSA offered "export grade encryption" that was deliberately weak (very, very weak) that could be used abroad. As security researcher Matthew Green explains, in order to deal with the fact that SSL-enabled websites had to deal with both strong crypto and weak "export grade" crypto, -- the "golden key" -- there was a system that would try to determine which type of encryption to use on each connection. If you were in the US, it should go to strong encryption. Outside the US? Downgrade to "export grade."

In theory, this became obsolete at the end of the first cryptowars when the US government backed down for the most part, and stronger crypto spread around the world. But, as Green notes, the system that did that old "negotiation" as to which crypto to use, known as "EXPORT ciphersuites" stuck around. Like zombies. We'll skip over a bunch of details to get to the point: the newly discovered hack involves abusing this fact to force many, many clients to accept "export grade" encryption, even if they didn't ask for it. And it appears that more than a third of websites out there (many coming from Akamai's content delivery network -- which many large organizations use) are vulnerable.

And that includes the NSA's own website. Seriously. Now, hacking the NSA's website isn't the same as hacking the NSA itself, but it still seems notable just for the irony of it all (obligatory xkcd): But the lesson of the story: backdoors, golden keys, magic surveillance leprechauns, whatever you want to call it create vulnerabilities that will be exploited and not just by the good guys. As Green summarizes:

There’s a much more important moral to this story.

The export-grade RSA ciphers are the remains of a 1980s-vintage effort to weaken cryptography so that intelligence agencies would be able to monitor. This was done badly. So badly, that while the policies were ultimately scrapped, they’re still hurting us today.

This might be academic if it was just a history lesson — but for the past several months, U.S. and European politicians have been publicly mooting the notion of a new set of cryptographic backdoors in systems we use today. This would involve deliberately weakening technology so that governments can intercept and read our conversations. While officials are carefully avoiding the term “back door” — or any suggestion of weakening our encryption systems — this is wishful thinking. Our systems are already so complex that even normal issues stress them to the breaking point. There's no room for new backdoors.

To be blunt about it, the moral of this story is pretty simple:

Encryption backdoors will always turn around and bite you in the ass. They are never worth it.

Let's repeat that last line, because it still seems that the powers that be don't get it:

Encryption backdoors will always turn around and bite you in the ass. They are never worth it.

Whether it's creating vulnerabilities that come back to undermine security on the internet decades later, or merely giving cover to foreign nations to undermine strong encryption, backdoors are a terrible idea which should be relegated to the dustbin of history.

Filed Under: backdoors, encryption, export encryption, export keys, freak, nsa, openssl, ssl, tls, vulnerability

Lenovo In Denial: Insists There's No Security Problem With Superfish -- Which Is Very, Very Wrong.

from the so-long-and-thanks-for-all-the-superfish dept

Late last night, people started buzzing on Twitter about the fact that Lenovo, makers of the famous Thinkpad laptops, had been installing a really nasty form of adware on those machines called Superfish. Many news stories started popping up about this, again, focusing on the adware. But putting adware on a computer, while ethically questionable and a general pain in the ass, is not the real problem here. The problem is that the adware in question, Superfish, has an astoundingly stupid way of working that effectively allows for a very easy man in the middle attack on any computer with the software installed, making it a massive security hole that is insanely dangerous.

Lenovo's response? Basically to shrug its shoulders and say it doesn't understand why anyone's that upset. This is because whoever wrote Lenovo's statement on this is completely clueless about computer security.

We have thoroughly investigated this technology and do not find any evidence to substantiate security concerns.

Bullshit. That's really the only response that should be said to that line. Lenovo focuses on the reasons why many people normally hate adware: that it tracks what you're doing and sends info back to third parties. That's not what Superfish does, so Lenovo doesn't see what the big deal is. Superfish, which was just recently ranked 64th by Forbes in its list of "Most Promising American Companies," tries to watch what you're surfing, and when you see certain images, the service injects other offerings for similar (or the same) products. In theory, if one chose to use such a product, you could see why it could be useful. But automatically putting it on computers is a different thing all together.

The real problem is in how Superfish deals with HTTPS protected sites. Since, in theory, it shouldn't be able to see the images on those sites, it appears that Superfish came up with what it must have believed was a clever workaround: it just installs a root HTTPS certificate, that it signs itself, to pretend that any HTTPS page you're visiting is perfectly legitimate. For many years, we've pointed out why the HTTPS system with certificate authorities is open to a giant man in the middle attack via any certificate authority willing to grant a fake certificate -- and here we basically have Lenovo enabling this questionable company to go hogwild with this exact kind of MITM attack. Basically, EVERY SINGLE HTTPS SITE that you visit was a victim of this kind of MITM attack -- solely for the purpose of interjecting Superfish ads. In fact, some have suggested it could apply to VPNs as well. Basically this is a massively dangerous security hole with wide ranging implications. And Lenovo says they don't see why.

And, even beyond that, it's implemented incredibly stupidly -- in a way that is ridiculously dangerous. That's because it appears that the private key use for the Superfish certificate is the same on basically every install of this software. And it didn't take very long at all for security folks, such as Robert Graham, to crack the password, meaning that it's now incredibly easy to get access to information someone thinks is encrypted. As Graham notes, the password is "komodia" which just so happens to also be the name of a company that "redirects" HTTPS traffic (for spying on kids and such).

This is a massive and ridiculous security threat, and Lenovo is completely brushing it off as nothing big. As many have noted, people have been complaining about the adware components of the software for months now, and Lenovo announced that it was stopping installs, because some people didn't like the way the software created popups and such -- but with no mention of the massive security problems. And, even now, the company doesn't seem willing to admit to them.

Furthermore, the company doesn't even seem willing to say what machines it installed them on, or provide people with instructions on how to protect themselves (simply uninstalling Superfish won't do it). This is a huge mess. I've personally been a very loyal Lenovo Thinkpad customer for years, having bought many, many laptops. In fact, just a couple months ago -- right in the middle of the period of when Superfish was being preloaded -- I bought a new Thinkpad laptop, though it appears that mine is not one that includes Superfish. Still, Lenovo created a huge and dangerous mess, and they don't seem to recognize it at all. This kind of fuck up is much worse than the whole Sony rootkit thing from a decade or so ago, and as with Sony then, Lenovo doesn't seem to have the slightest clue of just how badly it has put people at risk.

It doesn't take much to kill off tremendous goodwill and trust, and Lenovo may have just done so with it's pitiful reaction here. It's one thing for Lenovo to have made the stupid decision to install this kind of adware/bloatware. It's a second thing to not realize the security implications of it. However, it's another thing entirely, once it's been pointed out to Lenovo to then deny that this is a security risk. Lenovo screwed up big time here, and mostly in the way it's responded to the mess it created.

Filed Under: adware, certificate authority, concerns, https, man in the middle, privacy, security, superfish, tls
Companies: komodia, lenovo, superfish

Shamed By Google's Email Security Transparency Report, Comcast Is Rushing To Better Encrypt Emails

from the sunlight-to-disinfectant dept

Well, that was quick. Yesterday Google announced its new email security/encryption transparency report, which revealed that Comcast and Verizon were primary offenders, in not using TLS to encrypt emails, making them much more vulnerable to surveillance. And, in less than 24 hours, Comcast quickly said that it is rushing to roll out TLS, with a company spokesperson saying it will be out there "within a matter of weeks" and that the company is being "very aggressive about this." That's good to see. Once again, greater transparency leads to greater protection.

Filed Under: email, encryption, tls
Companies: comcast, google

Google To Enable End-To-End Email Encryption, Highlight Good Email Security Practices

from the good-to-see dept

Back in December of 2012, we wrote about (and agreed with) Julian Sanchez's suggestion that Google should do end-to-end encryption of emails, even if it (only slightly) mucked with its advertising business model. The impact on overall security would be great (and this was before the Snowden revelations had even come out). As Sanchez pointed out, not only would this (finally) drive more widespread adoption for email encryption, it would create enormous goodwill among privacy advocates. About six weeks ago, we mentioned this again, when it was rumored that Google was trying to make encrypted email easier, though it was said that it wouldn't go "site-wide" on end-to-end encryption.

A new blog post on the Google blog* has now detailed at least some of Google's plans, including offering a new End-to-End Chrome extension that will make it much easier for anyone to send and receive encrypted email messages. This is a big step forward, and hopefully shows how serious Google is about actually encrypting messages, rather than leaving them open for snooping.

This announcement came along with adding a new section to Google's famed transparency report, entirely focused on email encryption in transit, which will hopefully increase the use of Transport Layer Security (TLS) from other email providers out there. In the initial report, Google notes that 65% of outbound messages on Gmail to other providers use TLS, while 50% of inbound messages use TLS (over the last 30 days). And, more importantly, it highlights who supports TLS... and who doesn't (Comcast seems to be a shameful leader on that front). With some transparency, hopefully it will lead more email providers to adopting TLS.

* For the sake of full disclosure, the author of the blog post on Google's site is an old friend of mine, whom I've known for nearly 20 years (I feel old), since long before he worked at Google. I had no idea he was working on this and actually haven't spoken to him in probably a year or two (because life happens). I didn't find out about it from him, but from people talking about it on Twitter.

Filed Under: chrome extension, email, encryption, end-to-end encryption, gmail, pgp, privacy, security, tls
Companies: google

Twitter Implements Forward Secrecy; Says It 'Should Be The New Normal'

from the protecting-your-privacy dept

There's been a lot of talk recently about getting more web companies to look at using forward secrecy to make HTTPS connections even more secure. That link from Parker Higgins at EFF explains the basics. It appears that folks at Twitter were paying attention, as they've now announced how they've implemented forward secrecy to better protect privacy. In practical terms, this means that if someone (hello NSA peoples!) is recording all encrypted traffic today, and then are later able to crack or steal Twitter's private encryption keys, they shouldn't be able to go back and decrypt the stored data. That's as opposed to the way many now implement security, in which if the key gets out, it's basically game over for privacy on previously encrypted files.

The Twitter blog post on this actually goes into a fairly detailed discussion about the technology choices they made, and the trade-offs involved. It's pretty clear this wasn't just written by a PR person. That said, security researcher Nicholas Weaver notes some potential issues with Twitter's transport encryption choices, noting that there are some indications that RC4 is no longer secure, even when used in TLS. Hopefully further changes can make it even more secure.

That said, the Twitter blog post makes a key point towards the end, about how greater and greater security, especially against the ability of an entity like the NSA, needs to be "the new normal."

At the end of the day, we are writing this not just to discuss an interesting piece of technology, but to present what we believe should be the new normal for web service owners. A year and a half ago, Twitter was first served completely over HTTPS. Since then, it has become clearer and clearer how important that step was to protecting our users’ privacy.

If you are a webmaster, we encourage you to implement HTTPS for your site and make it the default. If you already offer HTTPS, ensure your implementation is hardened with HTTP Strict Transport Security, secure cookies, certificate pinning, and Forward Secrecy. The security gains have never been more important to implement.

Filed Under: encryption, forward secrecy, https, privacy, rc4, security, tls
Companies: twitter