[Pidgin] #17217: NSS Handshake fails with TLS1.3

[Pidgin]

#17217: NSS Handshake fails with TLS1.3
--------------------------------------+------------------------
 Reporter:  vobej                     |       Owner:
     Type:  defect                    |      Status:  closed
Milestone:  2.10.13                   |   Component:  libpurple
  Version:  2.12.0                    |  Resolution:  fixed
 Keywords:  ssl nss handshake tls1.3  |
--------------------------------------+------------------------
Changes (by dx <dx@…>):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  2.12.1 => 2.10.13


Comment:

 (In [2deceb0f9ef9]):[[BR]]
 ssl-nss: Use default NSS ciphersuites/TLS versions, fixes TLS 1.3 issues

 Recent NSS versions (3.27, 3.29) added TLS 1.3 support without enabling it
 in
 the default configuration. But, for historical reasons, libpurple always
 enables the latest TLS version, sets custom ciphersuite lists and disables
 all
 the defaults, including ciphersuites needed for TLS 1.3 to work. This
 means
 that connections to servers that support TLS 1.3 (for example, anything
 behind
 cloudflare) always fail with "SSL Handshake Failed".

 The solution is to just not do any of that. NSS has decent defaults, they
 regularly update them and their devs will always know better than us.

 Fixes #17217

 The rest of the commit log is about those historical reasons.

 The main user of NSS is firefox, which keeps its own ciphersuite and TLS
 version preferences. In the past there were periods of time where firefox
 was
 ahead of the NSS defaults, which caused connection issues or eyebrow-
 raising
 ciphersuite choices. So libpurple tried to copy those prefs. I'm being
 told
 by the NSS devs that nowadays they do a better job at keeping up.

 The referenced issues in the deleted code are:

 - Trac #1435 (2007), some connection issues due to disabled ciphers.

 Probably NSS 3.11 or 3.12. So old it's not relevant, but interesting
 anyway.
 The fix (hg 32a4cf358f9c) was enabling things that look like bad choices
 nowadays, but the NSS defaults weren't better. Dark times. It looks like
 it was
 effective to solve connection issues. Newer NSS versions definitely fixed
 this,
 mostly with 3.14 (2012)

 - Trac #15909 (2014), TLS 1.1 and 1.2 supported but not enabled.

 NSS 3.14 (2012) introduced TLS 1.1; NSS 3.15.1 (2013) introduced TLS 1.2.
 It wasn't until NSS 3.18 (2015) that they were enabled by default. The fix
 was
 hg f4e63e354f45. This isn't needed anymore.

 - Trac #16262 (2014), "Enabled ciphers in NSS unnecessarily limited"

 Someone messed with ciphersuites in ejabberd and broke things. News at 11.
 The ticket says "we don't have ciphers that support forward security"
 ignoring
 that the DHE ones have that.

 This was NSS 3.17 (2014). The fix (hg f26d96f03176) took the ciphersuite
 lists
 from firefox to enable ECDHE and disable the defaults. ECDHE ciphersuites
 were
 enabled by NSS 3.21 (2015).

 - Trac #15862 (2014), "Disable Export ciphers and DES in SSL"

 Windows pidgin 2.10.7 (2013) bundled NSS 3.13.6 (2012). Those were
 disabled by
 NSS 3.14 (2012). Pidgin 2.10.8 (2014) updated to NSS 3.15.4 (2014).

 ---

 This means that old NSS versions with bad defaults will use those bad
 defaults.
 The earliest version in current LTS distros is 3.26, while our windows
 builds
 have the oldest version, 3.24. These versions aren't affected by any of
 the
 issues above.

--
Ticket URL: <https://developer.pidgin.im/ticket/17217#comment:2>
Pidgin <https://pidgin.im>
Pidgin