davidschinazi / masque-drafts Goto Github PK

The text should do a better job of explaining how compression contexts are used, and how they interact with DATAGRAM flow identifiers. In a nutshell, the compression context is identified by a number that is in the DATAGRAM flow identifier namespace, but that needs to be better explained.

(Thanks @martinthomson for the feedback)

Our community, working with the PEARG folks in IRTF, submitted an Internet Draft of our on-going work on network traffic obfuscation called "Pluggable Transports". It's HERE. I'm one of the authors. This work, begun at the Tor Project with later cooperation from organizations serving the Human Rights and Internet Freedom areas, has been focused on TCP. We'd be interested to understand if there is a relationship between this work and your work on MASQUE, and/or if there is possibility to cooperate.

You don't need to do that. Configuring a URL seems as likely to work as a domain name and it provides additional deployment flexibility for the application.

A payload within a CONNECT-UDP request message has no defined semantics; a CONNECT-UDP request with a non-empty payload is malformed.

I think that this text is out of sync with the rest of the doc. The payload is used to carry UDP packets, even when you use DATAGRAM frames.

As of connect-udp-00, the Datagram-Flow-Id is defined as a structured header of type sh-integer. The max value for those is 10^15-1, but in theory flow IDs can go up to 2^62-1 (~4*10^18). We should either:

• specify an alternate encoding, such as an sh-binary byte sequence with specified endianness and maximum width
• note that values over 10^15-1 cannot be encoded and reaching that flow identifier should trigger closing the HTTP/3 connection and restarting it

The word "validated" is already used to discuss address validation is QUIC. Perhaps we should use "confirmed" instead? Then again that's already used for the handshake...

(Thanks @martinthomson for the feedback)

Note that when multiple proxies are involved in a CONNECT-UDP request, all the HTTP connections along the path need to be using HTTP/3 [H3] or later in order for UDP payloads to be sent over QUIC DATAGRAM frames.

How is this true? The first proxy should convert the stream of encapsulated UDP datagrams into actual UDP datagrams. That means that the second proxy won't see these as part of the connection.

This is only an issue if the proxy wants to pass the DATAGRAM frames on to the next proxy. But that's not what is being asked of it, if it does that, it does so on its own recognizance. (I should add: if it chooses to forward to a next hop that uses h2, then it can take the DATAGRAM frames and stuff them into the request stream.)

Created out of mailing list discussion, summary of the points discussed there:

• MASQUE has some similarity to other mechanisms that modify the behaviour of an HTTP connection after a negotiation phase (e.g. conventional CONNECT, WebSocket upgrade etc).
• Legacy HTTP proxying can be vulnerable. Programmatic request generation such as via the Fetch API provide several measures to prevent scripts from exploiting such mechanisms. Either through forbidding methods or forbidding header names prefixed with Sec- or Proxy- (e.g. as required by the WebSocket protocol .
• it is reasonable to assume that MASQUE proxying applications make be affected by the class of vulnerability
• draft-schinazi-masque-protocol-01 negotiation uses POST requests and has defines no mandatory headers

Some possible actions to provide mitigations:

• acknowledge that as a new protocol, MASQUE is not affected by legacy deployment concerns. Provide guidance in Security Considerations for new deployments of MASQUE.
• Consider if MASQUE negotiation should be blocked from implementation in web-based JavaScript. If so define something to do so e.g.:
  • Keep POST but define some forbidden header
  • More drastically, move away from POST to something else such as extended CONNECT.

connect-udp-00 s3 mainly copied most of the CONNECT-UDP design from CONNECT, but than goes against some existing HTTP semantics. In particular, every HTTP method is supposed to use URIs to represent their request target (this was mentioned in RFC 7231 s2 and clarified in draft-ietf-httpbis-semantics s6.1). CONNECT and OPTIONS are noted as existing exceptions, but new methods are not allowed exceptions, to allow intermediaries to proxy unknown methods. CONNECT-UDP only cares about the authority (host and port) portion of the URI, so we can easily encode that as an URI and mandate that the path MUST be "/" and the query MUST be empty. The main open question is what scheme to use. We could either reuse https, or register a new one.

The CONNECT-UDP proxy has to act a little like a NAT when it forwards UDP. It has to assign a source IP and port. Those probably need to be dedicated to the flow for its lifetime. However, UDP lacks the clear signals of TCP about connection termination, so we need a clear definition of what lifetime is.

It is perhaps reasonable to tie the lifetime of the allocation to the existence of the stream, but then the connection from the client might drop mid-flow; how long does the proxy need to avoid reusing that address?

The proxy might also decide that idleness is cause for dropping bindings. The client needs to know this because it will need to make new tunnels to continue communication if it goes idle for too long.

The design here would appear to permit the use of 'Address and Port-Dependent Mapping' as defined in Section 4.1 of RFC 4787. However, that document strongly recommends that an 'Endpoint-Independent Mapping' is used so as to make UNSAF methods work. This document should define those rules.

Related #24.

CONNECT-UDP can be used across multiple proxy hops, and each of these hops can have a different MTU, so it could be useful for the client to be notified of the maximum DATAGRAM payload size that will make it across all the hops. This value could also change over time, so we could consider adding the ability to communicate that.

The client part of negotiation requires a client to send a POST request with a sequence of TLVs. What is the content-type of that payload body?

That is probably OK for something with CONNECT-like semantics, but we did explicitly choose to disable hop-by-hop fields in HTTP/2.

One of the security issues with Masque proxies is whether they can be used to attack third parties. The attacking client would connect to the Masque server, and push packets towards a third party with a goal of attacking that party. It could be part of a "targeted" attack, sending specially crafted packets to activate a bug and crash or pwn the target. Or it could be a volumetric attack, with the client sending large number of transactions to try DOS the target.

Such abuses can cause reputation issues for the proxy, eventually landing the proxy's IP address in some kind of blacklist. It seems that Masque implementations should recognize the issue and do something about it.

The first line of defense is of course to only serve authorized clients, but that's not a perfect defense. Attackers could somehow hack an authorized client and get its credentials. Or, they could subscribe to the service with a throw-away identity.

The second line of defense, used for example in TURN, is to restrict what clients can do. This amounts to building some kind of basic firewall in the Masque proxy, with rules like inspecting packets or limiting packet rates.

I wonder whether we should add text to that effect in the specification?

Would be good to already add a table with type-length-value entries for the services that are described in the draft. I assume we will have a IANA registry for that...?

We discussed already which term to use. Not sure we fully concluded here but in the charter I think it's service now. Should this be updated in this draft respectively?

I would like to support a QUIC proxy because it is much easier to deploy, requires just one port.

... Per feedback from Martin during the BoF.

Imagine adversary Adv knows the username of a MASQUE user, and observes a connection to a supposed MASQUE server. Adv could determine whether or not the user initiated a MASQUE connection as follows:

1. Connect to the server and send a MASQUE request with the correct username and bogus signature. Measure the time to response as T1.
2. Connect to the server and send a MASQUE request with a bogus username and signature. Measure the time to response as T2.

If T1 >> T2, this suggests that the username is valid for the given MASQUE server.

MASQUE servers should process (username, signature) request tuples in constant time so as to not leak this type of information.

Proxying QUIC isn't a completely straightforward concept, the draft should spend more time explaining what it accomplishes and what external bits are required (such as return routing of packets for example). A sequence diagram showing the flow of packets might help.

(Thanks @martinthomson for the feedback)

Since HTTP Structured Headers (draft-ietf-httpbis-header-structure) are nearing publication, we should turn Transport-Authentication from draft-schinazi-httpbis-transport-auth into an Item Structured Header.

The abstract seems to unnecessarily restrict the use case for MASQUE. I can see a very clear use case for corporations/governments/organizations: VPNs are being blocked and tracked more and more frequently. Travelling employees need VPNs to work. Such groups would then want to run MASQUE on their own infrastructure to obfuscate their own VPN traffic. Many OpenVPN providers offer obfs4 tunneling, for example. If the network that the travelling employee has access to blocks all OpenVPN traffic, then MASQUE to their own infrastructure would help.

@m4mb01t4l14n0 @uniqx

From 3. Overview of the Mechanism, I understand the goal as making sure that the HTTP CONNECT responses do not divulge whether MASQUE is present or not. I think this needs to be spelled out a bit more, since HTTP CONNECT can be used without any auth. This would then make it clear that the MASQUE server should respond to HTTP CONNECT requests without auth the same as it would for failed auth. Or maybe its better to say that the MASQUE server only considers HTTP CONNECT requests with MASQUE pseudo-header, and everything else is entirely ignored.

@uniqx @m4mb01t4l14n0