Closed Bug 1032738 Opened 5 years ago Closed 5 years ago

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

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla33

People

(Reporter: standard8, Assigned: standard8)

Details

(Keywords: regression)

Attachments

(2 files)

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)
Severity: normal → blocker
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.
Assignee: nobody → rhubscher
Attached file Link to github PR
Attachment #8448706 - Flags: review?(alexis+bugs)
Whiteboard: [qa+]
So it seems the client is faulty here, I'll let Mark explain why and submit a patch.
Assignee: rhubscher → nobody
Component: Server → Client
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
Attachment #8448706 - Flags: review?(alexis+bugs) → review+
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?
Attachment #8448968 - Flags: review?(jed+bmo)
Assignee: nobody → standard8
Priority: -- → P1
Target Milestone: --- → 33 Sprint 2- 7/7
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.
Attachment #8448968 - Flags: review?(jed+bmo) → review+
https://hg.mozilla.org/integration/fx-team/rev/4581563eaebf

Rémy, do we have a server test? (as per previous comment)
Flags: needinfo?(rhubscher)
OS: Mac OS X → All
Target Milestone: 33 Sprint 2- 7/7 → mozilla33
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.
Flags: needinfo?(rhubscher)
https://hg.mozilla.org/mozilla-central/rev/4581563eaebf
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
+ Martijn from QA
Jed, do you know if such tests exist for the identity servers?
What should we be testing exactly here?
Flags: needinfo?(jed+bmo)
James, what needs to be tested here?
Flags: qe-verify+
QA Contact: jbonacci
Whiteboard: [qa+]
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?
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?
Flags: needinfo?(jed+bmo)
(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
> "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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Bob or Benson, I am not sure where to find the 40x in our server logs. Is this something we have right now?
Flags: needinfo?(bwong)
Flags: needinfo?(bobm)
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.
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
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.
OK. Thanks. Removing the NeedInfo requests and closing out this bug.
Status: RESOLVED → VERIFIED
Flags: needinfo?(bwong)
Flags: needinfo?(bobm)
You need to log in before you can comment on or make changes to this bug.