Re: [Standards] XEP-0363: Restricted set of headers when requesting a slot
Hi Ivan, On Dienstag, 15. Dezember 2020 02:56:33 CET Ivan Vučica wrote: > I'm trying to direct the chat client to talk directly to the cloud > storage API using 'signed URLs', granting time-restricted upload > access to possessing a URL, where I can still restrict file size. > > The cloud storage API happens to be Google Cloud Storage, but to my > understanding, a similar approach applies to Amazon S3 and possibly > other similar stores. > > The XEP says (https://xmpp.org/extensions/xep-0363.html#request): > > """ > The element MAY also contain a number of elements which > correspond to HTTP header fields. Each element MUST have a > name-attribute and a content with the value of the header. Only the > following header names are allowed: Authorization, Cookie, Expires. > Other header names MUST be ignored by the requesting entity and MUST > NOT be included in the HTTP request. The requesting entity MUST strip > any newline characters from the header name and value before > performing the HTTP request. > """ > > I do understand that this tries to restrict the possible damage that a > compromised server could direct a chat client to execute. The rationale is about the same as for the existence of CORS rules. I think, back then (but I cannot find the specific discussion quickly) the choice was between forcing XMPP clients to fully implement the CORS standard or to define a specific set of headers. The fact that being able to direct entities to send arbitrary HTTP PUT requests is a dangerous feat is known, otherwise CORS would not exist. So yeah... > > However, this does mean setting useful custom headers such as > x-goog-acl becomes difficult. (This particular header's documentation: > https://cloud.google.com/storage/docs/xml-api/put-object-upload#request_head > ers) > > Two workarounds: > - make the whole bucket public to the internet: in this particular > case, feasible > - on first GET access, update ACLs > - hopefully the API exists -- I did not actively seek it yet > - feasible because I want the permalink GET URLs to be on a domain I > control - downside: this does cost a small amount of money > > The best option is for the chat client to set this header to value > "public" in order to make the blob visible to unauthenticated users. > > This is only one cloud storage provider. It's not a lot of money to > perform an extra write operation when the GET method is executed by > the HTTP frontend (creating the 302 response). And clearly, this is a > proprietary header. So -- it's not a big deal. > > But, I do wonder what attacks are even possible if arbitrary PUT > request headers are allowed. The user still has to attempt an upload, > so this wouldn't be a large distributed attack. What are the concerns > with the upload component directing the user to an arbitrary service > to perform the upload? That’ll very much depend on the service we’re talking about. Mind that the XMPP client may live in a different trust zone than the server. It might be in an Intranet and might have access to other fun services which this allows to exploit in one way or another. Generally the same rationale why browsers forbid cross-domain requests (unless authorized via CORS), really. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2020-12-16
Hi everyone, The next XMPP Council Meeting will take place on 2020-12-16 at 16:00Z in xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to the discussions. This agenda is composed from: - Editor notifications to standards@ - xsf/xeps GitHub PRs marked as Needs Council - xsf/xeps GitLab MRs marked as Needs Council - Suggestions directly sent to me (see below) Agenda as follows: 1) Roll Call 2) Agenda Bashing * Feel free to pre-bash on-list or directly to me if you think something is missing. 3) Editor’s Update * XEP-0450: Automatic Trust Management accepted as Experimental 4) Items for voting None. 5) Pending Votes - Everyone got some, please check the Spreadsheet of Doom [1]. 6) Date of Next 7) AOB 8) Close End of Agenda. Note that I am aiming for 30 minutes, but meetings may be extended as necessary if all council members agree. Meetings are normally held every Wednesday at 16:00 UTC in the xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone (XSF Member or not) may attend, though only XMPP Council members may vote. Relevant comments from the floor are welcomed. Using your web browser, you can join anonymously via https://xmpp.org/chat?council Note that conversations in the room are logged publicly at https://logs.xmpp.org/council/ If you have suggestions for an agenda item, you can message me via XMPP or email at this address or at jo...@zombofant.net. I aim to publish the Agenda on the day before the Council meeting before 19:00Z. Stay safe, smart & healthy, Jonas [1]: https://docs.google.com/spreadsheets/d/1KyQCSGAsP-nHmH1X_EQOO-MfMzqSMxgBYGRlloAhxxY/edit#gid=0 (sorry, you’ll have to copy that link due to [2]) [2]: https://bugs.kde.org/show_bug.cgi?id=373040 signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-12-02
On Samstag, 5. Dezember 2020 23:26:53 CET Tedd Sterr wrote:
> 4d) Proposed XMPP Extension: Automatic Trust Management -
> https://xmpp.org/extensions/inbox/automatic-trust-management.html Jonas:
> [on-list]
> Daniel: [on-list]
> Georg: [on-list]
> Zash: [on-list]
> Dave: [on-list]
>
> Georg bemoans the tradition of XEP authors redefining commonly-used acronyms
> ('ATM' in this case.) Dave thinks this looks somewhat familiar - Zash
> suggests Dave might be thinking of XEP-0434 (Trust Messages (TM)) which is
> the wire format, while this seems to be mostly policy.
+1.
signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Council Minutes 2020-12-02
Hi Zash, I used "OOK" as an abbreviation for "only one key". You can find it here: https://xmpp.org/extensions/inbox/automatic-trust-management.html#use-cases > If the encryption protocol used with ATM involves only one key for > all endpoints of the same identity, only the use cases for > authenticating and distrusting keys of a contact's endpoint are > relevant. Those use cases are marked with OOK for only one key. If you use ATM e.g. with OpenPGP for XMPP and each chat partner has only on key for all own devices, you would only need to implement the "OOK" use cases. >> 4d) Proposed XMPP Extension: Automatic Trust Management - >> https://xmpp.org/extensions/inbox/automatic-trust-management.html >+1 > >What's "OOK" tho? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-12-02
On Sat Dec 5, 2020 at 11:26 PM CET, Tedd Sterr wrote: > 4a) PR #1014 (XEP-0176: Improve compatibility with WebRTC clients) - > https://github.com/xsf/xeps/pull/1014 +1 > 4d) Proposed XMPP Extension: Automatic Trust Management - > https://xmpp.org/extensions/inbox/automatic-trust-management.html +1 What's "OOK" tho? -- Kim "Zash" Alvefur ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
