Mozilla Nederland LogoDe Nederlandse

Wladimir Palant: Keybase: "Our browser extension subverts our encryption, but why should we care?"

Mozilla planet - to, 06/09/2018 - 10:50

Two days ago I decided to take a look at Keybase. Keybase does crypto, is open source and offers security bug bounties for relevant findings — just the perfect investigation subject for me. It didn’t take long for me to realize that their browser extension is deeply flawed, so I reported the issue to them via their bug bounty program. The response was rather… remarkable. It can be summed up as: “Yes, we know. But why should we care?” Turns out, this is a common response, see update at the bottom.

What is Keybase?

The self-description of Keybase emphasizes its secure end-to-end encryption (emphasis in original):

Imagine a Slack for the whole world, except end-to-end encrypted across all your devices. Or a Team Dropbox where the server can’t leak your files or be hacked.

So the app allows you to exchange messages or files with other people, with the encryption happening on sender’s computer in such a way that decryption is only possible by the designated recipient. This app is available for both desktop and mobile platforms. And for desktop you get a bonus: you can install the Keybase browser extension. It will add a “Keybase Chat” button to people’s profiles on Facebook, Twitter, GitHub, Reddit or Hacker News. This button allows you to connect to people easily.

Clicking the button will open a chat window and allow you to enter a message directly in the browser. Only after that initial message is sent the conversation will be transferred to the Keybase app.

So what’s the issue?

The issue here is a very common one, merely a week ago I listed it as #6 in this article. The extension injects its user interface (the button and the chat window) into third-party websites, yet it fails to isolate it from these websites. So the first consequence is: the Keybase message you enter on Facebook is by no means private. Facebook’s JavaScript code can read it out as you type it in, so much for end-to-end encryption. This is quite contrary to the promise Keybase still makes on their Mozilla Add-ons and Chrome Web Store installation pages.

Don’t believe that Facebook would intentionally spy on you? Maybe not, but by now it is pretty common to protocol all of user’s actions, for “site optimization” purposes — this includes anything entered into text fields of course. But in my opinion, that’s not even the worst issue.

A website could do more than passively spying on you. It could just as well instrument the Keybase user interface in order to send messages in your name, while also making this user interface invisible so that you don’t notice anything. Why would Facebook want to do something like that? Not necessary them, rather anybody who discovered a Cross-Site Scripting (XSS) vulnerability in one of the websites that Keybase integrates with. So if hundreds of people complain about you sending them spam messages via Keybase, it might be somebody exploiting the Keybase extension on your computer via an XSS vulnerability in Reddit. Have fun explaining how you didn’t do it, even though the messages were safely encrypted on your computer.

What does Keybase think about this?

According to Keybase, “this is all clearly described on the install page and is known.” In fact, close to the bottom of that page you find the following:

What if my browser is compromised?

The Keybase extension uses a compose box inside your browser. If you fear your browser or the social network site’s JavaScript has been compromised — say by another extension or even the social network acting fishy — then just compose the message inside the Keybase app directly. Or send a quick hello note through the extension and save the jucier private details for inside the app.

To me, this is thoroughly confusing. First of all, “browser is compromised” to me sounds more like malware. Trouble is, malware affecting the browser will affect the Keybase app just as well, so the advise makes no sense. But let’s say that it really is “the social network acting fishy,” how are you supposed to know? And is Facebook spying on you “fishy” or just its usual self?

It’s not that this issue is unavoidable. Avoiding it is fairly easy, by isolating all of the extension’s user interface in an <iframe> element. This would prevent both the website and other extensions from accessing it. Disaster averted, nothing to see here. But according to Keybase:

there were technical reasons why iframes didn’t work, though I forget the details

I translate this as: “Using iframes required a slightly more complicated approach, so we couldn’t figure it out.” Also:

It’s such a minor feature for us, it’s not worth a fix.

I translate this as: “We will keep pushing this extension because it gets users to promote our app for free. But we don’t care enough to make it secure.”

And now?

The only advise I can give you: uninstall the Keybase browser extension ASAP. As to the app itself, it might be secure. But as experience shows, the claim “end-to-end encryption” doesn’t automatically translate into a secure implementation. Initially, I planned to take a closer look at the crypto in Keybase, to see whether I can find weaknesses in their implementation. But that’s off the table now.

Update (2018-09-10): After I wrote this, EdOverflow pointed out that he made a similar experience with Keybase in the past. He could demonstrate that the domain ownership validation approach used by Keybase is flawed, yet Keybase wasn’t really interested in fixing this issue. Why they don’t require their keybase.txt file to be always located within the .well-known/ directory is beyond me, it solves the security issue here without any obvious downsides.

And then I also found this older vulnerability report on HackerOne about the Keybase extension opening up XSS issues on websites. The reporter recommended staying clear of innerHTML and using safe DOM methods instead, something that I have also been preaching for years. The response he received sounded very familiar:

There was some reason our extension developer decided against that approach, though he agrees it’s better in theory.

In other words: “We don’t know how to do it, but we’ll claim that we have a good reason instead of asking for help.”

Categorieën: Mozilla-nl planet

Daniel Stenberg: DoH in curl

Mozilla planet - to, 06/09/2018 - 09:26

DNS-over-HTTPS (DoH) is being designed (it is not an RFC quite yet but very soon!) to allow internet clients to get increased privacy and security for their name resolves. I've previously explained the DNS-over-HTTPS functionality within Firefox that ships in Firefox 62 and I did a presentation about DoH and its future in curl at curl up 2018.

We are now introducing DoH support in curl. I hope this will not only allow users to start getting better privacy and security for their curl based internet transfers, but ideally this will also provide an additional debugging tool for DoH in other clients and servers.

Let's take a look at how we plan to let applications enable this when using libcurl and how libcurl has to work with this internally to glue things together.

How do I make my libcurl transfer use DoH?

There's a primary new option added, which is the "DoH URL". An application sets the CURLOPT_DOH_URL for a transfer, and then libcurl will use that service for resolving host names. Easy peasy. There should be nothing else in the transfer that changes or appears differently. It'll just resolve the host names over DoH instead of using the default resolver!

What about bootstrap, how does libcurl find the DoH server's host name?

Since the DoH URL itself typically is given using a host name, that first host name will be resolved using the normal resolver - or if you so desire, you can provide the IP address for that host name with the CURLOPT_RESOLVE option just like you can for any host name.

If done using the resolver, the resolved address will then be kept in libcurl's DNS cache for a short while and the DoH connection will be kept in the regular connection pool with the other connections, making subsequent DoH resolves on the same handle much faster.

How do I use this from the command line?

Tell curl which DoH URL to use with the new --doh-url command line option:

$ curl --doh-url How do I make my libcurl code use this? curl = curl_easy_init(); curl_easy_setopt(curl, CURLOPT_URL, ""); curl_easy_setopt(curl, CURLOPT_DOH_URL, ""); res = curl_easy_perform(curl); Internals

Internally, libcurl itself creates two new easy handles that it adds to the existing multi handles and they are then performing two HTTP requests while the original transfer sits in the "waiting for name resolve" state. Once the DoH requests are completed, the original transfer's state can progress and continue on.

libcurl handles parallel transfers perfectly well already and by leveraging the already existing support for this, it was easy to add this new functionality and still work non-blocking and even event-based correctly depending on what libcurl API that is being used.

We had to add a new little special thing that makes libcurl handle the end of a transfer in a new way since there are now easy handles that are created and added to the multi handle entirely without the user's knowledge, so the code also needs to remove and delete those handles when they're done serving their purposes.

Was this hard to add to a 20 year old code base?

Actually, no. It was surprisingly easy, but then I've also worked on a few different client-side DoH implementations already so I had gotten myself a clear view of how I wanted the functionality to work plus the fact that I'm very familiar with the libcurl internals.

Plus, everything inside libcurl is already using non-blocking code and the multi interface paradigms so the foundation for adding parallel transfers like this was already in place.

The entire DoH patch for curl, including documentation and test cases, was a mere 1500 lines.


This is merged into the master branch in git and is planned to ship as part of the next release: 7.62.0 at the end of October 2018.

Categorieën: Mozilla-nl planet

Chris H-C: The End of Firefox Windows XP Support

Mozilla planet - wo, 05/09/2018 - 17:25

Firefox 62 has been released. Go give it a try!

At the same time, on the Extended Support Release channel, we released Firefox ESR 60.2 and stopped supporting Firefox ESR 52: the final version of Firefox with Windows XP support.

Now, we don’t publish all-channel user proportions grouped by operating system, but as part of the Firefox Public Data Report we do have data from the release channel back before we switched our XP users to the ESR channel. At the end of February 2016, XP users made up 12% of release Firefox. By the end of February 2017, XP users made up 8% of release Firefox.

If this trend continued without much change after we switched XP users to ESR, XP Firefox users would presently amount to about 2% of release users.

That’s millions of users we kept safe on the Internet despite running a nearly-17-year-old operating system whose last patch was over 4 years ago. That’s a year and a half of extra support for users who probably don’t feel they have much ability to protect themselves online.

It required effort, and it required devoting resources to supporting XP well after Microsoft stopped doing so. It meant we couldn’t do other things, since we were busy with XP.

I think we did a good thing for these users. I think we did the right thing for these users. And now we’re wishing these users the very best of luck.

…and that they please oh please upgrade so we can go on protecting them into the future.



Categorieën: Mozilla-nl planet

Mozilla libera o Firefox 62

Nieuws verzameld via Google - wo, 05/09/2018 - 17:20
  1. Mozilla libera o Firefox 62  SempreUPdate Notícias (liberação de imprensa) (Blogue)
  2. Full coverage
Categorieën: Mozilla-nl planet