Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#3456 closed defect (fixed)

TLS handshake error(unexpected length packet) when recieving MSN contact list

Reported by: bsdunx Owned by: khc
Milestone: 2.5.5 Component: MSN
Version: 2.2.1 Keywords: gnutls tls handshake msn
Cc: gagern, doublehp

Description

I was talking with someone on MSN today and an emoticon was sent to me, pidgin decided to crash on it after about 30 seconds. After that I restarted pidgin I got an error that MSN servers are going down. So after testing another client and all was well, I zapped my .purple directory and recreated my account configuration, the same error came up. I eventually ran in debug mode and here is the relevant(I hope) information.

(18:00:43) MSNCL: Getting Contact List.
(18:00:43) MSN SOAP: No connection to SOAP server. Connecting...
(18:00:43) MSN SOAP: Initializing SOAP connection
(18:00:43) dns: DNS query for 'omega.contacts.msn.com' queued
(18:00:43) dns: Created new DNS child 7312, there are now 1 children.
(18:00:43) dns: Successfully sent DNS request to child 7312
(18:00:43) dns: Got response for 'omega.contacts.msn.com'
(18:00:43) dnsquery: IP resolved for omega.contacts.msn.com
(18:00:43) proxy: Attempting connection to 65.54.170.30
(18:00:43) proxy: Connecting to omega.contacts.msn.com:443 with no proxy
(18:00:43) proxy: Connection in progress
(18:00:43) proxy: Connected to omega.contacts.msn.com:443.[[BR]] (18:00:43) gnutls: Handshaking with omega.contacts.msn.com
(18:00:43) gnutls: Handshaking with omega.contacts.msn.com
(18:00:43) gnutls: Handshake failed. Error A TLS packet with unexpected length was received.
(18:00:43) MSN SOAP: Soap connection error[[BR]] (18:00:43) msn: C: NS 000: OUT
(18:00:43) account: Disconnecting account 0x7a9110
(18:00:43) connection: Disconnecting connection 0xc567a0
(18:00:43) msn: destroy httpconn (0xbff820)
(18:00:43) connection: Destroying connection 0xc567a0

Attachments (2)

bug3456a.patch (5.9 KB) - added by gagern 10 years ago.
%SSL3_RECORD_VERSION for MSN soap, fallback to TLS <=1.0
bug3456b.patch (917 bytes) - added by gagern 10 years ago.
%SSL3_RECORD_VERSION for all GnuTLS connections

Download all attachments as: .zip

Change History (31)

comment:1 Changed 12 years ago by datallah

  • Resolution set to invalid
  • Status changed from new to closed

This is from an an old mtn build, not the released 2.2.1 version; this issue no longer should happen. Please don't use mtn unless you are developing patches.

comment:2 Changed 11 years ago by backslash

The same problem happens also with 2.3.1 stable version. Here is my log:

(10:49:21) proxy: Connection in progress
(10:49:21) proxy: Connected to nexus.passport.com:443.
(10:49:21) proxy: Using CONNECT tunneling for nexus.passport.com:443
(10:49:21) proxy: HTTP proxy connection established
(10:49:21) gnutls: Starting handshake with nexus.passport.com
(10:49:21) gnutls: Handshake failed. Error A TLS packet with unexpected length was received.
(10:49:21) msn: C: NS 000: OUT
(10:49:21) account: Disconnecting account 0x872e590
(10:49:21) connection: Disconnecting connection 0x8a31000
(10:49:21) msn: destroy httpconn (0x8a45ca0)
(10:49:21) connection: Destroying connection 0x8a31000

comment:3 Changed 11 years ago by datallah

I had this happen the other day to me, the solution I found was to use NSS instead of gnutls. I don't know if this is a bug in gnutls itself or our usage of it.

comment:4 Changed 11 years ago by khc

I've googled around and found a debian bug documenting at least one gnutls issue. I don't have the link anymore, but if I recall correctly the bug was fixed fairly recently. I say assume gnutls is at fault unless a user explicitly say he's compiled gnutls from source

comment:5 follow-up: Changed 11 years ago by ranma42

backslash has compiled gnutls 2.2.0 from source and is describing a similar problem in ticket #4646

comment:6 in reply to: ↑ 5 Changed 11 years ago by backslash

Replying to ranma42:

backslash has compiled gnutls 2.2.0 from source and is describing a similar problem in ticket #4646

Yes, I compiled gnutls from tarball. I opened a new ticket (#4646) since I wasn't able to reopen this

comment:7 follow-up: Changed 10 years ago by gagern

Get the same debug messages (unexpected length from omega...) on Gentoo with gnutls-2.6.3 and pidgin-2.5.4. In the Pidgin UI, it keeps connecting to MSN forever. Disabling and re-enabling the MSN account has some chance of resolving the issue, though I couldn't reproduce that aspect yet with the debug messages enabled.

comment:8 in reply to: ↑ 7 Changed 10 years ago by freezy

Replying to gagern:

Get the same debug messages (unexpected length from omega...) on Gentoo with gnutls-2.6.3 and pidgin-2.5.4. In the Pidgin UI, it keeps connecting to MSN forever. Disabling and re-enabling the MSN account has some chance of resolving the issue, though I couldn't reproduce that aspect yet with the debug messages enabled.

I am having the same issue as gagern on Debian with gnutls-2.4.2 and pidgin-2.5.4. Disabling and re-enabling the MSN account sometimes results in a successful connection, it seems somewhat random.

The failure:

(20:56:00) proxy: Attempting connection to 65.54.170.19
(20:56:00) proxy: Connecting to omega.contacts.msn.com:443.
(20:56:00) gnutls: Starting handshake with omega.contacts.msn.com
(20:56:00) gnutls: Handshake failed. Error A TLS packet with unexpected length was received.

Account disabled, re-enabled:

...
(20:55:58) soap: Received secure request.
(20:55:58) soap: Received secure request.
(20:56:52) soap: read 14115 bytes
(20:56:52) gnutls: receive failed: A TLS packet with unexpected length was received.
(20:56:52) soap: read: Input/output error
(20:56:52) soap: Received secure request.
...

(continues as if nothing went wrong)

...
(20:56:53) proxy: Attempting connection to 65.54.170.30
(20:56:53) proxy: Connecting to omega.contacts.msn.com:443.
(20:56:53) gnutls: Starting handshake with omega.contacts.msn.com
(20:56:53) gnutls: Handshake complete
(20:56:53) gnutls/x509: Key print: de:27:b1:dd:f7:16:d6:4e:46:4d:59:ca:02:ef:3a:9a:38:bc:a1:e0
(20:56:53) gnutls/x509: Key print: 7e:8a:c2:9c:5a:32:8c:c2:71:a2:d9:4f:75:70:f7:a9:1b:f6:94:05
(20:56:53) gnutls/x509: Key print: 3d:29:1d:b8:ee:22:be:e1:33:70:06:f2:ef:c6:f9:db:dd:03:bb:25
(20:56:53) gnutls: Peer provided 3 certs
...

Connection works as expected.

Note that the failure occurred when omega.contacts.msn.com resolved to 65.54.170.19, but not when it resolved to 65.54.170.30.

Possible temporary solution: append 'omega.contacts.msn.com 65.54.170.30' to the system hosts file, assuming 65.54.170.19 is the problem. It explains why disabling/re-enabling works with some chance. The domain seems to be assigned to several IPs, some of which may not be handling handshakes correctly.

comment:9 Changed 10 years ago by gagern

By compiling a modified version of GNUTLS to tack every instance of the GNUTLS_E_UNEXPECTED_PACKET_LENGTH error, I've got a backtrace for this:

#1  0xb75d2b21 in _gnutls_recv_int (session=0x9bf9700, type=GNUTLS_HANDSHAKE, 
    htype=GNUTLS_HANDSHAKE_SERVER_HELLO, data=0x9bfa0e8 "", sizeofdata=1) at gnutls_record.c:910
#2  0xb75d7bd6 in _gnutls_handshake_io_recv_int (session=0x9bf9700, type=GNUTLS_HANDSHAKE, 
    htype=GNUTLS_HANDSHAKE_SERVER_HELLO, iptr=0x9bfa0e8, sizeOfPtr=1) at gnutls_buffers.c:1123
#3  0xb75da2d0 in _gnutls_recv_handshake_header (session=0x9bf9700, type=GNUTLS_HANDSHAKE_SERVER_HELLO, 
    recv_type=0xbfbe58f0) at gnutls_handshake.c:1039
#4  0xb75da88c in _gnutls_recv_handshake (session=0x9bf9700, data=0x0, datalen=0x0, 
    type=GNUTLS_HANDSHAKE_SERVER_HELLO, optional=MANDATORY_PACKET) at gnutls_handshake.c:1196
#5  0xb75dcf68 in _gnutls_handshake_client (session=0x9bf9700) at gnutls_handshake.c:2341
#6  0xb75dcc18 in gnutls_handshake (session=0x9bf9700) at gnutls_handshake.c:2262
#7  0xb75077fc in ssl_gnutls_handshake_cb (data=0x9737430, source=18, cond=3) at ssl-gnutls.c:113
#8  0x080a50ab in pidgin_io_invoke (source=0x9b905b8, condition=<value optimized out>, data=0x9b8c440)
    at gtkeventloop.c:78
#9  0x482a510a in g_io_unix_dispatch (source=<value optimized out>, callback=<value optimized out>, 
    user_data=Could not find the frame base for "g_io_unix_dispatch".
) at giounix.c:162
#10 0x48271f04 in IA__g_main_context_dispatch (context=<value optimized out>) at gmain.c:2144
#11 0x482752c3 in g_main_context_iterate (context=<value optimized out>, block=<value optimized out>, 
    dispatch=<value optimized out>, self=Could not find the frame base for "g_main_context_iterate".
) at gmain.c:2778
#12 0x4827576c in IA__g_main_loop_run (loop=<value optimized out>) at gmain.c:2986
#13 0x426a7237 in IA__gtk_main () at gtkmain.c:1200
#14 0x080be1fe in main (argc=Cannot access memory at address 0xffffffca
) at gtkmain.c:884

Note when you try debugging this yourself that there is another situation where _gnutls_recv_int returns GNUTLS_E_UNEXPECTED_PACKET_LENGTH. In that case the call stack looks different, it includes msn_soap_read_cb and purple_ssl_read. This error seems to occur even for successful connections, and pidgin seems to recover well from it, so it's probably unrelated to this bug here.

I can also confirm a correspondence between error and IP, though for me 65.54.170.28 is the working one. The failing one is 65.54.170.19 as it is for freezy. Notice that in the comment:description by bsdunx it was 65.54.170.30 causing the failure, which seems to work now.

I even can confirm the issue with curl compiled against gnutls:

$ curl https://65.54.170.19/
curl: (35) gnutls_handshake() failed: A TLS packet with unexpected length was received.

So it might be some kind of general gnutls issue, not directly related to Pidgin. As we only know of that single server, though, where this error occurs, it might well be that few people would encounter this except those trying to use MSN through some allication employing gnutls.

comment:10 Changed 10 years ago by gagern

New insights gained using wireshark: 65.54.170.19 doesn't like TLS 1.1. When confronted with a TLS 1.1 client hello, it immediately terminates the TCP connection.

You can use gnutls-cli-debug to have a look at the features and protocols the host supports. You will notice that fallback from TLS 1.1 to 1.0 seems to be broken:

$ gnutls-cli-debug -p 443 65.54.170.19
Resolving '65.54.170.19'...
Connecting to '65.54.170.19:443'...
Checking for TLS 1.1 support... no
Checking fallback from TLS 1.1 to... failed
Checking for TLS 1.0 support... yes
Checking for SSL 3.0 support... yes
Checking for HTTPS server name... not checked
Checking for version rollback bug in RSA PMS... no
Checking for version rollback bug in Client Hello... yes
Checking whether we need to disable TLS 1.0... N/A
Checking whether the server ignores the RSA PMS version... yes
Checking whether the server can accept Hello Extensions... yes
Checking whether the server can accept cipher suites not in SSL 3.0 spec... yes
Checking whether the server can accept a bogus TLS record version in the client hello... no
Checking for certificate information... N/A
Checking for trusted CAs... N/A
Checking whether the server understands TLS closure alerts... partially
Checking whether the server supports session resumption... yes
Checking for export-grade ciphersuite support... yes
Checking RSA-export ciphersuite info... N/A
Checking for anonymous authentication support... no
Checking anonymous Diffie Hellman group info... N/A
Checking for ephemeral Diffie Hellman support... yes
Checking ephemeral Diffie Hellman group info... N/A
Checking for AES cipher support (TLS extension)... yes
Checking for CAMELLIA cipher support (TLS extension)... no
Checking for 3DES cipher support... no
Checking for ARCFOUR 128 cipher support... yes
Checking for ARCFOUR 40 cipher support... yes
Checking for MD5 MAC support... yes
Checking for SHA1 MAC support... yes
Checking for ZLIB compression support (TLS extension)... no
Checking for LZO compression support (GnuTLS extension)... no
Checking for max record size (TLS extension)... no
Checking for SRP authentication support (TLS extension)... yes
Checking for OpenPGP authentication support (TLS extension)... no

You can then simulate the way pisgin probably connects:

$ gnutls-cli -p 443 65.54.170.19
Resolving '65.54.170.19'...
Connecting to '65.54.170.19:443'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.

By restricting the protocol to TLS version 1.0 and thus disallowing 1.1, you can get a successful handshake:

$ gnutls-cli --protocols TLS1.0 -p 443 65.54.170.19
This method of specifying algorithms is deprecated. Please use the --priority option.
Resolving '65.54.170.19'...
Connecting to '65.54.170.19:443'...
- Certificate type: X.509
 - Got a certificate list of 3 certificates.

 - Certificate[0] info:
 # The hostname in the certificate does NOT match '65.54.170.19'.

So there now are several possible solutions to this whole mess:

  1. Bug MS to install a proper TLS implementation on 65.54.170.19
  2. Disable TLS 1.1 for this connection for the time being
  3. Try 1.1 but fall back to TLS 1.0 in pidgin code whenever this issue turns up

I've got the feeling that the last option might make the most sense. Haven't yet looked at the GnuTLS API to figure out how to achieve this protocol restriction.

comment:11 Changed 10 years ago by gagern

The kind of workaround I just suggested would require quite a lot of modifications to the purple code. From what I can tell, the msn soap code is responsible for the connection to MSN_CONTACT_SERVER. These steps might get us there:

  1. msn_soap_connection_run in soap.c is where the connection is established initially. It should probably remain TLS 1.1 there.
  2. msn_soap_error_cb in soap.c would be the place to recognize the PURPLE_SSL_HANDSHAKE_FAILED error and try to fall back in response to this.
  3. struct _PurpleSslConnection in sslconn.h would have to have some field to store additional information. I'd probably introduce an int bitfield "flags" and define a flag "PURPLE_SSL_FLAG_NO_TLS10" or similar for this purpose. This flag could be set by the soap code for the second run.
  4. ssl_gnutls_connect in ssl-gnutls.c is where the session is set up. A call to gnutls_protocol_set_priority there could be used to restrict protocols to GNUTLS_SSL3 and GNUTLS_TLS1_0 if the corresponding flag in gsc is set.

On the whole this is more coding than I can afford the time to implement this myself just now. But perhaps my considerations might be useful, either as a basis for discussing alternatives in addressing this issue, or as a guideline for someone willing to implement it.

BTW: Can we please have this bug report reopened?

comment:12 Changed 10 years ago by deryni

  • Resolution invalid deleted
  • Status changed from closed to new

comment:13 Changed 10 years ago by khc

Ticket #4646 has been marked as a duplicate of this ticket.

comment:14 follow-up: Changed 10 years ago by freezy

I'm not familiar with the Pidgin source, but rather than catching the failure and retrying, could we do what gnutls-cli-debug does and check what protocols a server supports before connecting? If TLS 1.1 is not supported and TLS 1.0 is, force TLS 1.0 for the connection.

comment:15 in reply to: ↑ 14 Changed 10 years ago by gagern

Replying to freezy:

rather than catching the failure and retrying, could we do what gnutls-cli-debug does and check what protocols a server supports before connecting?

The way gnutls-cli-debug works is this:

  1. Try to connect with TLS 1.1 only. If it works, skip all fallback tests.
  2. Try to connect with TLS 1.1, see if it succeeds, report version chosen by server

In both cases, the connection is closed again after the test.

The bottom line is this: you can't check what version the server supports without trying to. And if you try and succeed, you have a connection and it would be wasteful to close it just so you can reconnect again with that same version.

There also wouldn't be much to be gained in terms of code simplicity, I guess. What makes gnutls-cli-debug as simple as it is is the fact that it can afford to block on I/O, so it can use loops and keep information in local variables. Pidgin, on the other hand, has to stay responsive while establishing a connection in the background. Therefore everything has to be done through callbacks triggered when data becomes available on the underlying tcp socket. This restriction would hold for a check for supported version as well, so you can't simply have a function "supports_TLS11" or similar returning bool, as such a function must not block.

BTW: The flag in comment:11 should be PURPLE_SSL_FLAG_NO_TLS11 of course, not 10.

comment:16 follow-up: Changed 10 years ago by khc

I think we should let gnutls developers know about this, because this quite possibly is a legitimate gnutls bug. nss seems to work fine as far as I know, and distros tend to ship with compiled packages that use nss. I wouldn't mind to have msn require nss and/or some gnutls version that actually works.

comment:17 in reply to: ↑ 16 ; follow-up: Changed 10 years ago by gagern

Replying to khc:

I think we should let gnutls developers know about this, because this quite possibly is a legitimate gnutls bug. nss seems to work fine as far as I know, and distros tend to ship with compiled packages that use nss. I wouldn't mind to have msn require nss and/or some gnutls version that actually works.

From what wiresharking a firefox connection tells me, nss only uses TLS 1.0 and doesn't even try TLS 1.1. The NSS overview doesn't even mention the TLS 1.1 RFC 4346, nor the TLS 1.2 RFC 5246.

Using TLS in preference to TLS 1.0 is not a bug, as RFC 4346 section 1.1 mentions several security relevant improvements from TLS 1.0 to TLS 1.1. Always sending version 1.1 in the client hello is not a bug, as RFC 2246 section 7.4.1.2 states that the client should indicate the highest protocol version it can handle. It is up to the server to give a lower protocol version in its reply hello, which will then be used for the communication. The server closing the connection instead is simply a bug there.

If you want to have the nss behaviour, you can simply choose to indiscrimately disable TLS 1.1 and higher for each and every connection established with gnutls. A simple call to gnutls_protocol_set_priority in ssl_gnutls_connect would do the trick. The danger is that this configuration option would be likely to stay in place unrevised for a really long time, making pidgin use outdated and insecure protocols for all connections far into the future, just because some MSN server right now is buggy.

So if you can think of a way to actually enforce revisiting this bug here say every year or so, and to check whether the restriction to TLS <1.1 is still required, then this might be a viable workaround for now. If not, I'm not a pidgin developer so I can't forbid this approach, but I would vote against it.

On the whole, I see no gnutls bug here at all. You might wish to have workarounds for buggs TLS servers as a feature, but I'm not sure if gnutls would be the place for this, especially as you can't transparently implement this client-side fallback in the current API, since you need to re-establish the connection over a new TCP socket.

comment:18 Changed 10 years ago by gagern

The patch I just attached is something of a middle road. It limits MSN soap connections to SSL 3 or TLS 1.0. Connections using TLS 1.1 are not even tried, which avoids much of the machinery that would be needed for bug detection and fallback. On the other hand, the version limit only applies to MSN, therefore other protocols with proper server implementations won't suffer. Verbose comments in multiple suitable places indicate the workaround as such and suggest its reevaluation.

As the API of libpurple changes, it might that all this will have to wait until 2.6.0. On the other hand, the implementation of purple_ssl_connect stays compatible, and instances of PurpleSslConnection? should only ever be passed around as pointers, so a change in its size should not matter. If you decide to include this in 2.5.x, please change the @since comments accordingly.

By the way, I've tested the patch. Got a successful TLS 1.0 connection to 65.54.170.19. Prooves my point that a successful connection using GnuTLS is possible.

comment:19 Changed 10 years ago by khc

Ticket #8407 has been marked as a duplicate of this ticket.

comment:20 in reply to: ↑ 17 ; follow-up: Changed 10 years ago by darkrain42

Replying to gagern:

Using TLS in preference to TLS 1.0 is not a bug, as RFC 4346 section 1.1 mentions several security relevant improvements from TLS 1.0 to TLS 1.1. Always sending version 1.1 in the client hello is not a bug, as RFC 2246 section 7.4.1.2 states that the client should indicate the highest protocol version it can handle. It is up to the server to give a lower protocol version in its reply hello, which will then be used for the communication. The server closing the connection instead is simply a bug there.

In reading RFC4346 (tls 1.1) Appendix E and examining wireshark, I noticed something. The Client Hello contains two version fields; one in the SSL Record Layer and one in the Client Hello. For tls1.1, both are set to TLS 1.1 (0x0302), but Appendix E indicates that, for backward-compatibility, the record layer SHOULD be version SSL3.0 (0x0300, I assume) (and the Client Hello version 1.1). My reading is that doing this is the appropriate way to support >=SSL3.0 (since Microsoft's server doesn't understand TLS1.1).

I may be reading that wrong and I also am not sure that gnutls allows what I just described, but I'm going to take a closer look and possibly add another test to the cli debug app and test setting the record layer to 0x0300 and 0x0301.

If you want to have the nss behaviour, you can simply choose to indiscrimately disable TLS 1.1 and higher for each and every connection established with gnutls. A simple call to gnutls_protocol_set_priority in ssl_gnutls_connect would do the trick. The danger is that this configuration option would be likely to stay in place unrevised for a really long time, making pidgin use outdated and insecure protocols for all connections far into the future, just because some MSN server right now is buggy.

So if you can think of a way to actually enforce revisiting this bug here say every year or so, and to check whether the restriction to TLS <1.1 is still required, then this might be a viable workaround for now. If not, I'm not a pidgin developer so I can't forbid this approach, but I would vote against it.

I wholeheartedly think this is a very Bad Idea (the reasons you outlined plus the possibility of discoveries of further exploits in TLS 1.0). Your other suggestion (limiting just MSN soap connections) is better.

comment:21 in reply to: ↑ 20 Changed 10 years ago by gagern

Replying to darkrain42:

In reading RFC4346 (tls 1.1) Appendix E and examining wireshark, I noticed something. The Client Hello contains two version fields; one in the SSL Record Layer and one in the Client Hello. For tls1.1, both are set to TLS 1.1 (0x0302), but Appendix E indicates that, for backward-compatibility, the record layer SHOULD be version SSL3.0 (0x0300, I assume) (and the Client Hello version 1.1). My reading is that doing this is the appropriate way to support >=SSL3.0 (since Microsoft's server doesn't understand TLS1.1).

I may be reading that wrong and I also am not sure that gnutls allows what I just described, but I'm going to take a closer look and possibly add another test to the cli debug app and test setting the record layer to 0x0300 and 0x0301.

You are right. I just exported the packet from wireshark, changed the record version to 0x0300, and sent it to the server through netcat. The server kept the connection and responded with an appropriate server hello, establishing SSL 3.0 as the common version to use (which is still strange, as it negotiates a TLS 1.0 connection when talked to using the TLS 1.0 record protocol).

So now we indeed have what looks like a GnuTLS bug. I stand corrected, and acknowledge that this seems to be not (only) the MS server's fault, but a GnuTLS thing after all. darkrain42, will you forward this finding to the GnuTLS guys?

comment:22 follow-up: Changed 10 years ago by darkrain42

Follow-up: I recompiled gnutls and re-ran the gnutls-cli-debug tests while setting the record version to 0x0300 and 0x0301. Both tests passed; when using an SSL 3.0 record, the server negotiates SSL3.0, and when using an TLS 1.0 record, the server negotiates TLS1.0 (That's a server bug; the server should negotiate TLS1.0 in both cases AIUI).

I'm not sure if this is actually a gnutls bug or not, and I don't know if it makes sense to set the record version to 3.1 (at least for these connections). I'm not a TLS guru, so I don't know if this is just as bad an idea as disabling TLS >= 1.1 purple-wide would be. Also, the symbol to set the record type is exported, but isn't in a header file (and has a big "only use this if you know what you're doing" warning next to the code for it)

void _gnutls_record_set_default_version (gnutls_session_t session,
                     unsigned char major,
                     unsigned char minor);

comment:23 in reply to: ↑ 22 Changed 10 years ago by gagern

Replying to darkrain42: I've asked on the help-gnutls mailing list about this. See the Gmane thread for any replies.

comment:24 Changed 10 years ago by gagern

Nikos Mavrogiannopoulos from GnuTLS wrote that he committed a change to address this issue. It introduces a priority string "%SSL3_RECORD_VERSION" which will force an SSL 3 record version header.

I'm currently testing a patch to make use of this new feature, with a fallback to disabling TLS 1.1 if the feature isn't available, and will attach the patch here once I'm happy with it.

Changed 10 years ago by gagern

%SSL3_RECORD_VERSION for MSN soap, fallback to TLS <=1.0

Changed 10 years ago by gagern

%SSL3_RECORD_VERSION for all GnuTLS connections

comment:25 Changed 10 years ago by gagern

OK, attachment:bug3456a.patch solves the MSN issue, no matter what version of GnuTLS the user has installed. It does so by trying to use the new %SSL3_RECORD_VERSION feature, and if that fails, by disabling TLS 1.1 and above. As future versions of GnuTLS will support %SSL3_RECORD_VERSION and as future server implementations should use the hello messages to negotiate a common protocol version, there shouldn't be any harm in having this patch in place even in the far future.

attachment:bug3456b.patch addresses this whole issue with very little modifications to the code. It tries to enable the %SSL3_RECORD_VERSION flag for all GnuTLS connections, not only the MSN ones, and falls back to current behaviour if that fails. This means that in order to avoid this bug here, users not only have to update pidgin, but also their GnuTLS. It also means that all other protocols will use SSL 3.0 records as well. While all TLS servers should accept such connections, there is no guarantee that they actually do, so there is a chance that this patch will break other protocols. On the upside, this patch doesn't introduce any new functions into the purple API.

I would vote to include the first patch as soon as your policy allows.

comment:26 follow-up: Changed 10 years ago by khc

For the latter, is that what nss does (and which is why it seems to work better at least in this case)? I'd rather really prefer that our ssl plugins abstract out the backend differences instead of having a flag that's useful only in some cases.

I am going to checkin the second patch, other developers who are more well versed in ssl than I am feel free to decide otherwise.

comment:27 Changed 10 years ago by khc@…

  • Milestone set to 2.5.5
  • Resolution set to fixed
  • Status changed from new to closed

(In c84a41f40179331c218ac05005ce7805129049e5):
patch from Martin von Gagern that uses a new gnutls option to enable better compatibility with a msn contact server

Fixes #3456

comment:28 in reply to: ↑ 26 Changed 10 years ago by gagern

Replying to khc:

For the latter, is that what nss does (and which is why it seems to work better at least in this case)?

Don't think so. As mentioned in comment:17, NSS doesn't support TLS 1.1 at all, so even if it sends its highest supported record version, 1.0, that will be accepted by the server. Once NSS does support TLS 1.1 we will have to see what its default behaviour is then, and whether we need workarounds for specific hosts there as well.

I'd rather really prefer that our ssl plugins abstract out the backend differences instead of having a flag that's useful only in some cases.

Problem is that hosts might be broken in both directions, which is the reason for the GnuTLS default behaviour in the first place. If we have to deal with both kinds of broken servers, we need some kind of flag to determine what workaround we use, or a rather elaborate automatic fallback mechanism.

I am going to checkin the second patch, other developers who are more well versed in ssl than I am feel free to decide otherwise.

I'd say test that, see if it works. If any problems turn up in other protocols, where the SSL 3.0 record version causes trouble, revert that patch and apply the other instead.

comment:29 Changed 10 years ago by khc

Yes, if this patch causes troubles I will definitely go the other route instead, not like there's another option ;-)

I really appreciate your help in tracking down this issue.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!