Set up a Mozilla Persona testing server

added SponsorP TorBrowserTeam201410D component::archived/ponies owner::isis priority::high resolution::fixed status::closed type::project labels

Trac:
Cc: N/A to gk

Mike Perry kept lauting Persona while I was starting research on authentication mechanisms for BridgeDB's social distributor last summer/fall. I ended up setting up a Mozilla Persona server on my personal server for a while on patternsinthevoid.net (it's not up anymore though) to test it out, and, ultimately, to be able to log into the silly Tor Stack Exchange thingie that insisted on being MITMable and insecure.

Long story short: I've already read a few papers on it, and read their docs, and set one up. It's supposed to have changed some, but I could do it again.

@mikeperry: As a technical aside, why did you say

a number CAPTCHAs

plural? Why is solving 2-out-of-3 8-char CAPTCHAs better than solving 1 24-char CAPTCHA with 3 chars wrong? Is there something better about having plural CAPTCHAs? As a user, that would annoy the crap out of me; I would think I'd done something wrong.

If you want just the server, and you want it well-tested and scalable to a potentially high number of Tor clients who are waiting to pounce on it, then that would probably take me two months. I could plug the CAPTCHA system that I already made for BridgeDB into it pretty easily, I think.

If you want extra authentication systems, then I'd estimate 2 months extra, on top of setting up the server(s), for each auth mechanism that is simple. Simple RSA-based blind tokens probably count as simple. If you want crazy stuff for extra authentication systems, like BTC payments, that would need a bit of extra work to guarantee that any adversarial advantage for deanonymisation isn't introduced. I would estimate roughly 6 months extra work for implementing any more ambitious auth/PoW scheme.

Trac:
Cc: gk to gk, isis

Trac:
Keywords: N/A deleted, TorBrowserTeam201408D added

Trac:
Priority: normal to major

Trac:
Status: new to assigned
Owner: N/A to isis

Trac:
Cc: gk, isis to gk, isis, arlo@torproject.org

Trac:
Keywords: TorBrowserTeam201408D deleted, TorBrowserTeam201409D added

Trac:
Keywords: TorBrowserTeam201409D deleted, TorBrowserTeam201410D added

It's up and running behind an Apache reverse proxy. Turns out that this is the repo we wanted, not the actual "persona" one, for the record.

Preliminary thoughts from the process of setting it the Persona/BrowserID primary Identity Provider (IDP) server:

1. It's going to be hard enough just to run our own persona.torproject.org safely.

Persona/BrowserID are now unmaintained. (Although, [http://identity.mozilla.com/post/78873831485/transitioning-persona-to-community-ownership not "decommissioned"], which apparently means they intend to make critical security patches, if necessary.)

Both depend upon a (seemingly unmaintained) fork of `node.js` from a sketchy Ubuntu PPA.

2. It's going to be difficult to put new primitives into this thing.

Blind signatures are ''probably'' doable. As of right now, it appears as if it will only require a fork of [https://github.com/mozilla/browserid-crypto jwcrypto] with some patches. Anything fancier than that, however, and it's likely going to get hairy rather fast.

3. Persona/BrowserID were not designed to be anonymous.

There's all kinds of certification issuance timing correlations, identity certificate use correlations, etc. that we'll need to be worried about. Especially if we expect third parties to be able to do anything like "report a troll/abusive user" to us. Some of these I'm already aware of, but I may not find all of them.

My point being: we're using something for an unintended purpose, and we are going to need to be ''very'' careful about that.

4. I'm concerned about the lack of adoption by, and lack of support for, the third parties who will want to hand their Tor-using users to us.

Namely, if we were to go to the trouble of fixing all of the above things, that someone like Wikimedia is just going to be confused: ''"What do you expect me to do with these weird unblinded sigs your users are handing me?"''

Third parties, whom we expect to hand off their abuse mitigation to us, they are going to want to copy+paste some code and ItJustWorks™. Think of how one integrates Stripe, Paypal, etc. into a webpage. They are ''not'' going to want to say, ''"Okay, let me pay a developer to spend a month figuring out how this poorly documented, unmaintained Persona thing works, and have them write some code to integrate it into our site for you."''

Replying to isis:

3. Persona/BrowserID were not designed to be anonymous.

There's all kinds of certification issuance timing correlations, identity certificate use correlations, etc. that we'll need to be worried about. Especially if we expect third parties to be able to do anything like "report a troll/abusive user" to us. Some of these I'm already aware of, but I may not find all of them.

Which did you already find?

Another potential problem: Persona is not "decentralised". It's pseudo-federated and semi-centralised.

Any Relying Party (RP; a.k.a the third-party site that wishes to allow their users to login via Persona) must source an include.js file. There can only one primary IdP at a time, as the ipServer in these include.js files is hardcoded.

As such, for a RP to send its users to different IdPs, the RP would need to dynamically source different include.js files, depending on the IdP specified by the user. To my knowledge, no sites which support logging in through Persona have implemented this, meaning that all Persona-aware sites currently on the internet are hardcoded to send users to https://login.persona.org, https://login.anosrep.org, or https://login.dev.anosrep.org.

To see this in action:

Install the RequestPolicy Firefox plugin and configure it to use full addresses/domains.
Configure NoScript to deny everything by default.
Go to http://beta.123done.org, which is an example RP which uses Mozilla's Persona staging server (https://login.anosrep.org) as its IdP.
Open up the WebConsole and reload the http://beta.123done.org page.
Allow scripts from http://beta.123done.org. (You still won't have beta.123done.org's include.js file because they remotely source it.)
Allow requests from http://beta.123done.org to https://login.anosrep.org, and reload.
Allow scripts from https://login.anosrep.org. (You've now loaded the include.js file.)
At this point, if you have the dom.identity.enabled pref set to true (meaning you prefer that Persona implementations use Firefox's native navigator.mozId code, rather that the navigator.id fallback JS code) you must set it to false. The choice of whether or not to use native code versus JS is also not up to the user, and the two appear to be incompatible. If you had to change the pref, reload the http://beta.123done.org page. (This would seem to imply that the so-called "fallback" code isn't really a fallback, as once the pref is disabled, entering navigator.mozId into the WebConsole will return null.)
Go to the "Other origins" RequestPolicy menu and allow requests from https://login.anosrep.org to https://static.login.anosrep.org, and reload. (You should now see a Sign in… button.)
Click the Sign in… button. (You should now have either a new window/tab which loads https://login.anosrep.org/sign_in.)
Go to the "Other origins" RequestPolicy menu and allow requests from https://static.login.anosrep.org to https://login.anosrep.org, and reload. (Hooray! Your tab/window now magically closes because Persona expects you to allow sourcing shit from all over the web. Sorry for all the steps, and, yes, this one is the fault of RequestPolicy, but it's important to understand what's actually happening.)
Do Step !#10 (closed) again.
In the new/window tab that has opened, type whatever@mockmyid.com (mockmyid is an IdP which automatically signs *@mockmyid.com without authentication) into the email address input field. Click next.
Allow requests from https://login.anosrep.com to https://mockmyid.com, and reload. (Hooray! Again! Your tab/window is gone!)
Do Steps !#10 (closed) and !#13 (closed) again.
Go to the "Other origins" RequestPolicy menu and allow requests from https://mockmyid.com to https://login.anosrep.org, and close the tab/window. (At least this time there's a error page...)
Do Steps !#10 (closed), and !#13 (closed), again. (Finally, the tab/window says you're logged in, closes itself, and you're back on the http://beta.123done.org page logged in as whatever@mockmyid.com.)

I've implemented a Persona IdP at https://https://93.95.228.166/. It's probably still buggy but I can't test further because we need a domain and valid^Wpurchased certificate for it. It's similar to mockmyid.com, except even more lenient, in that it currently signs literally anything.

If you want to imagine the "under-the-hood" (assuming they don't block scripts and aren't using RequestPolicy) steps taken for our users to login to the RP (Wikipedia for example), then (assuming we've talked Wikipedia into sourcing our include.js file) do 's/beta\.123\.org/wikipedia\.com/' and 's/login\.anosrep\.org/93\.95\.228\.166/' on the above steps.

I'm honestly a bit ashamed for Mozilla that they designed something so horrible.

I'm also inclined to believe that this is a blocker, meaning "there is no feasible way that we could ever actually use and massively deploy Persona to allow for 'anonymous' logins". Any real deployment of whatever we could build out of Persona's scraps of code is either going to result in RPs 1) sending Tor users to login.persona.org, or 2) being forced to source our JS.

Opinions? Is this a blocker? Should I move forward with this thing?

Trac:
Status: assigned to needs_review

Replying to isis:

I'm also inclined to believe that this is a blocker, meaning "there is no feasible way that we could ever actually use and massively deploy Persona to allow for 'anonymous' logins". Any real deployment of whatever we could build out of Persona's scraps of code is either going to result in RPs 1) sending Tor users to login.persona.org, or 2) being forced to source our JS.

To expand upon my previous statement above, the previously mentioned problem essentially boils down to forcing us to choose between one of two options for real-world deployment:

Option 1

We would need to accept that our so-called "anonymous" users would be sent from the website they are trying to log into (Wikipedia, for example) to https://login.persona.org, and that the latter would speak to the Tor Project IdP.

There is not even remotely a chance for even pseudonymity, if we went this route, as the https://login.persona.org server could:

Log which websites a Tor user tries to log into,
Log when a Tor user tried to log into or out of any website,
Potentially link a user's pseudonyms (yes, even if we handed out blinded signatures in our credentials),
Arbitrarily decide to block all Tor users without the consent of either Wikipedia or the Tor Project IdP,
and probably a bunch of other horrible stuff.

Option 2

We would need to try to force every single website that wants to allow anonymous users to login to source custom Javascript that we make available, which is specific to allowing logins from our IdP. Our custom Javascript would be specific to allowing logins from our IdP. Overall, it means we'd be expecting everyone on the internet (including every other Persona server) to trust us, and/or we'd break half the things for half the people (by "people", I mean "anyone using Persona whether they are using our primary IdP or someone else's").

For example, if we went this route, and put the Tor Project IdP at https://persona.torproject.org, and we convinced Wikipedia to use our code on their login page, this would mean:

'''ex. 1A1: Alice the Mozilla employee tries to log in to Wikipedia using Persona.'''

She would be sent to https://login.persona.torproject.org where she'd enter `alice@mozilla.org` into the email input field.  Our IdP would talk to https://persona.mozilla.org to determine if Alice's credential is valid.

'''RESULT:''' The website's login works successfully, but the Tor Project Persona IdP gets to know a lot of details about Alice that it really shouldn't be allowed to know.

We could, of course, add some error handling around our customised Javascript which makes the file only actually get sourced for Tor Browser users. One might naïvely think that this would fix Alice's example above.

If we continue trying to use Persona, and we continue to try to use our own primary IdP, we would need to set, by default, the following Tor Browser preference: dom.identity.enabled true to enable Firefox's native Persona code. This causes the navigator.mozId attribute become available, [4] and causes, on a Persona-enabled site, the navigator.id attribute to be missing. All current Persona-aware websites source the official Mozilla Persona Javascript. Mozilla's documentation states that navigator.id is a "fallback implementation of navigator.mozId for compatibility", but the two appear to be entirely incompatible. I tried everything to get the two implementations to play nicely together; I tested both variants for the Tor Project IdP that I created, with every variant of revelant preference settings; I eventually dug around through Firefox's source code, and realised the two were incompatible, and then asked questions in both #identity and #developers on irc.mozilla.org.

Therefore, because we must set the dom.identity.enabled pref, and every Persona-aware site on the internet uses the official Mozilla Javascript, we would be completely, entirely incompatible with the rest of Persona infrastructure on the internet (and likewise make the rest incompatible with us). Half the sites would be broken for half the people, all the time. What I'd consider to be privacy violations would happen on both sides, and end-user usability (as if Persona weren't already unusable enough for providers and websites) starts to drop into the GnuPG range.

To demonstrate how broken this would make absolutely everything, let's look at another set of examples! These examples are exactly the same as example 1A1, except now, Wikipedia is using our "improved" custom Javascript which has some error handling. Said Javascript it only ever fully executes for Tor Browser users, and for regular Firefox users it displays a message saying that they need to toggle a preference. Amazon is also in the game now, except that they're running the official Mozilla Persona Javascript. You can skip these examples if you don't care about the details of how we'd potentially break everything.

ex. 2A1: Alice from Mozilla (meaning they have an @mozilla.org account, or an @persona.org account) uses Tor Browser to log in to Wikipedia.

She clicks the friendly `Login with Persona` button, and everything in example '''1A1''' happens in exactly the same way. The Tor Project gets a record of Alice's browsing habits, and the "horrible things" from Option !#1 above would happen, except with the tables turned.

(Unless she also has, or registers for, an `alice@persona.torproject.org` account, then she could use that to log in without the Tor Project IdP talking to the Mozilla server... but then that case would be example '''2B1'''.)

'''RESULT:''' The website's login works successfully, but the Tor Project Persona IdP gets to know a lot of details about Alice that it really shouldn't be allowed to know. Because we control the JS and the browser in this case, we could modify the way the `Login with Persona` button works, e.g. to cause it to display a dropdown where Alice selects her IdP from a list before being sent to the IdP.  ''It is important to note that, regardless of how much we "fix" the Persona `include.js` file, we'll always be incompatible with the rest of official Persona.''

ex. 2A2: Alice from Mozilla uses regular Firefox (or, anything not TBB) to log in to Wikipedia.

She clicks the friendly `Login with Persona` button, and nothing happens.  Well, almost nothing; our [https://github.com/isislovecruft/browserid-certifier/blob/master/srv/login.persona.torproject.org/document_root/browserid/signin.js#L70 error handler does something] like displaying a message which explains that she needs to toggle a browser preference.

'''RESULT:''' The website is effectively broken.

ex. 2A3: Alice from Mozilla uses Tor Browser to log in to Amazon.

She clicks the `Login with Persona` button, and nothing happens. Well, almost nothing; a single error message goes to her TB WebConsole: "TypeError: navigator.id is undefined", but she'll probably never see it.

'''RESULT:''' The website is completely broken.

ex. 2A4: Alice from Mozilla uses regular Firefox to log in to Amazon.

She clicks the `Login with Persona` button, and she's sent to https://login.persona.org where she uses her `alice@mozilla.org` account to log in.

'''RESULT:''' Everything's fine.

ex. 2B1: Barbara the Tor user (meaning they have an account with the Tor Project IdP) uses Tor Browser to log in to Wikipedia.

She clicks the `Login with Persona` button, and she's sent to https://persona.torproject.org where she uses her `barbara@persona.torproject.org` account to log in.

'''RESULT:''' Everything's fine.

ex. 2B2: Barbara the Tor user uses regular Firefox to log in to Wikipedia.

She clicks the `Login with Persona` button, and our error handler displays a message which explains that she needs to toggle a browser preference in order to log in to Wikipedia.

'''RESULT:''' The website is effectively broken.

ex. 2B3: Barbara the Tor user uses Tor Browser to log in to Amazon.

She click the `Login with Persona` button, and Amazon tries to send her to https://login.persona.org, but can't.  The button doesn't do anything, and Barbara can't log in because her browser has the `dom.identity.enabled` preference set. Somewhere in her TBB WebConsole, there's an error message that says: `TypeError: navigator.id is undefined`, but Barbara probably won't see it.

'''RESULT:''' The website is completely broken.

ex. 2B4: Barbara the Tor user uses regular Firefox to log in to Amazon.

She clicks the `Login with Persona` button, and she's sent to https://login.persona.org where she uses her `barbara@persona.torproject.org` account to log in.  The Mozilla Persona IdP gets a record of Barbara's browsing habits, and the "horrible things" from Option !#1 above would happen.

'''RESULT:''' The website's login works successfully, but the Mozilla Persona IdP gets to know a lot of details about Barbara that it *super* shouldn't be allowed to know.

All the previous examples essentially mean that, even if we control the code in the user's browser and the Javascript which a website sources to allow for Persona logins, we'll never be compatible with the rest of the official Mozilla Persona infrastructure and any sites which use it. There will confusingly be two things called "Persona" which will never be fully-interoperable.

So, as I said previously, we would be essentially be forcing every Persona-aware website on the internet to source our custom Javascript.

I think we can all agree that Option !#1 is unacceptable.

I hope we can also agree that Option !#2 (closed) is never going to happen. Even if it did happen, we don't want to be a single point of failure for other Persona-aware things on the internet, nor do we want become the internet equivalent of the Berlin Wall. Additionally, if we actually expect online services to be sourcing our code, and we're insane enough to think this is deployable, scalable, maintainable, and a good idea, we should probably avoid limiting ourselves to Persona's constraints when we could just as easily start from scratch and write our own code the way we would like to see it done, without increasing the overall deployment and adoption difficulty. We would essentially be taking over maintenance of Persona from Mozilla, and we should pay attention to the fact that Mozilla pulled support for the project because of lack of adoption.

Additionally, my code for all of this is here and the code for the Tor Project IdP server website is in that same repository, in the srv/login.persona.torproject.org/ directory.

Ok, I am calling this fixed. We have a testing server, and it made it clear that Persona is not capable of being what we want here.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

closed

Set up a Mozilla Persona testing server

Child items 0

Activity

Option 1

Option 2