Re: New draft: Reverse HTTP Transport

On 7/11/23 11:43, Benjamin Schwartz wrote:
> Hi HTTPBIS,
>
> TIru Reddy and I have a fun new -00 today for your amusement: Reverse 
> HTTP Transport 
> (https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-00.html).
>
> Abstract:
>    This document defines a secure transport for HTTP in which the client
>    and server roles are reversed.  This arrangement improves the origin
>    server's protection from Layer 3 and Layer 4 DDoS attacks when an
>    intermediary is in use.  It allows origin server's to be hosted
>    without being publicly accessible but allows the clients to access
>    these servers via an intermediary.
>
> Although the mechanism described here is generic, the main expected 
> use case is related to MASQUE, OHAI, and Oblivious DoH.  The essence 
> of the proposal is straightforward, but there are definitely some 
> things for us to talk about in the details:
>
> * Transport proxies like CONNECT-UDP are handled by having the origin 
> run its own proxy endpoint for access to itself.
>   - "CONNECT-TCP" is not used (even though I think it's great), 
> because the target is only identified by an Origin, not a URI Template.
> * The TLS server (i.e. HTTP client) speaks first, at 1.5 RTT on the 
> half-open TLS connection.
> * Ownership of transport endpoints and IP addresses is inferred from 
> ownership of matching HTTP origins.
> * There are some real open questions about what to do about DNS 
> verification and stolen key attacks.
>
> Please send us your thoughts!
>
> --Ben Schwartz

We (personally) understand this is not explicitly intended for clients, 
but could this be used for HTTP-based GUI systems? You'd have a web 
browser and instead of letting the browser make connections to the 
localhost app (vulnerable to XSS, CSRF, etc) you could have the 
localhost app connect to the browser (and the browser would allocate a 
unique opaque origin of some sort for it, completely hidden from other 
origins)?

Probably unlikely to happen but something like this would solve all the 
security issues we've run into while trying to deploy a native app with 
a browser-based GUI (without webviews or embedding an own browser)...