Federation request signing is easily broken by proxies

I recently came across this issue with synapse: https://github.com/matrix-org/synapse/issues/3294#issuecomment-462199951

It basically comes down to how reverse-proxies in front of synapse handle things. So far, I checked the spec which doesn't really specify whenever or things have to be url-encoded or not, but all example url-encode strings.

So far one could make assumptions on this, but HTTP explicitly states that URL encoded URLs, should be decoded before using them and make no difference.

Characters other
than those in the "reserved" set are equivalent to their
percent-encoded octets: the normal form is to not encode them (see
Sections 2.1 and 2.2 of [RFC3986]).

For example, the following three URIs are equivalent:

 http://example.com:80/~smith/home.html
 http://EXAMPLE.com/%7Esmith/home.html
 http://EXAMPLE.com:/%7esmith/home.html

https://tools.ietf.org/html/rfc7230#section-2.7.3

When we use HTTP as a standard, we should make sure we don't contradict it. Therefore we should fix the examples and implementations in this perspective.

For some cases, where things might contain special characters, that interfere with the HTTP standard like / we might want to explicitly disallow them in the spec. Because if we don't do this, it'll cause harm to the protocol in the long term perspective (as it already does with various WAF solutions in front of Synapse, when they canonicalize URLs).

Start by reading the linked Synapse issue and RFC 7230 section 2.7.3, then compare the specification's URL-encoding examples with its implementations. Done means the examples and implementations consistently define handling of encoded URLs and special characters so reverse proxies cannot change the signed request meaning.