push-notes

 
"""
=======================================
OBJECTIVES
=======================================

[1]. MIMICRY:  client <---> 3rd party <---> Push service
[2]. SPOOFING: client <---> 3rd party <---> Push service
[3]. END RESULT: SUCCESSFUL BRUTE-FORCE ATTACK

NOTE:
error-code checking should be done by unit tests


=======================================
BASIC FLOW
=======================================

------------
IGNORE
------------

[1]. CONNECT (client) 

   - connect to websocket via ws(s)://

[2]. HELLO (client)

   - first time submits a blank UAID, receives one from server
   - afterwards, submits existing UAID, if any (stored) messages, they now get
     delivered 


------------
SPOOFING
------------
     
[3]. REGISTER (client <--> server)

   - main point: get an endpoint URL (w/ encoded UUID)
   - does every notification we want to send require a unique registration?
   - i.e. if i want to send 10 unique notifications and then ack them later??


[4]. PUBLISH (3rd party)

   - hidden within ap-loadtester
   - 3rd party site publishes an update
   - vapid exposes header here!

[5]. EXPECT NOTIFICATION (client)

   - client saying: "Hey, I'm interested! (subscribe my ass)" 

[6]. ACK (client) 
   - "Yes, I've received notification! (so you can stop sending)" 


------------
IGNORE
------------

[6]. UNREGISTER 

[7]. DISCONNECT 



=======================================
GLOSSARY
=======================================

[1]. UAID 
     - unique ID received by client

[2]. CHID
     - unique channel ID (1 per 3rd party app)
     - a client could be registered with multiple 3rd party apps
       (and a have a diff CHID for each)

[3]. endpoint:

http://push/update/..UAID..+..CHID../
                  /<-- encrypted -->/
     
[4]. registration "version" = message id


=======================================
ENCRYPTION OVERVIEW 
=======================================

[1]. endpoint encryption

    - covered by spoofing token in operation tests

[2]. Vapid

    - everything publicly exposed!
    - we only base64urlencode for transport (as URL) 
    - to do this we'll spoof the following:

      (a) header authorization
      (b) crypto-key
      (c) replace entire header with default-sized crap
      (d) replace entire header with variable-sized crap

[3]. client-key encryption
     - the 3rd party does this so this key will only be a 'passthru'
       (aka: wouldn't benefit us to spoof this)



=======================================
VAPID - how it's done
=======================================

[1]. 3rd party uses some tool to create an EC keypair

[2]. (a)                    (b) 
     type: JWT, alg:ECDH3   aud: http://example.com
                            sub: mailto: [email protected]
                            exp: 123....3

[3] urlsafe_base64encode(2a) + "." + urslafe_base64encode(2b)
    (a) Example: "abc+193--.qrs492--"
[4] urlsafe_base64encode(ECPrivateKey.sign(3a))

[5].  3a + "." + 4 = "abc--.grs--.foo---"

[6]. Headers:
         Authorization: Bearer  abc--.qrs--.foo---
         Crypto-Key: edcsa=base64(raw ECPubKey) 

see: 
https://jrconlin.github.io/WebPushDataTestPage/