Transport security and authentication
CoyIM will always connect to XMPP servers using TLS. This means that the transport of data from your machine to the server will always be protected by at least one layer of encryption. In most cases, this connection will be done using the XMPP specific STARTTLS extension, which is documented in RFC6120 Chapter 5. CoyIM will negotiate which version of TLS and what cipher suites to be used, as is normal for TLS connections. The minimum acceptable TLS version will always be TLS 1.2, and 1.3 will be preferred. Only a very restricted set of cipher suites are possible to use. Specifically, for versions of Golang 1.12 or higher, these are the possible suites offered, in this order:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305TLS_AES_256_GCM_SHA384TLS_AES_128_GCM_SHA256TLS_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
All of these suites offer forward secrecy, and provide for a high security level.
The STARTTLS extension can sometimes cause too many roundtrips, and there’s also a risk for various downgrade attacks
with this kind of system. For this reason, CoyIM also implements XEP-0368
which allows for lookup of a TLS connection port over DNS SRV entries. This bypasses the clear-text initial connection
necessary for STARTTLS.
TLS provides one layer of transport security, but if Tor is turned on, this provides another level. And if the server in question is a known server with a published version 3 Onion Address, CoyIM will automatically try to connect to this one instead, providing yet another level of transport security and server authentication.
Most applications that use TLS will automatically trust certificates that are valid and which can be validated against the trust roots that ship with your operating system. However, many types of attacks on the certificate authority system has shown that this might not be sufficient for persons at risk. For this reason, CoyIM will use certificate pinning as an additional security measure. What this means is that any time CoyIM sees a new certificate for a server, this can be rejected or accepted, depending on your pinning policy. By default, CoyIM will always ask before using a certificate it has not seen before. But you can also set up CoyIM to automatically reject any new certificate. In this way, even if an attacker manages to get hold of a valid certificate for an XMPP server, you can still be protected.
Authentication
In order to authenticate to the XMPP server, there exists two standard methods. One is to provide a password of some kind, and the other is to first get an OAUTH token and then use that to authenticate to the server. While OAUTH can be extremely powerful, it also brings with it a lot of extra machinery. Specifically, you will usually need to use a browser or an internal web-view where the user can authenticate to the OAUTH provider. Our experience has been that doing this in a high-security setting is simply not viable. For this reason, CoyIM only supports password based authentication to the XMPP server.
XMPP uses the SASL standard to provide for flexible negotiation of authentication mechanisms. CoyIM will use the
strongest method available for authenticating with the server, but in the worst case will fall back to the PLAIN
method. CoyIM supports these mechanisms:
SCRAM-SHA-512-PLUSSCRAM-SHA-512SCRAM-SHA-256-PLUSSCRAM-SHA-256SCRAM-SHA-1-PLUSSCRAM-SHA-1DIGEST-MD5PLAIN
However, if the connection with the server is using TLS 1.3, the -PLUS variants are not available, due to limitations
in the Golang standard library.