Giters

coyim / coyim

coyim - a safe and secure chat client

Home Page:https://coy.im

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RFC 9266: Channel Bindings for TLS 1.3 support

Neustradamus opened this issue · comments

commented

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?

Little details, to know easily:

  • tls-unique for TLS =< 1.2
  • tls-server-end-point
  • tls-exporter for TLS = 1.3

Thanks in advance.

Linked to:

commented

Sorry for taking some time on this one. I have added some questions and comments in the PR - if you have answers, it would be useful.

commented

Hello,

Firstly it would be appreciated if you did not mention every single developer and contributor into your issue because of some fears about MitM, for example I have only contributed to the README.md because I adopted this package for Arch Linux, I have never contributed code, so mentioning me here was useless.

However I would like to point out that channel bindings is not the solution to every problem ever caused, you don't slap channel binding in and then the problem is fixed. Its a mitigation technique, it makes things harder, but not impossible, so this is not a "solution" but instead increasing resistance to MitM attacks.

Finally, the MitM attack here is believed to be a lawful request by authorities, this is not a security vulnerability, at least from the software point of view, the cloud hosting providers own the network and hardware they provide you, they are more than able to intercept SSL certificates and packets on their network, or read the data on your server (such as yanking your certificates), and it being a lawful wiretap means they had the permission to do so. There is NOTHING you can do to prevent this.

This is a useful feature for strengthening the resistance to MitM attacks sure, but the real solution here is to always use E2E encryption, especially if you are on public XMPP servers, and if you are not? Self host your own and cut out the companies in the middle which could be compromised.

Take care,
Polarian

commented

@Neustradamus - we consider this behavior abusive. This is our only warning. Desist in abusive behavior, or you will be blocked and reported.

commented

@Neustradamus - As you are well aware, Golang still does not have proper support for tls-exporter channel binding. You know this since you have opened the issue in the Golang crypto issue tracker for this.

Second, the jabber.ru case has nothing to do with this - they were using valid certificates but different ones. Channel Binding for SCRAM would not have helped in that situation. However, pinning of certificates (which Coy already does) would actually help - and it's already there.

I will close this issue - there seems to be no movement on this front from the Golang side, and it is unclear whether the major XMPP servers have support for it anyway.

commented

Dear @olabiniV2, @coyim team,

Thanks for your message.

First, I wish you a Happy New Year 2024 at all the team.

Second, I think it is not good to close unsolved ticket.

Third, @FiloSottile has said here: golang/go#54103

Indeed, we already support EKM via ConnectionState.ExportKeyingMaterial.

What do you need us to change in crypto/tls?

Maybe you can talk with on the ticket about the situation?

Fourth point, for example:

Thanks in advance.