tomas.kracmar/ma1sd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Clone wiki.

Anatoly Sablin
2020-01-22 23:17:26 +03:00
parent 736a2f894e
commit f70d16f9b1
3 changed files with 215 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
Gotchas.md Normal file

@@ -0,0 +1,18 @@
# NATing
If you are using NAT and doing port forwarding (with or without a reverse proxy in between) to the homeserver/identity server running on the same box, then you will most likely run into the issue that the homeserver is not able to talk to the identity server.
This is a sign that your NAT is not configured to handle supposedly outgoing connection that loopback into an internal network.
This is because the domain used is a public one that will give a public IP, forcing your gateway to rewrite the packet, sending it back to the homeserver/identity server box for a connection it is not aware of (and sending a RST packet).
iptables configuration:
```
iptables -t nat -A POSTROUTING -s 1.2.3.4/5 -j MASQUERADE
```
Change `1.2.3.4/5` to your HS/IS subnet (or its IP with /32).
Others options to go around this:
- Properly configure your firewall to handle NAT
- Have at least two IPs on the box running the HS and IS and reverse proxying IS endpoints to the 2nd IP
- have a mechanism to resolve the DNS name to the internal IP via:
- local `/etc/hosts` or equivalent
- your internal DNS (Bind9 with split view or dnsmasq with record overwrite)

120
Upgrade-Notes.md Normal file

@@ -0,0 +1,120 @@
# Upgrade notes
Unless listed below, it's always safe to upgrade to a release.
## v1.3.0
v1.3.0 is not backward-compatible with any previous version.
The following was changed:
- `application.yaml` is not longer supported as a default configuration filename. `mxisd.yaml` in the current working directory is now used by default
- Spring boot command line options are no longer supported. If you want to specify another configuration filename, use `-c /path/to/whatever/file`
- Removed support for Properties-like configuration
- Removed support for variable substitution with `${...}`
- The structure of the Sendgrid notification handler configuration has been changed to reflect the new unbind protection.
- 3PID sessions have been revamped (See [#93](https://github.com/kamax-matrix/mxisd/issues/93)), including their config.
- 3PID views have been equally revamped. There are no longer `local`, `localRemote` and `remote` views. `local` configuration namespace has been kept for backward compatibility but the two others do not do anything anymore.
- 3PID notifications have been equally revamped and no longer have `local` or `remote` validations, while `local` config goes up one level.
To migrate your configuration, edit your configuration so:
### Step 1
Any key which is not itself a value (like a 3PID type) and is made of `.` is turned into proper YAML.
Proper YAML is:
- 2 spaces per indentation. Not 4, and no tabs
- Keys cannot be duplicated
Example:
```yaml
my.config.item: 'value'
```
will become:
```yaml
my:
config:
item: 'value'
```
### Step 2
Configuration keys needs to be properly grouped as well.
Example:
```yaml
my:
config:
item1: 'value1'
my:
config:
item2: 'value2
```
becomes:
```yaml
my:
config:
item1: 'value1'
item2: 'value2
```
### Step 3
Placeholders now needs to be set to their intended value.
Example:
```yaml
matrix:
domain: 'example.org'
server:
name: "${matrix.domain}"
```
becomes:
```yaml
matrix:
domain: 'example.org'
server:
name: 'example.org'
```
### Step 4
Move anything under `view.session.local` up one level to `view.session`
Example:
```yaml
view:
session:
local:
onTokenSubmit:
success: '/path/to/session/local/tokenSubmitSuccess-page.html'
failure: '/path/to/session/local/tokenSubmitFailure-page.html'
```
becomes:
```yaml
view:
session:
onTokenSubmit:
success: '/path/to/session/local/tokenSubmitSuccess-page.html'
failure: '/path/to/session/local/tokenSubmitFailure-page.html'
```
### Step 5
Adapt 3PID notification templates to the distinction local/remote being removed.
Example:
```yaml
threepid:
medium:
<YOUR 3PID MEDIUM HERE>:
generators:
template:
session:
validation:
local: '/path/to/validate-local-template.eml'
remote: '/path/to/validate-remote-template.eml'
```
becomes
```yaml
threepid:
medium:
<YOUR 3PID MEDIUM HERE>:
generators:
template:
session:
validation: '/path/to/validate-local-template.eml'
```
The `remote` key totally disappears and has no equivalent.

77
mxisd-and-your-privacy.md Normal file

@@ -0,0 +1,77 @@
# mxisd and your privacy
**NOTE:** This page is out of date in some areas, especially regarding MSCs.
## A bit of history
Back in 2016, while we were evaluating Matrix use for orgs/corps environments, we saw three big issues:
- An IS spec not aligned with the typical needs of our users.
- While a theoretical care for Identity data privacy was outlined, the reference implementations did not reflect it.
- There was no self-hostable and/or usable Identity server, only a centralized server.
We set on to build mxisd as you know it today, a fully-fledged Identity Server for Matrix with many more features that typically cover what would be expected of what you would call an "Identity server". We spent several years learning the inner workings of the protocol and the various implementations to ensure all we did was 1) in line with the specification for full inter-polarity and 2) aimed towards a **privacy-centric behaviour**.
Over time, we have added more and more **control for users and administrators alike**, allowing them things like:
- Choose if their data is sent to the central Matrix.org server or not
- Use 3PIDs for authentication and discovery without adding them to the homeserver **ensuring Identity and Home servers are independent**, as required by the specification.
Recently, GDPR or similar legislation finally took a stance from an end-user privacy point of view, instead of corporations and service providers. Users must be given the means and rights so their data is safe and private by default. This directly aligns with our goals with mxisd.
## Choices are never easy
We also made hard choices, clearly **preferring privacy over convenience** by:
- [Not including the Matrix.org servers by default](https://github.com/kamax-matrix/mxisd/issues/76) in 3PID searches, giving once again **choice and explicit consent** from administrators on behalf of their users, while remaining compliant with the spec.
- [Making Federation opt-in](https://github.com/kamax-matrix/mxisd/commit/10f9126c) instead of opt-out by not trying to probe HTTP endpoints if a SRV record is not present.
## Improving your privacy, one commit at the time
We will keep working on improving how we **safeguard** your privacy and your Private Identifiable data by:
- Following feedback from the community, improve the whole user experience of being prompted for the choice to add a 3PID on the Matrix.org for discoverability. We will do a better job at the timing of such notifications and also how it is managed so your users can give **informed and unambiguous consent** for it. This is done as part of issues [#93](https://github.com/kamax-matrix/mxisd/issues/93) and [#98](https://github.com/kamax-matrix/mxisd/issues/98)
- Actively blocking changes from [New Vector](https://beta.companieshouse.gov.uk/company/10873661), the for-profit currently behind Matrix.org and owner of the synapse and Riot projects, that threatens privacy and control, with the possibility to still opt-in to their changes.
mxisd v1.3.0 will contain a lot of those privacy-protecting changes, the most notables being:
1. Opt-in to prompt users to publish their 3PID binding to the central server if those are considered remote, making any 3PID acceptable by default. Currently, this is opt-out.
2. Aggressively block any 3PID unbind attempts from synapse given [MSC1194](https://github.com/matrix-org/matrix-doc/issues/1194) at the time of writing (1st Feb 2019).
## MSC1194/MSC1915, synapse and impacts on your privacy
So why are we aggressively blocking a specific behaviour when we have always tried to be as invisible as possible and providing a better user experience? Because for the first time, your private data are actively at risk.
It is important to clarify that MSC1194/MSC1915 is still open and under review, which means it is not ready, and we have given extensive feedback to it both on how it could be problematic for privacy and not mirroring the other actions where a clear, specific user consent is given. But all would still be well if MSC1194 was just a theoretical thing.
Sadly, synapse has been implementing it with several arbitrary choices which directly lead to your personal identifiable data (Emails, phone numbers, Matrix ID) potentially leaked to an arbitrary 3rd party server which you did not choose, doe not have any control over, and without being informed of such transmission of data - synapse doesn't use the Identity server configured in your Matrix client ([the client has no mean to send it either](https://matrix.org/docs/spec/client_server/r0.4.0.html#post-matrix-client-r0-account-3pid-delete)) but picks its own.
We have spent almost a year attempting to discuss this with the New Vector developers but without any success, while the MSC was constantly being de-prioritized regardless of our privacy concerns and its illegality under European GDPR law.
Given privacy is *de facto* not a priority for them, we have decided to take action by:
- Actively blocking the endpoint, so data that you control cannot be altered by a remote unknown entity
- Warn users about those potential privacy leaks by sending a notification to the 3PID address, if it is present in one of the Identity stores you have configured.
### MSC1915
The [MSC1915](matrix-org/matrix-doc#1915) is labeled as "an alternative proposal to [#1194](matrix-org/matrix-doc#1194)" when it is in fact just the same proposal, just worded differently. It does not taken into account the feedback given on the original MSC (feedback which has yet to receive any acknowledgement on the MSC itself).
The current implementation of it has lead to various reports of breakage but is also [illegal under GPDR](https://github.com/matrix-org/synapse/issues/4540) as your personal and identifiable data can go off to an arbitrary Identity server, which users never chose.
To this day, despite our repeated feedback, comments and several discussions, nothing has been done by the Matrix.org administrators which also are the developers of synapse and Riot. The proposal is rewritten without taking care of the previous one and the reported issues up to now, and only seem to be about damage control rather than fixing existing problems.
### How does it affect you?
Concretely:
- Upon attempting to remove a 3PID from your profile, synapse might send your personal data to an unknown 3rd party server. As a user, this is a leak of your personal and identifiable data **without your explicit and unambiguous consent**. As a system administrator, this leaves you open to GDPR law suits since you did not safeguard your user private data and potentially shared it with a remote server.
- While there is nothing mxisd can directly do about synapse sending off data to potentially random servers, mxisd can at least take action if such a request is received: it will **inform** you so that you are **aware** of those attempts, block those attempts to prevent any abuse from malicious Homeserver owners.
### You don't care about this and just need 3PID removal to work in clients/servers that do not respect your privacy
Current MSC 1915 allow for an escape route by sending some specific status codes. The endpoint can therefore be intercepted in the reverse proxy and made to return such value without ever hitting mxisd.
Example with a nginx snippet configuration:
```nginx
server {
# Rest of config...
location /_matrix/identity/api/v1/3pid/unbind {
return 404;
}
# Rest of config...
}
```
### What can you do to help?
We have opened [an issue on the synapse repo](https://github.com/matrix-org/synapse/issues/4540) and we would appreciate if you could show your support if privacy is important to you and do not want your private data to just be broadcast randomly.
If you would like to request a way to remove 3PIDs binding the same way as you add them, which should have existed in the specification from the start, leave a comment on [MSC1194](https://github.com/matrix-org/matrix-doc/issues/1194).