Opened 9 months ago

Last modified 9 months ago

#21005 new enhancement

Enforce stronger ciphers in Tor Messenger

Reported by: cypherpunks Owned by:
Priority: Medium Milestone:
Component: Applications/Tor Messenger Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


In considering to limit the standard ciphers to the ones recommended in RFC 7525 from 2015 for torbirdy (ticket:20751), and to minimize the risk of downgrade attacks, it might be advisable to find a similar solution for tor messenger, too. (Maybe even a similar way of handling exceptions in the UX)

Therefor I suggest the following standard settings (torbirdy, ticket:20751)

  1. tls version 1.2 (RFC 5246 from 2008, tls version 1.3 is is going to be introduced next year)

security.tls.version.min = 3

  1. recommended ciphers in accordance to RFC 7525 (from 2015)

security.ssl3.* false
security.ssl3.ecdhe_rsa_aes_128_gcm_sha256 true
security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256 true

  1. Prevent Insecure Recognition

security.ssl.require_safe_negotiation true
security.ssl.treat_unsafe_negotiation_as_broken true

  1. Certificate Pinning

security.cert_pinning.enforcement_level = 2

ticket:16494#comment:5 suggests to implement a tbb like slider for Tor Messenger and to enforce a stronger set of ciphers just for the higher security settings. As explained in to follow the recommendations of the last RFCs tls version 1.2 has to be used (otherwise the recommended ciphers can't be used). Today, most XMPP server support TLS version 1.2 and are able to use modern ciphers, allowing a downgrade of the ciphers just allows downgrade attacks and weakens the overall security. Ie, an user should not enforce stronger ciphers by setting a higher security level, instead he should get a message in the moment the the server doesn't support the (stronger) standard cipher than he can decide what to do, ie either to use a different XMPP server (a server that doesn't support tls v 1.2 in 2017, is just a bad choice and the server owner might just do a bad job and even save password as md5 hash etc) or deliberately use the xmpp sever (if the server used to support stronger encryption and stops to do so, the user might even know that something is going wrong)

Child Tickets

Change History (2)

comment:1 Changed 9 months ago by arlolra

Thanks for your pursuit.

an user should not enforce stronger ciphers by setting a higher security level

Right, I reconsidered that here,

As an experiment, I changed my settings to what you suggested above.

When connecting to my accounts, I was presented with,

Error: An error occurred during a connection to freenodeok2gncmy.onion:6697.

Cannot communicate securely with peer: no common encryption algorithm(s).

Error code: <a id="errorCode" title="SSL_ERROR_NO_CYPHER_OVERLAP">SSL_ERROR_NO_CYPHER_OVERLAP</a>

That's freenode's onion (we need to consider IRC as well).

Running nmap -Pn --script ssl-enum-ciphers -p 6697 gives me,

|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A

The first one on the list is recommended in RFC 7525, but not supported in NSS, see ticket:18129#comment:11

or deliberately use the ... server

which would mean enabling security.ssl3.dhe_rsa_aes_256_sha as a distinguisher. Someone suggested this isn't an issue because,

your email/xmpp provider already "knows" you

but that's a global setting that's going to be advertised to all connections and might not play well with temporary accounts in #16606

On another note about the security.ssl3.*, the rc4 suites aren't enabled despite saying true. See ticket:18129#comment:7 for the client hello.

Anyways, I think I agree with the spirit of the ticket.

comment:2 Changed 9 months ago by arlolra

Keywords: Tor Messenger removed
Summary: Enforce Stronger Ciphers in Tor MessengerEnforce stronger ciphers in Tor Messenger
Note: See TracTickets for help on using tickets.