1017906 - audit client-side hawk usage for security

Status: RESOLVED INCOMPLETE

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

Description

[Dan Mosedale (:dmosedale, :dmose)]

Right now, we make the simplest use of Hawk possible in the client.  It could be that it's worth our time to do more sophisticated things for better security (eg track clock skew like the services hawk client does <http://dxr.mozilla.org/mozilla-central/source/services/common/hawkclient.js#88>).

http://dxr.mozilla.org/mozilla-central/source/services/common/hawkclient.js#88

https://github.com/hueniverse/hawk#security-considerations has plenty to say here, and the client hawk code at <https://github.com/hueniverse/hawk/blob/master/lib/browser.js#L17> has some relevant options.

That said, given that we're intending to do everything over HTTPS by the time we hit MVP, maybe these security tightening measures don't actually add anything for us.

My guess is that sitting down with Chris Karlof or somebody on his team (eg Brian Warner, Zack Carter) would probalby be the most efficient way to figure out what makes sense here.

Comment 1

[:shell escalante]

Hi Curtis,  
Hi Chris,

At this point we've had a lot of folks looking at the Hawk code - so a full audit seems like it could wait for Fx36 dev cycle (when we slow down and have the changes that were added with FxA).  based on dan's comments on the https and the amount of folks that have looked at this area - are you OK with waiting to Fx36?

Comment 2

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

(In reply to sescalante from comment #1)
> Hi Curtis,  
> Hi Chris,
> 
> At this point we've had a lot of folks looking at the Hawk code - so a full
> audit seems like it could wait for Fx36 dev cycle (when we slow down and
> have the changes that were added with FxA).  based on dan's comments on the
> https and the amount of folks that have looked at this area - are you OK
> with waiting to Fx36?

Adam (:adamm) is most familiar with this code and the implications, so I will defer the decision to him

Comment 3

[Adam Muntner [:adamm] (use NEEDINFO)]

This issue also affects the FxA API (https://bugzilla.mozilla.org/show_bug.cgi?id=1048976) and probably other services. 

We (Mozilla) don't have a specific stance on what, specifically, we're OK with protected with SSL, without using other forms of protection. 

I've also heard rumblings about moving off Hawk entirely to something else - if so, the opportunity to define this kind of encryption standard would move to that initiative - reviewing Hawk would have quickly diminishing returns.

Comment 4

[Chris Karlof [:ckarlof]]

We use Hawk as a way to do request signing in the FxA, Loop, and MSISN verification APIs, and a security review of our use of it is likely worthwhile. 

For future APIs we build that rely on FxA, I expect us to use our FxA OAuth infrastructure, which uses Bearer tokens for authentication. However, there are no plans to deprecate the v1 API for FxA anytime soon, which uses Hawk for authentication.

We do not enforce replay protection at the Hawk layer, and instead rely on SSL to resist transport level attacks.

Comment 5

[Mark Banner (:standard8)]

Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.