Skip to content

Instantly share code, notes, and snippets.

@maxidorius
Last active November 16, 2023 00:05
Show Gist options
  • Save maxidorius/5736fd09c9194b7a6dc03b6b8d7220d0 to your computer and use it in GitHub Desktop.
Save maxidorius/5736fd09c9194b7a6dc03b6b8d7220d0 to your computer and use it in GitHub Desktop.
Notes on privacy and data collection of Matrix.org

Notes on privacy and data collection of Matrix.org


This version of the document is no longer canonical. You can find the canonical version hosted at Gitlab and Github.

PART 2 IS OUT, INCLUDING THE DISCLOSURE OF A GLOBAL FEDERATION DATA LEAK, AND THE ANATOMY OF A GDPR DATA REQUEST HANDLED BY MATRIX.ORG. SEE THE REPOS ABOVE.

@ara4n
Copy link

ara4n commented Jun 14, 2019

Thanks for the detailed analysis. Some of the points are accurate, specifically:

  • We should probably provide a click-thru when users interact with 3rd party identity lookup servers or integration managers
  • We should hash contacts when doing bulk lookups
  • Riot/Web has a bug where it talks to the integration manager too frequently (element-hq/element-web#5846)
  • Notary servers should eventually be removed entirely (as per matrix-org/matrix-spec-proposals#1228).

Much of the rest is incorrect or hyperbolic however, and I've posted a response at https://matrix.org/~matthew/Response_to_-_Notes_on_privacy_and_data_collection_of_Matrix.pdf (apologies for the PDF, but Google Docs doesn't seem to expose a read-only view of commented docs.)

@maxidorius
Copy link
Author

maxidorius commented Jun 14, 2019

Much of the rest is incorrect or hyperbolic however

I think you need to do better than that. I'll avoid duplicating my reply from Hacker News and focus on fact checking. When we put together our research, we used a very simple methodology:

  • Write down all we know from memory that is problematic for privacy
  • Check our own implementation code, and code in reference implementations which define fundamental behaviour (like synapse's keys fetching)
  • Dig a little bit further in those areas, do some thought experiments as if we were an attacker with the intent to get our hands on personal identifying data/metadata
  • Put together some scenarios, try it out and double check that we're not claiming things that are fundamentally incorrect

Anyone who believe we are incorrect can simply use the following methods to double check everything:

  • For anything Riot web/desktop, open the dev tools of the browser/electron, go in the network tabs and check out the requests/responses.
  • Check synapse logs, typically with tail -f, that will contain each endpoint called and when; we give links to the related endpoints.
  • For anything else, use a reverse proxy or a HTTP sniffer to see requests in real-time, while replacing matrix.org/vector.im in config/code to your own setup and simply see the requests/responses flowing.

You certainly try hard to present the whole research under a worse light by pointing to proposals that are not implement yet, but those are irrelevant. The point of this document is not to give Matrix.org a list of things to improve for whenever they feel like it. The point of this document is to tell Matrix users what is happening, so they can start hardening their config if they care. That you plan to solve the issues at some point in the future doesn't change the fact that those are happening right now, and some for years and years.

You have every right to reply to such a research document if you believe it is incorrect. But then I ask that you do so in a respectful manner, by showing with hard facts and protocol exchanges that things are not happening in a comprehensive manner. I did not work alone on this document, far from it. Please be mindful that we worked hard to put this together, but we did not do it for you. We did it for Matrix users who are unaware of what is going on. We did it for Grid users who want something better.

And because we strongly believe we should put our money where our mouth is, we will work on not having such leaks in The Grid protocol, Gridepo and Soler. This certainly should show with hard facts that much of this document is not, as you put it, incorrect.

@juliangaal
Copy link

Which service would you recommend instead?

@maxidorius
Copy link
Author

@juliangaal We purposefully held off making any recommendation, because the research highlights many issues/behaviour that can be solved in several ways. Each way would depend on your use case. We can discuss it further in the Matrix room (see end of the paper). We wish to keep this research page neutral.

@juliangaal
Copy link

@maxidorius I understand. Great work nevertheless

@maxidorius
Copy link
Author

For anyone subscribed, we have corrected some sections, added several new sections and new identified leaks thanks to Community feedback since the original publishing! See the revisions.

@maxidorius
Copy link
Author

maxidorius commented Jun 17, 2019

@ara4n Given that we're not going to be significantly changing the doc anymore, as the target audience has given us the feedback we were looking for, I'll wrap this up by answering your notes at the time posted as a gesture of good faith and respect. I'll use the comment numbering from the PDF directly.

Comment 1

The integration manager is closed source, and its behaviour has been documented here. So the only way to learn about its behaviour was to reverse engineer it with the client and the homeserver. Reverse engineering is factual and we did use it. 100% relevant.

Comment 2

Does it really?. It can, but it doesn't have to. It's just your choice is making synapse do it.

Comment 3

The document does not say it is mandatory. Only that the user is strongly pushed to do it.

Comment 4

The document does not say it is mandatory. Only that the user is not informed of the specifics (single contact vs the whole phonebook).

Comment 5

Except that's not what we're talking about. You're in the TL;DR section, read everything first.

Comment 6

That the file is called "MatthewPicture2015.jpg" or "dkjkjfoeDSDfdsfkERR" makes no difference that it's publicly accessible. And that all files in the repo are. There is no access control.

Comment 7

But encryption is not enabled by default, and the doc states it reviews default behaviour.

Comment 8

all of the current non-centralised identity servers (e.g. mxisd) either restrict you from being contactable(by not publishing your email address to the wider identity db) or from being able to contact people (because their emails are not published on the wider identity db)

Let's get some facts straight:

  • mxisd has allowed lookups to involve matrix.org by default as a last resort until the beginning May 2018, so 18 months later, due to privacy concerns that were left unanswered. Users can still opt-in to this day. Either way, they can perfectly talk to the wider identity DB. This is also stated in our FAQ.
  • mxisd allowed to publish 3PID binding to matrix.org by default up to v1.3.0 - so for 2+ years. See the docs of the release just before about it.. You can also see issue #76 which shows we initially were talking with you, until we decided not to anymore because of our concerns for privacy and your lack of care in that aspect.
  • Because we allowed remote bindings in case the user would not be found by people on matrix.org, we had the binding on matrix.org by default. Users were very much contactable if they chose to, after we explicitly got their informed consent.
  • We discussed those mechanisms in #matrix-identity:matrix.org - your official room for it! I encourage people to scroll back for discussions in 2017 and 2018!
  • I also told you at length about those, in public rooms and in private messages. I also explained to you once again how mxisd works on the closed door Jitsi call for #1194. I've told Dave several times about those too, and Dave is in the mxisd room. Dave is the core team member in charge of Identity as per your open governance and was since I joined in 2017.
  • From v1.3.0 (10th of Feb 2019), we decided to drop support for remote bindings and sessions because of all the privacy concerns we had. We even wrote a wiki page about it. It hasn't been reworded since, so you can even see how it was at that time.
  • We told you about it in synapse issue #4540. That issue is yet another privacy problem (documented in the doc here) which we brought up and is the 2nd highest +1 issue from both open and closed ones at the time of writing. But the issue was closed without addressing the 5 privacy points I brought up using a MSC which would not solve it. We talk about that MSC1915 on the wiki page mentioned.

So while the previous quoted statement is technically correct as of today, ignoring everything since start of 2017, the following is not:

The fact that mxisd can delegate lookups to the vector.im server doesn't change this, and this is why the warning exists. This is also why we've been holding out for genuinely decentralised rather than federated identity architecture to replace sydent.

You haven't been holding out for decentralised because of mxisd since mxisd supported the needed features for at least 18 months. During that time, you never reached out to us despite our efforts. Matrix.org always had higher priorities than Identity and privacy.

mxisd is NOT the reason why no progress was made. Your prioritization which you did all on your own is. We can also talk about how you deprioritized working on 1194 purposefully only because I requested updates about it and triggered its own Email removal section.

You have been well-informed about mxisd capabilities which you even mentioned in FOSDEM presentations in 2017 (or maybe 2018, possibly both). Dave is in the room and his role as a core board member is to be aware of what is going on. You have been purposefully lying about this for years now in an attempt to hide what mxisd could accomplish while remaining spec compliant. Why?

Comment 9

There are at least two other identity serve implementations out there, fwiw

You highlighted this:

only other

but the full sentence is this:

Riot devs are well aware of the only other Identity server mxisd which federates and can include data from vector.im.

Please give a link to the source that those two fit the requirements in the same sentence: which federates and can include data from vector.im..

Comment 10

We agree.

Comment 11

Thank you for confirming that our statement is factually correct.

Comment 12

Thank you for confirming that our statement is factually correct.

Comment 13

So to find the privacy policy of vector.im we need to go to github.com, then find a doc under a matrix.org folder...
How is a user new to Matrix supposed to know that if all they see is vector.im in the Identity Server URL field of their client?

What about a link on your main website: https://vector.im/?

Ok for the oversight.

Comment 14

But you still need the Identity server to add the Email to the user setting, right? Your comment seems out of place.

Comment 15

This is considered acceptable UX; if a user is trusting the HS to deliver them messages reliably, it is also reasonable to trust the HS to unbind 3PIDs non-maliciously rather than pester the user with confirmation, given the user already confirmed they wanted the HS to bind the 3PID in the first place

We shown in the document in the first section of Riot that the user was never told about the binding. That would make your UX unacceptable, right?

Comment 16

It is obvious that the act of locating people by email address and phone number will involve sharing them.

Yes, for the people that the user wants to talk to, not for the full address book before the user can even start looking for the contact. What about only when a person click on the contact they are interested in? (or whatever UX you could wipe up).

Comment 17

OK.

Comment 18

OK.

Comment 19

My gut feeling is that it would be stated in their terms of services or their cookie policy which you need to accept upon using their services. Double checking will be left as an exercise to the readers. I don't think explaining why it's set makes it any relevant when the website is very sensitive to privacy. You would definitely not want that to be set.

Comment 20

The research paper does not have proposals in scope, only spec documents published as standard/stable at the time of writing.

Comment 21

I don't see the relevance of your comment. We gave the link so people can see the request/response. That it's federation doesn't matter to the point made.

Comment 22

Until we wrote the doc (so not including your last comment on it written after), the bug never talked about removing the calls, just to not duplicate them. The privacy issue around it is not even mentioned once, and the issue is open for ~18 months. That it was already documented would not have helped for the issue at hand.

Do you have some other documentation that shows you were aware of the privacy issue around the behaviour, or that the behaviour was problematic in the first place?

Comment 23

The context that you miss to quote in its entirety (emphasis mine):

vector.im is receiving the following information without the user's knowledge, some without the user even opening the Integration server window:

  • A steady stream of requests directly related to user activity and usage pattern of Riot and Matrix.
  • Their Matrix ID and their IP, Riot directly connecting to scalar.vector.im.
  • The rooms which the user is part of.

The sentence means:

  • If the user opens the integration window (or the client if one is already present), all of those elements are sent
  • If the user did not open one, only some are sent which are the stream of requests, their Matrix ID and their IP

In both cases, the request you've given as an example is indeed the one. Thank you for confirming this is factually correct.

Comment 24

Github again? Is this link also given one way or another to the user directly in Riot when they use the integration manager? If yes, could you show us a screenshot please?

Comment 25

Yes, and the document specifically state at the beginning that default settings is what is taken into account, which is therefore well in scope.

Thank you for confirming that our statement is factually correct.

Comment 26

Yes, and the document specifically state at the beginning that default settings is what is taken into account, which is therefore well in scope.

Thank you for confirming that our statement is factually correct.

Comment 27

I believe we are now at our 3rd one.

Comment 28

Which is the case by default as per comment 26.

Thank you for confirming that our statement is factually correct.

Comment 29

But it is secure right? You do not seem to oppose the statement.

Comment 30

But End-to-End encryption is not enabled by default, so it's not in scope of this document.

Comment 31

So for now, they are not.

Thank you for confirming that our statement is factually correct.

Comment 32

We recognise we used a bad example to illustrate that the files are forever accessible under the same ID. We have corrected our document with a better illustration. Thank you for pointing it out.

Comment 33

But still in use. And I'm guessing always been in use. So it only was obvious during reverse engineering (!).

Comment 34

Thank you for confirming that our statement is factually correct.

Comment 35

Thank you for confirming that our statement is factually correct.

Comment 36

OK

Comment 37

Double check your document. Your copy/paste screwed up the formatting and the full context is there. Compare with the Gist view of the original doc.

About other Homeservers being affected in their use of the Matrix.org services by the outage: Thank you for confirming that our statement is factually correct. The context is clear and the next sentence specifically list what was affected. We do not state that they were compromised. The next section talks about how they could have been impacted from a security point of view, or be affected by Denial of Service.

Comment 38

We removed that sentence soon after reading your feedback. Thank you for clarifying.

Comment 39

Thank you for confirming the impact that the pattern of centralisation outlined in this document could have allowed the attacker to do "a lot of very unpleasant things".

Comment 40

Thank you for confirming that our statement is factually correct.

Comment 41

Let's respectfully agree to disagree.

Comment 42

We've clarified our wording soon after seeing your feedback of taking a sentence out of the important context. We recognise that our wording could have been misleading.

Comment 43

OK, but you do not answer the questions. GDPR is a law in effect for more than a year. You simply cannot process the personal identifiable data that you currently get without a lawful basis.

What is the lawful basis under which you process their personal data, since we've illustrated all over the document that you do not get informed consent?

Comment 44

I did disclose Grid in previous research document like The Server ACL one, but you used it against us to say "look, they are promoting their hostile fork by using Matrix weaknesses instead of contributing to it!". Now that we don't and make sure it's only about Matrix in the document, you also use it against us. You also never fail to slander us for something which is your own fault in the official Matrix rooms.

So here is me asking you officially, in a public setting, on record: Which one do you want? Disclosure or not disclosure?


I hope all the links, sources and issues I have linked and mentioned here are proof enough that I was very much trying to make you aware of all of this, but nobody was listening, or was purposefully dragging their feet to make a point instead of thinking for their users.

@maxidorius
Copy link
Author

maxidorius commented Jun 17, 2019

@ara4n Following some links in my own links, I came accross this old issue: prism-break#1936 where I list the main concerns that I've re-documented in details in this research paper.
To which you reply. So you've been aware of the major points of this document for more than a year now. I believe this changes some of your comments where you claim ignorance or oversight.

We also mentionned having Google TURN servers hardcoded, and it seems like this issue is still happening on mobile clients. Could you confirm or deny?

@ara4n
Copy link

ara4n commented Jun 17, 2019

You have been well-informed about mxisd capabilities which you even mentioned in FOSDEM presentations in 2017 (or maybe 2018, possibly both). Dave is in the room and his role as a core board member is to be aware of what is going on. You have been purposefully lying about this for years now in an attempt to hide what mxisd could accomplish while remaining spec compliant. Why?

You are accusing me of "purposefully lying for years" in paragraphs of shouty bold text, while simultaneously acknowledging that I've been promoting mxisd and its capabilities in my talks. (And for that matter we've also been promoting it on matrix.org/blog). This is an almost farcical paradox. It's also starting to sound as if the root of all your unhappiness here may be due to feeling upset that mxisd doesn't get more recognition...

I maintain that the point of an IS is to discover people to talk to on Matrix based on 3PID, and the only way today to usably publish yourself as discoverable is by using the logically centralised sydent servers at vector.im/matrix.org. You can of course run a local IS like mxisd, but it will only render you discoverable to users on the same identity server (unless it delegates to the central servers), which is of very limited usage. The mxisd could try querying other ISes based on the domain of the 3pid (if it has a domain), but this relies on the 3pid having the same domain as the mxid, which is pretty unusual in the real world.

I would much rather (as I said to you years ago when trying to provide input into your IS work) that we spent the time instead providing a reliable and privacy-preserving way of letting users globally publish their 3PID->mxid mappings (if they want to), which doesn't depend on centralised servers at all - which is why we haven't prioritised the federated bodge.

An alternative approach would be to use DNS itself or a DNS-equivalent architecture, similar to ENUM, to let servers recurse identity lookups to a root server and then back down to a given deployment-specific server. But as far as I know, mxisd doesn't support that, nor has anyone proposed it as a design. Plus it would still depend on root servers being a SPOF/SPOC, and would suffer all the same attacks as DNS itself - and be tantamount to reinventing the DNS.

This is why we'd rather pursue an approach which is fully decentralised - i.e. a signed shared datastructure of hashed-3pid -> mxids, scoped to whatever visibility the publisher desires, which anyone can participate in hosting, rather than depending on centralised ISes for global lookups to function.

You also never fail to slander us for something which is your own fault in the official Matrix rooms.

I'm sorry you consider this slander(!)

This sort of hyperbolic rhetoric is why we gave up trying to work with you months ago.

I believe this changes some of your comments where you claim ignorance or oversight.

No, the word oversight means "an unintentional failure to [...] do something." - i.e. the issue in question is an unintentional failure, and one which we haven't solved yet.

We also mentionned having Google TURN servers hardcoded, and it seems like this issue is still happening on mobile clients. Could you confirm or deny?

Yup, the bug is still open, and Google STUN is still hooked up as a last resort to help people who have failed to configure their own VoIP servers:

https://github.com/matrix-org/matrix-ios-sdk/blob/develop/MatrixSDK/VoIP/MXCallManager.m#L34
https://github.com/matrix-org/matrix-android-sdk/blob/master/matrix-sdk/src/main/java/org/matrix/androidsdk/call/MXWebRtcCall.java#L602

This is a good example of where a relatively low priority (for us) issue has not been higher prioritised, as it only affects people who have failed to configure TURN servers on their homeservers.

@maxidorius
Copy link
Author

maxidorius commented Jun 17, 2019

You are accusing me of "purposefully lying for years" in paragraphs of shouty bold text, while simultaneously acknowledging that I've been promoting mxisd and its capabilities in my talks. (And for that matter we've also been promoting it on matrix.org/blog).

Please don't take my sentence out of context and only reply to it like it was a standalone sentence. I give you the courtesy to not do so, please do the same. My sentence is a reply to your comment, which claims mxisd cannot do those things [1] and shifts the blame on us for not moving Matrix forward.

I have shown proof that:

  • mxisd could do those things [1] for a long time that you claim it can't, and still can do one of them in the current releases.
  • you knew since we told you about it.

[1] "those things" refer to the two restricted actions of your comment #8, quoting:

  • "being contactable(by not publishing your email address to the wider identity db)"
  • "from being able to contact people (because their emails are not published on the wider identity db)"

Even if you refute we told you, you had every chance to check your facts before making such a statement. So yes, I have no problem claiming you are purposefully lying. The question is to what goal. Please do not comment further on this point unless you can prove you did in fact do your background check of mxisd features/source code and that mxisd cannot technically perform lookup on the central IS due to the lack of code for it.

Yup, the bug is still open, and Google STUN is still hooked up as a last resort to help people who have failed to configure their own VoIP servers:

Thanks, we'll incorporate this important info and create a new section about VoIP altogether. Thank you for this useful feedback.
Edit: It's here


I will not reply to the rest of your comments given their personal nature, and their lack of relevance for the document.

[Edit: removed section that was replying to an irrelevant section by mistake, clarify what those things are]

@maxidorius
Copy link
Author

maxidorius commented Jul 7, 2019

So after double-checking again, it seems like Comment 38 is not factually correct and that Cloudflare DOES TLS termination, directly having access to all the data in clear.

Here is a Client request done now:

$ curl -sv https://matrix.org/_matrix/client/r0/login
*   Trying 2606:4700:10::6814:15ec...
* TCP_NODELAY set
* Connected to matrix.org (2606:4700:10::6814:15ec) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS change cipher, Client hello (1):
* (304) (OUT), TLS Unknown, Certificate Status (22):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using unknown / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=www.matrix.org
*  start date: Jun 11 11:32:44 2019 GMT
*  expire date: Sep  9 11:32:44 2019 GMT
*  subjectAltName: host "matrix.org" matched cert's "matrix.org"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (OUT), TLS Unknown, Unknown (23):
* Using Stream ID: 1 (easy handle 0x55974db54580)
* (304) (OUT), TLS Unknown, Unknown (23):
> GET /_matrix/client/r0/login HTTP/2
> Host: matrix.org
> User-Agent: curl/7.58.0
> Accept: */*
> 
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Newsession Ticket (4):
* (304) (IN), TLS handshake, Newsession Ticket (4):
* (304) (IN), TLS Unknown, Unknown (23):
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (IN), TLS Unknown, Unknown (23):
* (304) (IN), TLS Unknown, Unknown (23):
< HTTP/2 200 
< date: Sun, 07 Jul 2019 09:39:09 GMT
< content-type: application/json
< set-cookie: __cfduid=dc79ff628c73af629e2cb1ccbe2c117be1562492349; expires=Mon, 06-Jul-20 09:39:09 GMT; path=/; domain=.matrix.org; HttpOnly
< cache-control: no-cache, no-store, must-revalidate
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 4f28d9820c6bd4b4-BRU
< 
{
    "flows": [
        {
            "type": "m.login.password"
        }
    ]
}
* (304) (IN), TLS Unknown, Unknown (23):
* Connection #0 to host matrix.org left intact

Here is a Federation request done now:

$ curl -sv https://matrix.org:8443/_matrix/federation/v1/version
*   Trying 2606:4700:10::6814:14ec...
* TCP_NODELAY set
* Connected to matrix.org (2606:4700:10::6814:14ec) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS change cipher, Client hello (1):
* (304) (OUT), TLS Unknown, Certificate Status (22):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using unknown / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=www.matrix.org
*  start date: Jun 11 11:32:44 2019 GMT
*  expire date: Sep  9 11:32:44 2019 GMT
*  subjectAltName: host "matrix.org" matched cert's "matrix.org"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (OUT), TLS Unknown, Unknown (23):
* Using Stream ID: 1 (easy handle 0x56503e398580)
* (304) (OUT), TLS Unknown, Unknown (23):
> GET /_matrix/federation/v1/version HTTP/2
> Host: matrix.org:8443
> User-Agent: curl/7.58.0
> Accept: */*
> 
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Newsession Ticket (4):
* (304) (IN), TLS handshake, Newsession Ticket (4):
* (304) (IN), TLS Unknown, Unknown (23):
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (IN), TLS Unknown, Unknown (23):
* (304) (IN), TLS Unknown, Unknown (23):
< HTTP/2 200 
< date: Sun, 07 Jul 2019 09:36:05 GMT
< content-type: application/json
< set-cookie: __cfduid=db97ca0304b4159c2ac95eb7e37e734851562492163; expires=Mon, 06-Jul-20 09:36:03 GMT; path=/; domain=.matrix.org; HttpOnly
< cache-control: no-cache, no-store, must-revalidate
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 4f28d4f6fcf5442b-BRU
< 
{
    "server": {
        "name": "Synapse",
        "version": "1.1.0rc1 (b=matrix-org-hotfixes,43e01be15)"
    }
}
* (304) (IN), TLS Unknown, Unknown (23):
* Connection #0 to host matrix.org left intact

Edit: vector.im as an identity server:

$ curl -sv https://vector.im/_matrix/identity/api/v1 | jq
*   Trying 2606:4700:30::681f:475f...
* TCP_NODELAY set
* Connected to vector.im (2606:4700:30::681f:475f) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
} [5 bytes data]
* (304) (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS Unknown, Certificate Status (22):
{ [1 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [15 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [2170 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [80 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* (304) (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* (304) (OUT), TLS Unknown, Certificate Status (22):
} [1 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using unknown / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=vector.im
*  start date: Feb 14 00:00:00 2019 GMT
*  expire date: Feb 14 12:00:00 2020 GMT
*  subjectAltName: host "vector.im" matched cert's "vector.im"
*  issuer: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=CloudFlare Inc ECC CA-2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* Using Stream ID: 1 (easy handle 0x560bab614580)
} [5 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
> GET /_matrix/identity/api/v1 HTTP/2
> Host: vector.im
> User-Agent: curl/7.58.0
> Accept: */*
> 
{ [5 bytes data]
* (304) (IN), TLS Unknown, Certificate Status (22):
{ [1 bytes data]
* (304) (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* (304) (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
} [5 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
< HTTP/2 200 
< date: Sun, 07 Jul 2019 22:57:56 GMT
< content-type: application/json
< set-cookie: __cfduid=d14ef1f6254ebb5c211fdb3493dfabfbf1562540276; expires=Mon, 06-Jul-20 22:57:56 GMT; path=/; domain=.vector.im; HttpOnly
< access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
< access-control-allow-origin: *
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 4f2d6b993a53d4b4-BRU
< 
{ [2 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* Connection #0 to host vector.im left intact
{}

In all cases, we can see the headers set-cookie, server, cf-ray and expect-ct with values set by Cloudflare, which would not be possible if TLS termination was done directly on matrix.org/vector.im servers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment