1032738 - Desktop client fails to authenticate session tokens with the latest loop server

Status: VERIFIED FIXED

(Hello (Loop) :: Client, defect, P1)

Description

[Mark Banner (:standard8)]

This is broken with the latest loop server (0.7.0), but it is working with production (0.5.0 iirc).

STR:

1) Run latest Nightly, set the loop.server pref to "http://loop.dev.mozaws.net"
2) Restart Nightly, let it register (this is expected to fail if you've changed the value of the pref, it'll be logged to the console)
2) Stop nightly, start it up with -jsconsole, so that you can see what's happening.

Expected results

The /registration call should succeed with 200.

Actual results

The /registration call fails with 401 Unauthorized, looking at the response headers we see:

WWW-Authenticate:  Hawk error="Bad mac"


Added notes:

There's currently two implementations of hawk we're using in the client (bug 1020876 will fix this to use the gecko one). The broken version is the one used with /registration - /call_url seems to work on the nightly build.

The interesting differences are that the /registration version has both hash and mac parameters, whereas the /call_url version just has a mac parameter.

The gecko impl of hawk for /registration starts in:

http://hg.mozilla.org/mozilla-central/annotate/606848e8adfc/browser/components/loop/MozLoopService.jsm#l151

and most of the hawk code is in /services/common/

The content impl of hawk for /call_url starts in:

http://hg.mozilla.org/mozilla-central/annotate/83c09fe3a658/browser/components/loop/content/shared/js/client.js#l172

(there's some libraries in browser/components/loop/content/shared/libs)

Comment 1

[Rémy Hubscher (:natim)]

Well we have a similar problem with MSISDN.

I think the problem can come from the port value.

http://mxr.mozilla.org/mozilla-central/source/services/crypto/modules/utils.js#517

Here I will investigate that.

Comment 2

[Rémy Hubscher (:natim)]

Attachment: Link to github PR

Comment 3

[Alexis Metaireau (:alexis)]

So it seems the client is faulty here, I'll let Mark explain why and submit a patch.

Comment 4

[Alexis Metaireau (:alexis)]

Comment on attachment 8448706 [details] [review]
Link to github PR

Landed a fix for the server (that will work better for SSL envs when the port is not proxified the right way).

https://github.com/mozilla-services/loop-server/commit/797a65a65a36a6b5528784225b96d1a5d4dffb61

Comment 5

[Mark Banner (:standard8)]

Attachment: Desktop client fails to authenticate session tokens with the latest loop server - change to using a hex key for hawk.

This changes the client to use a hex key for the credentials.key. This makes us authenticate correctly with the server (we didn't before as the server wasn't so strict/correct).

I have to admit I don't quite understand why we need this change, but it all seems to work fine with it.

Jed, do you mind reviewing this as markh is out?

Comment 6

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Comment on attachment 8448968 [details] [diff] [review]
Desktop client fails to authenticate session tokens with the latest loop server - change to using a hex key for hawk.

Review of attachment 8448968 [details] [diff] [review]:
-----------------------------------------------------------------

I don't know anything about the Loop server, but if using hex credentials fixes the problem, this patch certainly looks good to me.

Perhaps it's already there, but it might be good for the server to have a test for this, and maybe a link to this bug in the comments, explaining the formatting requirements.

Comment 7

[Mark Banner (:standard8)]

https://hg.mozilla.org/integration/fx-team/rev/4581563eaebf

Rémy, do we have a server test? (as per previous comment)

Comment 8

[Rémy Hubscher (:natim)]

Do we have a server test for Hawk logging? Yes.

Some here https://github.com/mozilla-services/loop-server/blob/master/test/hawk_test.js
And basically all function tests.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4581563eaebf

Comment 10

[James Bonacci [:jbonacci]]

+ Martijn from QA

Comment 11

[Alexis Metaireau (:alexis)]

Jed, do you know if such tests exist for the identity servers?
What should we be testing exactly here?

Comment 12

[u279076]

James, what needs to be tested here?

Comment 13

[Paul Silaghi, QA [:pauly]]

Using the STR in comment 0, I see both in Nightly 2014-07-01 and FF 33b1:
"push.services.mozilla.com : server does not support RFC 5746, see CVE-2009-3555
Failed to register with the loop server. error: [object Object] MozLoopService.jsm:268
"Error registering with Loop server, code: 999" client.js:145"
Thoughts?

Comment 14

[James Bonacci [:jbonacci]]

Clearning the need info field for jed parsons.

:pauly please try again now - you might have caught the loop-server in mid-update and release, since version 0.11.0 just went out.

Can we get client dev to take another look at this please?

Comment 15

[Paul Silaghi, QA [:pauly]]

(In reply to James Bonacci [:jbonacci] from comment #14)
> :pauly please try again now - you might have caught the loop-server in
> mid-update and release, since version 0.11.0 just went out.
Same results in Nightly 2014-07-01, FF 33b1, 33b2.
In nightly 35.0a1 (2014-09-08):
push.services.mozilla.com : server does not support RFC 5746, see CVE-2009-3555
"Loop hawkRequest error:" Object { code: 404, errno: 999, error: "Resource not found." } MozLoopService.jsm:235
Failed to register with the loop server. error: [object Object] MozLoopService.jsm:316
"Error registering with Loop server, code: 999" client.js:89

Comment 16

[Tarek Ziadé (:tarek)]

> "Loop hawkRequest error:" Object { code: 404, errno: 999, error: "Resource not found." }

Looks like we are hitting the wrong URL here, as the Loop server sends back a 404. Reopening this bug so we can investigate

Comment 17

[Tarek Ziadé (:tarek)]

Bob or Benson, I am not sure where to find the 40x in our server logs. Is this something we have right now?

Comment 18

[Mark Banner (:standard8)]

This bug was fixed back in 33 a couple of months ago, I believe the normal gecko procedure is to file a new bug, as it is likely a regression.

FWIW, it is working fine for me.

Comment 19

[Mark Banner (:standard8)]

Debugging with Tarek over irc, we found there was a trailing slash on the end of the url for the loop.server pref. With this removed (as per the default value), connecting to the loop server worked fine.

I filed bug 1064862 for considering to cope with the trailing slash on the url.

Comment 20

[James Bonacci [:jbonacci]]

OK. Thanks. Removing the NeedInfo requests and closing out this bug.