From f30e6851127874739659ffe2b2c211c4db6e50f0 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 7 Nov 2018 13:41:53 +0000 Subject: [PATCH 1/9] proposal for requiring signed certs for federation --- proposals/1711-x509-for-federation.md | 238 ++++++++++++++++++++++++++ 1 file changed, 238 insertions(+) create mode 100644 proposals/1711-x509-for-federation.md diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md new file mode 100644 index 00000000..9c20eab9 --- /dev/null +++ b/proposals/1711-x509-for-federation.md @@ -0,0 +1,238 @@ +# MSC1711: X.509 certificate verification for federation connections + +TLS connections for server-to-server communication currently rely on an +approach borrowed from the [Perspectives +project](https://web.archive.org/web/20170702024706/https://perspectives-project.org/) +to provide certificate verification, rather than the more normal model using +certificates signed by trusted Certificate Authorities. This document sets out +the reasons that this has not been a success, and suggests that we should +instead revert to the CA model. + +## Background: the failure of the Perspectives approach + +The Perspectives approach replaces the conventional heirarchy of trust provided +by the Certificate Authority model with a large number of "notary" servers +distributed around the world. The intention is that the notary servers +regularly monitor remote servers and observe the certificates they present; +when making a connection to a new site, a client can correlate the certificate +it presents with that seen by the notary servers. In theory this makes it very +hard to mount a Man-in-the-Middle (MitM) attack, because it would require +intercepting traffic between the target server and a large number of the notary +servers. + +It is notable that the Perspectives project itself appears to have largely been +abandoned: its website has largely been repurposed, the [Firefox +extension](https://addons.mozilla.org/en-GB/firefox/addon/perspectives/) does +not work with modern versions of Firefox, the [mailing +list](https://groups.google.com/forum/#!forum/perspectives-dev) is inactive, +and several of the (ten) published notary servers are no longer functional. The +reasons for this are not entirely clear, though clearly it never gained +widespread adoption. + +When Matrix was originally designed in 2014, the Perspectives project was +heavily active, and avoiding dependencies on the relatively centralised +Certificate Authorities was attractive, in accordance with Matrix's design as a +decentralised protocol. However, this has not been a success in practice. + +Matrix was unable to make use of the existing notary servers (largely because +we wanted to extend the protocol to include signing keys): the intention was +that, as the Matrix ecosystem grew, public Matrix servers would act as notary +servers. However, in practice we have ended up in a situation where almost [1](#f1) every Matrix homeserver either uses `matrix.org` as the +sole notary, or does no certificate verification at all. Far from avoiding the +centralisation of the Certificate Authorities, the entire protocol is therefore +dependent on a single point of control at `matrix.org` - and because +`matrix.org` only monitors from a single location, the protection against MitM +attacks is weak. + +It is also clear that the Perspectives approach is poorly-understood. It is a +common error for homeservers to be deployed behind reverse-proxies which make +the Perspectives-based approach unreliable. The CA model, for all its flaws, is +at least commonly used, which makes it easier for administrators to deploy +(secure) homeservers, and allows server implementations to leverage existing +libraries. + +## Proposal + +We propose that Matrix homeservers should be required to present valid TLS +certificates, signed by a known Certificate Authority, on their federation +port. + +In order to ease transition, we could continue to follow the current, +perspectives-based approach for servers whose TLS certificates fail +validation. However, this should be strictly time-limited (for three months, +say), to give administrators time to switch to a signed certificate. The +`matrix.org` team would proactively attempt to reach out to homeserver +administrators who do not update their certificate. + +Once the transition to CA-signed certificates is complete, the +`tls_fingerprints` property of the +[`/_matrix/key/v2`](https://matrix.org/docs/spec/server_server/unstable.html#retrieving-server-keys) +endpoints would be redundant and we should consider removing it. + +The process of determining which CAs are trusted to sign certificates would be +implementation-specific, though it should almost certainly make use of existing +operating-system support for maintaining such lists. It might also be useful if +administrators could override this list, for the purpose of setting up a +private federation using their own CA. + +### Interaction with SRV records + +With the use of `SRV` records, it is possible for the hostname of a homeserver +to be quite different from the matrix domain it is hosting. For example, if +there were an SRV record at `_matrix._tcp.matrix.org` which pointed to +`server.example.com`, then any federation requests for `matrix.org` would be +routed to `server.example.com`. The question arises as to which certificate +`server.example.com` should present. + +In short: the server should present a certificate for the matrix domain +(`matrix.org` in the above example). This ensures that traffic cannot be +intercepted by a MitM who can control the DNS response for the `SRV` record +(perhaps via cache-poisoning or falsifying DNS responses). + +This will be in line with the current +[requirements](https://matrix.org/docs/spec/server_server/unstable.html#resolving-server-names) +in the Federation API specification for the `Host`, and by implication, the TLS +Server Name Indication [2](#f2). + +### Interaction with `.well-known` files + +[MSC1708](https://github.com/matrix-org/matrix-doc/blob/rav/proposal/well-known-for-federation/proposals/1708-well-known-for-federation.md) +proposes an alternative to SRV records, in the form of `.well-known` files. In +this instance, a file at `https://matrix.org/.well-known/matrix/server` might +direct requests to `server.example.com`. + +In this case, `server.example.com` would be required to present a valid +certificate for `server.example.com`. + +Because the request for the `.well-known` file takes place over a validated TLS +connection, this is not subject to the same DNS-based attacks as the SRV +record, and this mechanism allows the owners of a domain to delegate +responsibility for running their Matrix homeserver without having to hand over +TLS keys for the whole domain. + +### Extensions + +HTTP-Based Public Key Pinning (HPKP) and +[https://www.certificate-transparency.org](Certificate transparency) are +both HTTP extensions which attempt to work around some of the deficiencies in +the CA model, by making it more obvious if a CA has issued a certificate +incorrectly. + +HPKP has not been particularly successful, and is +[deprecated]((https://developers.google.com/web/updates/2018/04/chrome-67-deps-rems#deprecate_http-based_public_key_pinning) +in Google Chrome as of April 2018. Certificate transparency, however, is seeing +widespread adoption from Certificate Authories and HTTP clients. + +This proposal sees both technologies as optional techniques which could be +provided by homeserver implementations. We encourage but do not mandate the use +of Certificate Transparency. + +### Related work + +The Perspectives approach is also currently used for exchanging the keys that +are used by homeservers to sign Matrix events and federation requests (the +"signing keys"). Problems similar to those covered here also apply to that +mechanism. A future MSC will propose improvements in that area. + +## Tradeoffs + +There are well-known problems with the CA model, including a number of +widely-published incidents in which CAs have issued certificates +incorrectly. It is therefore important to consider alternatives to the CA +model. + +### Improving support for the Perspectives model + +In principle, we could double-down on the Perspectives approach, and make an effort +to get servers other than `matrix.org` used as notary servers. However, there +remain significant problems with such an approach: + +* Perspectives remain complex to configure correctly. Ideally, administrators + need to make conscious choices about which notaries to trust, which is hard + to do, especially for newcomers to the ecosystem. (In practice, people use + the out-of-the-box configuration, which is why everyone just uses + `matrix.org` today). + +* A *correct* implementation of Perspectives really needs to take into account + more than the latest state seen by the notary servers: some level of history + should be taken into account too. + +Essentially, whilst we still believe the Perspectives approach has some merit, +we believe it needs further research before it can be relied upon. We believe +that the resources of the Matrix ecosystem are better spent elsewhere. + +### DANE + +DNS-Based Authentication of Named Entities (DANE) can be used as an alternative +to the CA model. (It is arguably more appropriately used *together* with the CA +model.) + +It is not obvious to the author of this proposal that DANE provides any +material advantages over the CA model. In particular it replaces the +centralised trust of the CAs with the centralised trust of the DNS registries. + +## Potential issues + +Beyond the problems already discussed with the CA model, requiring signed +certificates comes with a number of downsides. + +### More difficult setup + +Configuring a working, federating homeserver is a process fraught with +pitfalls. This proposal adds the requirement to obtain a signed certificate to +that process. Even with modern intiatives such as Let's Encrypt, this is +another procedure requiring manual intervention across several moving parts[3](#f3). + +On the other hand: obtaining an SSL certificate should be a familiar process to +anybody capable of hosting a production homeserver (indeed, they should +probably already have one for the client port). This change also opens the +possibility of putting the federation port behind a reverse-proxy without the +need for additional configuration. Hopefully making the certificate usage more +conventional will offset the overhead of setting up a certificate. + +### Inferior support for IP literals + +Whilst it is possible to obtain an SSL cert which is valid for a literal IP +address, this typically requires purchase of a premium certificate; in +particular, Let's Encrypt will not issue certificates for IP literals. This may +make it impractical to run a homeserver which uses an IP literal, rather than a +DNS name, as its `server_name`. + +It has long been the view of the `matrix.org` administrators that IP literals +are only really suitable for internal testing. Those who wish to use them for +that purpose could either disable certificate checks inside their network, or +use their own CA to issue certificates. + +### Inferior support for hidden services (`.onion` addresses) + +It is currently possible to correctly route traffic to a homeserver on a +`.onion` domain, provided any remote servers which may need to reach that +server are configured to route to such addresses via the Tor network. However, +it can be difficult to get a certificate for a `.onion` domain (again, Let's +Encrypt do not support them). + +The reasons for requiring a signed certificate (or indeed, for using TLS at +all) are weakened when traffic is routed via the Tor network. It may be +reasonable to relax the requirement for a signed certificate for such traffic. + +## Conclusion + +We believe that requiring homservers to present an X.509 certificate signed by +a recognised Certificate Authority will improve security, reduce +centralisation, and eliminate some common deployment pitfalls. + +[1] It's *possible* to set up homeservers to use servers other than +`matrix.org` as notaries, but we are not aware of any that are set up this +way. [↩](#a1) + +[2] I've not been able to find an authoritative source on this, but +most reverse-proxies will reject requests where the SNI and Host headers do not +match. [↩](#a2) + +[3] Let's Encrypt will issue ACME challenges via port 80 or DNS +(for the `http-01` or `dns-01` challenge types respectively). It is unlikely +that a homeserver implementation would be able to control either port 80 or DNS +responses, so we will be unable to automate a Let's Encrypt certificate +request. [↩](#a3) From efc8056fb62ccb7501efae146abb646914f69b1d Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 7 Nov 2018 13:48:27 +0000 Subject: [PATCH 2/9] fix a couple of broken links --- proposals/1711-x509-for-federation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md index 9c20eab9..a31ae482 100644 --- a/proposals/1711-x509-for-federation.md +++ b/proposals/1711-x509-for-federation.md @@ -114,13 +114,13 @@ TLS keys for the whole domain. ### Extensions HTTP-Based Public Key Pinning (HPKP) and -[https://www.certificate-transparency.org](Certificate transparency) are +[Certificate transparency](https://www.certificate-transparency.org) are both HTTP extensions which attempt to work around some of the deficiencies in the CA model, by making it more obvious if a CA has issued a certificate incorrectly. HPKP has not been particularly successful, and is -[deprecated]((https://developers.google.com/web/updates/2018/04/chrome-67-deps-rems#deprecate_http-based_public_key_pinning) +[deprecated](https://developers.google.com/web/updates/2018/04/chrome-67-deps-rems#deprecate_http-based_public_key_pinning) in Google Chrome as of April 2018. Certificate transparency, however, is seeing widespread adoption from Certificate Authories and HTTP clients. From f9cf99f1fd6c1b0cbdf77e86b6a4e532c13adb2a Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Thu, 8 Nov 2018 15:31:58 +0000 Subject: [PATCH 3/9] typo --- proposals/1711-x509-for-federation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md index a31ae482..d30fe566 100644 --- a/proposals/1711-x509-for-federation.md +++ b/proposals/1711-x509-for-federation.md @@ -219,7 +219,7 @@ reasonable to relax the requirement for a signed certificate for such traffic. ## Conclusion -We believe that requiring homservers to present an X.509 certificate signed by +We believe that requiring homeservers to present an X.509 certificate signed by a recognised Certificate Authority will improve security, reduce centralisation, and eliminate some common deployment pitfalls. From bc290155145d9e8d4721dbae111d0d13f83cd01a Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Thu, 8 Nov 2018 16:28:13 +0000 Subject: [PATCH 4/9] fix typo --- proposals/1711-x509-for-federation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md index d30fe566..52662123 100644 --- a/proposals/1711-x509-for-federation.md +++ b/proposals/1711-x509-for-federation.md @@ -10,7 +10,7 @@ instead revert to the CA model. ## Background: the failure of the Perspectives approach -The Perspectives approach replaces the conventional heirarchy of trust provided +The Perspectives approach replaces the conventional hierarchy of trust provided by the Certificate Authority model with a large number of "notary" servers distributed around the world. The intention is that the notary servers regularly monitor remote servers and observe the certificates they present; From e0fa00fc34c3b67ee8166e19372e569eabce42c9 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 3 Jan 2019 18:21:05 +0000 Subject: [PATCH 5/9] Some HSes use more than one notary --- proposals/1711-x509-for-federation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md index 52662123..82881d93 100644 --- a/proposals/1711-x509-for-federation.md +++ b/proposals/1711-x509-for-federation.md @@ -224,7 +224,7 @@ a recognised Certificate Authority will improve security, reduce centralisation, and eliminate some common deployment pitfalls. [1] It's *possible* to set up homeservers to use servers other than -`matrix.org` as notaries, but we are not aware of any that are set up this +`matrix.org` as notaries, but only a minority are actually set up this way. [↩](#a1) [2] I've not been able to find an authoritative source on this, but From 367f61f14a0f475f0f95c77cd2cd27254e0e7124 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 7 Jan 2019 21:38:41 +0000 Subject: [PATCH 6/9] cleanups and clarifications --- proposals/1711-x509-for-federation.md | 42 ++++++++++++++++++--------- 1 file changed, 29 insertions(+), 13 deletions(-) diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md index 82881d93..dc737ff6 100644 --- a/proposals/1711-x509-for-federation.md +++ b/proposals/1711-x509-for-federation.md @@ -58,17 +58,18 @@ We propose that Matrix homeservers should be required to present valid TLS certificates, signed by a known Certificate Authority, on their federation port. -In order to ease transition, we could continue to follow the current, -perspectives-based approach for servers whose TLS certificates fail -validation. However, this should be strictly time-limited (for three months, -say), to give administrators time to switch to a signed certificate. The -`matrix.org` team would proactively attempt to reach out to homeserver -administrators who do not update their certificate. +In order to ease transition and give administrators time to switch to a signed +certificate, we will continue to follow the current, perspectives-based +approach for servers whose TLS certificates fail validation. -Once the transition to CA-signed certificates is complete, the +However, this fallback will be strictly time-limited, and Matrix S2S spec r0 +will not accept self-signed certificates, nor will it include the `tls_fingerprints` property of the [`/_matrix/key/v2`](https://matrix.org/docs/spec/server_server/unstable.html#retrieving-server-keys) -endpoints would be redundant and we should consider removing it. +endpoints. Synapse 1.0 will not accept self-signed certificates by default. + +The `matrix.org` team will proactively attempt to reach out to homeserver +administrators who do not update their certificates in the coming weeks. The process of determining which CAs are trusted to sign certificates would be implementation-specific, though it should almost certainly make use of existing @@ -76,6 +77,12 @@ operating-system support for maintaining such lists. It might also be useful if administrators could override this list, for the purpose of setting up a private federation using their own CA. +It would also be useful for administrators to be able to disable the +certificate checks for a whitelist of domains/netmasks. This would be useful +for `.onion` domains (where a certificate is hard to obtain, and where server +verification is provided at the network level), as well as for testing with IP +literals. + ### Interaction with SRV records With the use of `SRV` records, it is possible for the hostname of a homeserver @@ -93,7 +100,10 @@ intercepted by a MitM who can control the DNS response for the `SRV` record This will be in line with the current [requirements](https://matrix.org/docs/spec/server_server/unstable.html#resolving-server-names) in the Federation API specification for the `Host`, and by implication, the TLS -Server Name Indication [2](#f2). +Server Name Indication [2](#f2). It is also consistent with +the recommendations of +[RFC6125](https://tools.ietf.org/html/rfc6125#section-6.2.1) and the +conventions established by the XMPP protocol (per [RFC6120](https://tools.ietf.org/html/rfc6120#section-13.7.2.1). ### Interaction with `.well-known` files @@ -133,9 +143,9 @@ of Certificate Transparency. The Perspectives approach is also currently used for exchanging the keys that are used by homeservers to sign Matrix events and federation requests (the "signing keys"). Problems similar to those covered here also apply to that -mechanism. A future MSC will propose improvements in that area. +mechanism. This is discussed at [#1685](thttps://github.com/matrix-org/matrix-doc/issues/1685). -## Tradeoffs +## Alternatives There are well-known problems with the CA model, including a number of widely-published incidents in which CAs have issued certificates @@ -192,6 +202,12 @@ possibility of putting the federation port behind a reverse-proxy without the need for additional configuration. Hopefully making the certificate usage more conventional will offset the overhead of setting up a certificate. +Furthermore, homeserver implementations could provide an implementation of the +ACME protocol and integration with Let's Encrypt, to make it easier for +administrators to get started. (This would of course be +implementation-specific, and administrators who wanted to keep control of the +certificate creation process would be free to do so). + ### Inferior support for IP literals Whilst it is possible to obtain an SSL cert which is valid for a literal IP @@ -214,8 +230,8 @@ it can be difficult to get a certificate for a `.onion` domain (again, Let's Encrypt do not support them). The reasons for requiring a signed certificate (or indeed, for using TLS at -all) are weakened when traffic is routed via the Tor network. It may be -reasonable to relax the requirement for a signed certificate for such traffic. +all) are weakened when traffic is routed via the Tor network. Administrators +using the Tor network could disable certificate checks for `.onion` addresses. ## Conclusion From 74b2db7937bc23226770d8f0fb457ba667bf0e58 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 7 Jan 2019 21:39:02 +0000 Subject: [PATCH 7/9] Remove .well-known section This really belongs in MSC1708. --- proposals/1711-x509-for-federation.md | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md index dc737ff6..43fd9657 100644 --- a/proposals/1711-x509-for-federation.md +++ b/proposals/1711-x509-for-federation.md @@ -105,22 +105,6 @@ the recommendations of [RFC6125](https://tools.ietf.org/html/rfc6125#section-6.2.1) and the conventions established by the XMPP protocol (per [RFC6120](https://tools.ietf.org/html/rfc6120#section-13.7.2.1). -### Interaction with `.well-known` files - -[MSC1708](https://github.com/matrix-org/matrix-doc/blob/rav/proposal/well-known-for-federation/proposals/1708-well-known-for-federation.md) -proposes an alternative to SRV records, in the form of `.well-known` files. In -this instance, a file at `https://matrix.org/.well-known/matrix/server` might -direct requests to `server.example.com`. - -In this case, `server.example.com` would be required to present a valid -certificate for `server.example.com`. - -Because the request for the `.well-known` file takes place over a validated TLS -connection, this is not subject to the same DNS-based attacks as the SRV -record, and this mechanism allows the owners of a domain to delegate -responsibility for running their Matrix homeserver without having to hand over -TLS keys for the whole domain. - ### Extensions HTTP-Based Public Key Pinning (HPKP) and From 12fc50cea785d0f071fd29c8cd2ea153a360f1de Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 8 Jan 2019 11:03:36 +0000 Subject: [PATCH 8/9] clarify that a whitelist is useful for cjdns too --- proposals/1711-x509-for-federation.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md index 43fd9657..4eda65ef 100644 --- a/proposals/1711-x509-for-federation.md +++ b/proposals/1711-x509-for-federation.md @@ -79,9 +79,8 @@ private federation using their own CA. It would also be useful for administrators to be able to disable the certificate checks for a whitelist of domains/netmasks. This would be useful -for `.onion` domains (where a certificate is hard to obtain, and where server -verification is provided at the network level), as well as for testing with IP -literals. +for testing, or for networks that provide server verification themselves, +such as like `.onion` domains on Tor or `fc00::/8` IPs on cjdns. ### Interaction with SRV records From afa0caee93c8c21c008139babd0061a8a12f2c53 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 10 Jan 2019 18:16:39 +0000 Subject: [PATCH 9/9] remove lying footnote --- proposals/1711-x509-for-federation.md | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md index 4eda65ef..e97b8532 100644 --- a/proposals/1711-x509-for-federation.md +++ b/proposals/1711-x509-for-federation.md @@ -175,8 +175,7 @@ certificates comes with a number of downsides. Configuring a working, federating homeserver is a process fraught with pitfalls. This proposal adds the requirement to obtain a signed certificate to that process. Even with modern intiatives such as Let's Encrypt, this is -another procedure requiring manual intervention across several moving parts[3](#f3). +another procedure requiring manual intervention across several moving parts. On the other hand: obtaining an SSL certificate should be a familiar process to anybody capable of hosting a production homeserver (indeed, they should @@ -229,9 +228,3 @@ way. [↩](#a1) [2] I've not been able to find an authoritative source on this, but most reverse-proxies will reject requests where the SNI and Host headers do not match. [↩](#a2) - -[3] Let's Encrypt will issue ACME challenges via port 80 or DNS -(for the `http-01` or `dns-01` challenge types respectively). It is unlikely -that a homeserver implementation would be able to control either port 80 or DNS -responses, so we will be unable to automate a Let's Encrypt certificate -request. [↩](#a3)