Neil Jenkins writes: > On Sun, 6 Jan 2019, at 9:26 AM, Bron Gondwana wrote: > > And look at making the push protocol have a confirmation step: > https://github.com/jmapio/jmap/issues/276 > > I'm not convinced this is necessary and/or helpful. In the current system, the > first time a push is triggered the application (JMAP) server sends a request to > the push server (the URL registered by the client); if this is not accepted > with a reasonable HTTP response, it would automatically disable it. The danger > is meant to be DOSing this URL (it's not really a push server); however with a > confirmation step, you still need to do that first request so you're not > reducing the number of HTTP requests. You are however relying on the push being > received by the client in order for it to be able to complete registration, and > all common push services do not guarantee delivery, so this becomes much less > reliable. (With this in mind, the JMAP push system happily copes with dropped > push packets while still guaranteeing full resynchronisation.) Actually I think adding confirmation step will make the push notifications more reliable, as that will give you positive feedback that your push notifications do work. It is really annoying trying to debug which firewall / proxy / encryption is causing the notification to be blocked, if I need to reregister again for every time and need to then somehow still cause one push notification to be sent before I can see does it work. > I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 > (which is what the push system is implementing) does not require a confirmation > step. My understanding is that RFC8030 does not connect random urls, the push notifications are received by client doing GET request to the subscription server and then later server using server push to that connection or something like that (in section 6 of the RFC8030). Usually that is only way things can work, as most of the people are behind firewalls / NATs / Proxies etc, thus connecting to them from outside is impossible or hard. The interaction between UA and the Application server is using "an application-specific method" which is not described in the RFC8030: An application-specific method is used to distribute the push URI to the application server. Confidentiality protection and application server authentication MUST be used to ensure that this URI is not disclosed to unauthorized recipients (Section 8.3). The verification would be inside this application-specific method, thus it is not covered in the 8030 because of that. In Jmap case the URL can be anything in the network and server is assumed to connect to that URL every time something happens. Yes, if something goes wrong in that url then notifications are disabled, but if server just answers HTTP ok 200 back, and JMAP server will be happy to keep sending notifications. With verification step the amplification factor would be around 1, as attacker does subscription registration (small packet), JMAP server sends first notification indication subscription is registed to given url (small packet), and when JMAP server does not get confirmation back from the attacker (which most likely cannot see the notifications), then it will delete subscription. Attacker can also do 10000 subscriptions to same victim (perhaps using different URLs, but destioned to same victim). It can do this overnight, and then on the morning when someone triggers event the victim will suddenly receive 10000 event notifications (https-connections) from the well connected JMAP server farm, and will be completely swamped before it can even respond to any errors to those notifications. -- kivinen@xxxxxx
