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

BBC Migrates Everything To HTTPS, Immediately Finds Itself Blocked By The Chinese Government

from the weird-freedom-of-not-giving-a-damn-how-much-it-sucks-for-your-constituents dept

Move to HTTPS; lose the Chinese. That's the revised internet maxim. China's Great Firewall has gradually reduced the number of foreign sites accessible by Chinese citizens... "gradually" only in the sense that it's been a continuous rollout steadily decreasing web access. The government blocked an entire content delivery network at one point, so even this gradual rollout has seen its share of spikes.

As is being collaboratively reported at WikiTribune, the BBC says the move to HTTPS for all of it properties has resulted in Chinese citizens being unable to access their contents.

"In accordance with internet industry good practice, the BBC is currently changing the format of internet sites from HTTP to HTTPS. This means content is less vulnerable to tampering and specific pages on our websites can no longer be blocked. Recently the BBC Chinese language site has changed to this new format," a BBC spokesperson told WikiTribune on Wednesday.

The spokesperson added that the corporation’s online audience in China has had no access to any of the BBC’s websites for "around a week."

The BBC recommends a VPN to bypass Chinese web filtering, but that suggestion only goes so far in country where VPN use has been banned for the most part. Businesses still rely on VPNs for securing their communications and content, so the capitalist heart of the authoritarian government has granted exceptions. But the exceptions are limited to VPNs registered with the government, which presumably contain government backdoors.

Government-approved VPNs won't be much use to citizens looking to read news the government has already expressed an interest in blocking. And citizens looking to keep their Citizen Scores™ from dropping will be better off seeking out approved news sources using the heavily-regulated web the government provides.

Filed Under: blocked, china, encryption, https
Companies: bbc

The More Copyright Holders Move Up The Stack, The More They Put Everyone At Risk

from the taking-down-security-certs-is-bad dept

A little over a year ago, Matt Holt, who created the Caddy Server that helps make it easier to protect websites with HTTPS encryption, posted a hypothetical blog post, from the year 2022, in which he worried that enterprising and persistent copyright lawyers would have continued moving up the stack with their DMCA notices, and started to use the process to get HTTPS security certificates removed.

A lawyer need only be successful in convincing one of those four “choke points” by threatening legal action in order to suffocate the site. (There are others, like ISPs, which operate more generally, and we skip them for brevity.) These entities totally control the site’s availability, which is one crucial dimension of secure systems. Here they are again:

• Site owner. He or she can voluntarily remove the site/content.
• Web host. They can destroy the site owner’s account or files.
• Domain registrar. They can cancel or transfer ownership of the domain name.
• DNS provider. They can make the site inaccessible via hostname.

Now that it’s 2022, a site needs HTTPS in order to be trusted by browsers. At very least, this means they show an indicator above the page. Maybe it even means the browser shows a warning before navigating to the site. Either way, HTTPS is critical to a site’s availability and integrity.

DMCA lawyers are clever, and they realize this emerging trend. They contact a site’s CA and demand the site be disconnected for violating the law (despite lack of a court case). The CA, operating without policy for such requests and afraid of legal ramifications, revokes the site’s certificate.

Within hours, browsers begin to refuse connecting to the site on port 443 and warning flags fly instead, scaring users away. Browsers don’t revert to port 80 anymore because HTTPS is expected and using HTTP is effectively a downgrade attack. Visitors aren’t sure what to do, and the site goes offline around the globe.

We've raised some questions in the past about this process of copyright holders moving up the stack -- and not just targeting the content hosts, but companies further upstream, including ad providers, domain registers and registrars, and the like. There are serious issues with each of these, but going after security certificates seems especially pernicious.

But Matt was a bit off in his predicted timing on this. After his article ran, we learned of at least a few examples of copyright holders going after security certificate providers. Take for example this copyright notice that was sent to Squarespace (the host), Tucows (the domain register), and Let's Encrypt (the security certificate provider).

And now TorrentFreak notes that Comodo has revoked Sci-Hub's HTTPS certificate.

“In response to a court order against Sci-Hub, Comodo CA has revoked four certificates for the site,” Jonathan Skinner, Director, Global Channel Programs at Comodo CA informed TorrentFreak.

“By policy Comodo CA obeys court orders and the law to the full extent of its ability.”

Comodo refused to confirm any additional details, including whether these revocations were anything to do with the current ACS injunction. However, Susan R. Morrissey, Director of Communications at ACS, told TorrentFreak that the revocations were indeed part of ACS’ legal action against Sci-Hub.

“[T]he action is related to our continuing efforts to protect ACS’ intellectual property,” Morrissey confirmed.

We've obviously covered a lot about the Sci-hub story over the years, and the weird quixotic focus by some to take down a site focused on (of all things) better sharing academic knowledge (especially to academics in the developing world). It's already sickening enough the level to which some copyright holders have gone to effectively shut down a library, but going after the security certificate is beyond the pale.

The DMCA allows for approaching a variety of different intermediaries, from network communications, to hosts, to caching, to "information location tools" (i.e. search engines), but I have a very difficult time seeing how any of that applies to security certificate providers (or, for that matter, to domain registers).

Even more bizarre is that going after the security certificate doesn't stop any actual infringement -- it just makes users a lot less safe. And yet, it's coming from the very same copyright holders who keep trying to tell people they shouldn't pirate content because it exposes them to malware and viruses and dangerous computers and the like. But removing security certificates would make that a much more serious problem. And yet, here we have a case where ACS went after a security certificate, a judge okayed it, and Comodo played along. That's dangerous for the way the internet works and is kept secure. If they want to go after the hosts, go after the hosts. Destroying the ability to protect users by encrypting the traffic is just evil.

Filed Under: choke points, copyright, dmca, https, security certificates, ssl
Companies: acs, american chemical society, comodo, sci-hub

Certificate Authority Gave Out Certs For GitHub To Someone Who Just Had A GitHub Account

from the oops dept

For many years now, we've talked about the many different problems today's web security system has based on the model of security certificates issued by Certificate Authorities. All you need is a bad Certificate Authority to be trusted and a lot of bad stuff can happen. And it appears we've got yet another example.

A message on Mozilla's security policy mailing list notes that a free certificate authority named WoSign appeared to be doing some pretty bad stuff, including handing out certificates for a base domain if someone merely had control over a subdomain. This was discovered by accident, but then tested on GitHub... and it worked.

In June 2015, an applicant found a problem with WoSign's free certificate service, which allowed them to get a certificate for the base domain if they were able to prove control of a subdomain.

The reporter proved the problem in two ways. They accidentally discovered it when trying to get a certificate for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then confirmed the problem by using their control of theiraccount.github.com/theiraccount.github.io to get a cert for github.com, github.io, and www.github.io.

They reported this to WoSign, giving only the Github certificate as an example. That cert was revoked and the vulnerability was fixed. However recently, they got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later.

As you can imagine, this should be a cause for quite some concern:

The lack of revocation of the ucf.edu certificate (still unrevoked at time of writing, although it may have been by time of posting) strongly suggests that WoSign either did not or could not search their issuance databases for other occurrences of the same problem. Mozilla considers such a search a basic part of the response to disclosure of a vulnerability which causes misissuance, and expects CAs to keep records detailed enough to make it possible.

Mozilla also noted that WoSign never informed it of the earlier misissuance either. This is a pretty big mistake. The Mozilla post also calls out some questionable activity by WoSign in backdating certificates, but this first point is the really troubling one.

I recognize that until a better system is found, certificate authorities issuing certificates is about all we have right now for web security -- but, once again, it really seems like we need to be moving to a better solution.

Filed Under: certificate authority, https, security, ssl, subdomains
Companies: github, mozilla, wosign

Russian Censor Bans Comodo... Doesn't Realize Its Own Security Certificate Is From Comodo

from the ow!-my-foot!-shot-it-right-off! dept

The Russian government's state censorship organization, Roskomnadzor (technically its telecom regulator) has been especially busy lately as the government has continued to crack down on websites it doesn't like. However, as pointed out by Fight Copyright Trolls, it appears that Roskomnadzor may have gone a bit overboard recently, in response to a court ruling that had a massive list of sites to be banned (over a thousand pages). Apparently, as part of that, various sites associated with Comodo were all banned. That's pretty bad for a variety of reasons, starting with the fact that Comodo remains one of the most popular issuers of secure certificates for HTTPS.

In fact, as many quickly noted, Roskomnadzor's own website happens to be secured with a certificate from... Comodo: It's not entirely clear the impact of this, but the Rublacklist site appears to be implying (via my attempt at understanding Google translate's translation...) that this also means that sites that rely on Roskomnadzor's registry of sites to block... may be blocked from accessing the list. Because its own site is effectively blocked by the list. Oops.

Filed Under: ban list, censorship, https, roskomnadzor, russia, security certificate, ssl
Companies: comodo

Super Slimey: Comodo Tries To Trademark 'Let's Encrypt' [Updated]

from the that's-just-bad dept

See the update at the end

Almost two years ago, we excitedly wrote about the announcement behind Let's Encrypt, a free certificate authority that was focused on dramatically lowering the hurdles towards protecting much more of the internet with HTTPS encrypted connections. It took a while to launch, but it finally did and people have been gobbling up those certificates at a rapid rate and getting more and more of the web encrypted. This is a good thing.

Unfortunately, it appears the old guard of certificate authorities doesn't like this very much. Comodo, which has provided certificates for quite some time (and, in fact, is where Techdirt's certificate comes from) has apparently, somewhat ridiculously, been trying to trademark versions of "Let's Encrypt." The most troubling one is the one on purely "Let's Encrypt," but the other two (Comodo Let's Encrypt and Let's Encrypt with Comodo) are equally problematic -- especially since (as Comodo admits directly) it's never used that phrase in offering its existing certificates.

This seems like a clear situation where Comodo is seeking to confuse the market -- and thus the clear case where trademark law actually makes some sense. As we've said basically forever, trademark is quite different than copyrights and patents, in that it was really designed as a consumer protection law, to keep consumers from being tricked into buying something that they believe is from a different entity. Trademarks are widely and frequently abused, but there are times where the original intent of consumer protection makes sense, and this seems like one of them. What's incredible is that when Let's Encrypt reached out to Comodo about this, the company refused to abandon the attempt to trademark these names.

Since March of 2016 we have repeatedly asked Comodo to abandon their “Let’s Encrypt” applications, directly and through our attorneys, but they have refused to do so. We are clearly the first and senior user of “Let’s Encrypt” in relation to Internet security, including SSL/TLS certificates – both in terms of length of use and in terms of the widespread public association of that brand with our organization.

If necessary, we will vigorously defend the Let’s Encrypt brand we’ve worked so hard to build. That said, our organization has limited resources and a protracted dispute with Comodo regarding its improper registration of our trademarks would significantly and unnecessarily distract both organizations from the core mission they should share: creating a more secure and privacy-respecting Web. We urge Comodo to do the right thing and abandon its “Let’s Encrypt” trademark applications so we can focus all of our energy on improving the Web.

At the very least, this kind of stupid stunt has me reconsidering if we should ever use Comodo's certificates on our site going forward. We've been a happy Comodo customer for many years, but I hate supporting bullies. Update: And... of course, after this goes public, Comodo suddenly backs down. Of course that doesn't explain why it refused to do so when asked months ago.

Filed Under: certificate authority, certificates, competition, https, let's encrypt, trademark
Companies: comodo, let's encrypt

Want To Report A Dangerous Drug Dealer? Just Enter Your Personal Info Into The DEA's Unsecured Webform

from the we-know-all-about-you,-but-good-luck-finding-out-about-us dept

Chris Soghoian, the ACLU's chief technologist, has decided to troll the DEA. His complaint is valid, though. The problem is, how do you troll the DEA when it's almost impossible to find the contact info of the person you want to speak to? Just like the FBI has more options at its disposal than simply demanding Apple help it beat down an iPhone's front door, Soghoian was able to route around the DEA's unforthcoming attitude.

How to disclose a security flaw to the DEA.
1 Find CISO on LinkedIn.
2 Look up consulting company records.
3 Email.https://t.co/sRK56FSkEL

— Christopher Soghoian (@csoghoian) February 28, 2016

If you can't read/see the tweet, it says:

How to disclose a security flaw to the DEA.
1 Find CISO on LinkedIn.
2 Look up consulting company records.
3 Email.

The email address was harvested from a third-party website for a company DEA CISO Bret Stevens is apparently associated with, Innovative Security Solutions, Inc., conveniently located in northeastern Virginia, right outside of Washington, DC.


This site will allow you to edit company info, provided you can socially engineer your way into a position at the company. That being said, it looks loads better than the company's original site, which appears to have been last updated five minutes after the domain was registered (2004).


There's nothing on this site referring to Bret Stevens, current DEA security chief, but then again, the site doesn't appear to be subject to frequent updates. Or any updates.

Anyway, Soghoian wanted to point out a security flaw on the DEA's website. The DEA will accept tips from citizens. However, it does absolutely nothing to protect these helpful citizens. From Soghoian's notification email:

The DEA operates an online tip­form, through which individuals can report "possible violation of controlled substances laws and regulations. Violations may include the growing, manufacture, distribution or trafficking of controlled substances."

See: http://www.dea.gov/ops/submit.php

This website does not use HTTPS to protect the transmission of information. It should.

Quite correct. Not only has the Office of Management and Budget stated every agency must use HTTPS on all public-facing websites by the end of 2016, but you'd think a form that collects personal info about members of the public -- especially in conjunction with info about possibly armed and violent criminals -- would be given an extra layer of security. Apparently, the DEA is not all that concerned about its tips being scooped by criminals, or criminals intercepting unsecured tips in order to target do-gooders.

Soghoian's email also suggests the agency be a little more transparent about its security staff.

On a more general note, I would also like to encourage you to post publicly contact information for your information security team, so that researchers and other individuals can responsibly disclose flaws such as this issue. This is a best practice followed by some federal agencies, widely adopted by those in the private sector, and promoted as a best practice by the Federal Trade Commission.

If this email manages to reach Bret Stevens, it will likely be sneered/groused at before being discarded as the imperious communications of a meddling motormouth representing an entity far too concerned about the rights of all Americans, especially the guilty, drug-dealing ones. As for its unsecured tip form, it will likely remain unsecured until the DEA is finally forced into compliance with the OMB's instructions.

Use at your own risk.

Filed Under: bret stevens, chris soghoian, dea, failures, https, security

UK's Pirate Site Blocklist Even More Pointless Than Previously Thought: HTTPS Defeats It

from the almost-too-easy dept

It will come as no surprise to sophisticated Internet users like Techdirt readers that the UK's attempts to block a growing list of "pirate" sites are easy to circumvent. But a post on TorrentFreak suggests that you don't even need to be a sophisticated Techdirt reader to do that:

While it's hard to stamp out piracy completely, the measures were supposed make it harder for UK Internet subscribers to access these sites.

However, a recent review of current blocking practices shows that several ISPs including Virgin Media, BT, EE and TalkTalk are failing. It turns out that many subscribers don't have to jump through technological hoops to circumvent the blockades, as many popular pirate sites are freely accessible on their regular connections.

With the help from several subscribers, TorrentFreak was able to confirm that the HTTPS versions of most blocked websites including The Pirate Bay, KickassTorrents, RARBG and Torrentz, are still freely accessible.

Apparently this has been known in certain circles for quite a while. Some pirate sites have even gone so far as to force users to connect using HTTPS to enable them to enjoy this further advantage of encryption. There's an interesting discussion in the comments on the TorrentFreak post as to when and why HTTPS connections can get around the court-mandated blocks, and what ISPs might try to do to close this gaping loophole. Even if they do, the other circumvention methods will remain.

The real point here is that the copyright industries are fighting a war they cannot win. That's not just stupid in itself, but doubly stupid, because there's a much better approach that they could take, as Techdirt has noted before: all they need to do to stop most people visiting pirate sites is to offer a good service at a fair price. Simple, really. Almost as simple as using HTTPS.

Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+

Filed Under: copyright, encryption, filter, https, piracy, piracy list, site blocking, uk

Patent Troll Sues Everyone For Infringing On Encryption-Related Patent By Encrypting Their Websites

from the um,-we-actually-offer-no-encryption-services-of-our-own.-sorry. dept

Underdog Texas company takes on corporate giants!

Scores of big brands – from AT&T and Yahoo! to Netflix, GoPro and Macy's – are being sued because their HTTPS websites allegedly infringe an encryption patent.

It appears in May this year CryptoPeak Solutions, based in Longview, Texas, got its hands on US Patent 6,202,150, which describes "auto-escrowable and auto-certifiable cryptosystems."

CryptoPeak reckons TLS-secured websites that use elliptic curve cryptography are infringing the patent – so it's suing owners of HTTPS websites that use ECC. Top tip: loads of websites use ECC these days to securely encrypt their traffic.

CryptoPeak, of course, offers no cryptography products. It does, however, manage a portfolio of 66 lawsuits, all filed in the Texas Eastern District Court, beginning roughly 60 days after it acquired the patent. Among the illustrious names listed as defendants are PNC Financial Services, VUDU, Netflix, State Farm, Allstate, Petco, GoPro, Mary Kay, Target, Groupon, Williams-Sonoma, Etsy, Priceline… well, the list goes on and on and on.

All of these companies produce goods and services. CryptoPeak does not. The only thing it produces are lawsuits. The patent it's using in its litigation doesn't appear to actually cover the allegedly infringing activity it's suing over.

Perhaps crucially, [the patent] describes a means for "generating public keys" and "publishing public keys", and it's certainly true that ECC does involve generating public keys and using them.

But the patent is focused on "a key recovery agent to recover the user's private key or information encrypted under said user's corresponding public key" – which is really not the point of ECC.

Netflix, which has already moved to dismiss the suit against it, doesn't concern itself too much with the patent's supposed function. Instead, it argues the patent (along with the numerous lawsuits) should be invalidated/tossed because of other wording used in the patent paperwork itself.

The invalidity of the claims asserted here is cut and dry. The Asserted Claims recite “a method and apparatus.” Thus, a practitioner cannot know the scope of the Asserted Claims from reading them because they explicitly claim “separate statutory classes of invention,” an act expressly forbidden by the law. For this reason alone, these claims are invalid on their face, and the Court should declare so at this stage.

Netflix then points out the "method and apparatus" wording appears in multiple claims.


All of which should serve to kill the lawsuit and, possibly the patent, no matter how much the troll protests.

The defect in these claims is so glaring that CryptoPeak’s only choice is to request that the Court overlook the express words of the claims, construe the claims to read out certain language, or even correct the claims. CryptoPeak has done just that in its Amended Complaint, alleging that “[n]othwithstanding that [the claims] generically recite the existence of ‘apparatus’ in their preambles, each of the . . . Asserted Claims is a method claim . . . .” (Dkt. No. 21 at 4 (emphasis added).)

This request is improper and should be rejected. The Court must read the claims as written, “not as the patentees wish they [ ] were written.”

Seems like a solid argument, but CryptoPeak didn't file in this particular court just because it coincidentally happened to have rented a mailbox and an empty office in Longview, Texas shortly before filing the lawsuits. It filed in this court because magical things often happen for patent trolls -- wholly unrelated to the validity of their claims and their affected Texan accents. If this wasn't the case, then this particular district wouldn't be the IP shitmagnet that it is. If CryptoPeak can nail down a few settlements and licensing agreements, it makes the hassle and expense of serial filing worthwhile. And isn't that why our patent system was implemented in the first place?

Filed Under: encryption, https, patent troll, patents
Companies: at&t, cryptopeak solutions, etsy, gopro, groupon, macy's, netflix, petco, priceline, target, yahoo

Learning From Lenovo's Compounded Failures, Dell Apologizes For Its Own HTTPS Certificate Screw Up

from the yeah,-whoops dept

Dell this week found itself under fire for embedding a certificate in some PCs that makes it relatively easy for attackers to cryptographically impersonate HTTPS-protected websites. First discovered by a programmer named Joe Nord, Dell's eDellRoot certificate appears to have been preinstalled as a root certificate on several Dell laptop and desktop models. As Nord notes, it's relatively simple to extract the locally-stored key, sign fraudulent TLS certificates for any HTTPS-protected website on the Internet, and trick user browsers to accept these encrypted Web sessions with no security warnings whatsoever.This is, of course, reminiscent of the Superfish fiasco that plagued Lenovo earlier this year. But in that case the culprit was third-party adware, while Dell's eDellRoot is the company's own abomination. Duo Labs Security says it discovered the same problem, noting that it had even found evidence of the root certificate on some SCADA systems, typically used in places like factories, dams and power stations. Like Nord, Duo's researchers note that it's rather incredible that Dell wouldn't have discovered and fixed this problem after what happened to Lenovo:

"This highlights a disturbing trend among original equipment manufacturer (OEM) hardware vendors. Tampering with certificate stores exposes users to unnecessary, increased risk. Tampering with the certificate store is a questionable practice, and OEM’s need to be careful when adding new trusted certificates, especially root certificates. Sadly, OEM manufacturers seem to not be learning from historical mistakes and keep making them over and over."

However Dell did appear to learn something in terms of their PR response to the vulnerability. Unlike Lenovo, which originally tried to deny any security problem whatsoever, Dell has issued a relatively straight forward blog post addressing the issue. In it, Dell does something downright kooky: it admits that the vulnerability is a vulnerability, and publicly thanks the security researchers that discovered it. According to Dell, the certificate was implemented as part of a support tool "intended to make it faster and easier" for users to service their system.

Dell's quick to remind readers that at least it wasn't adware, and unlike Lenovo's snoopvertising, it won't stealthily hide in the BiOS to reinstall itself at a later date:

"The certificate is not malware or adware. Rather, it was intended to provide the system service tag to Dell online support allowing us to quickly identify the computer model, making it easier and faster to service our customers. This certificate is not being used to collect personal customer information. It’s also important to note that the certificate will not reinstall itself once it is properly removed using the recommended Dell process."

Dell's also posted a word document outlining how to spot and remove the certificate here for those interested. It remains unclear just how many computers are at risk, but given that Dell is expected to ship 10 million computers worldwide in the third quarter of 2015, the footprint likely isn't modest. And while Dell managed the problem better on the PR front than their predecessors, the fact that this keeps happening is no less disturbing.

Filed Under: certificates, https, self-signed certificate, superfish
Companies: dell, lenovo