GnuTLS "Error in the pull function" : cannot establish connection with VPN server

Discussion:

Pawel Stankowski

2016-01-15 16:15:35 UTC

Hello open-connect developers,

I experience some unexpected behavior after some time in Ubuntu 15.04.
Upgrade to Ubuntu 15.10 did not help.

Thing is that openconnect stopped establishing connection with my
company's VPN, possibly after some change on server side or after
security upgrade of some package in my ubuntu, not sure.

Here is the output I got (after upgrade to Ubuntu 15.10):
# openconnect --version
OpenConnect version v7.06
Using GnuTLS. Features present: PKCS#11, RSA software token, HOTP
software token, TOTP software token, DTLS
***@past-ubuntu:~$
# openconnect -v <VPN IP>
POST https://<VPN IP>
Attempting to connect to server XX.XX.XX.XXX:443
SSL negotiation with <VPN IP>
SSL connection failure: Error in the pull function.
Failed to open HTTPS connection to <VPN IP>
Failed to obtain WebVPN cookie

Seems that the problem is related to pull function used by GNU TLS
library. I built the newest master version from source code and had the
same error.

Then I switched from GnuTLS to OpenSSL by writing:
../configure --with-vpnc-script="/usr/share/vpnc-scripts/vpnc-script"
-without-gnutls --with-openssl=yes

... and I successfully connected to the same VPN using v6.00 tag. I
couldn't compile master using the same configuration flags, seems that
OpenSSL is no longer supported as the only SSL library...

Could you help me to determine what is wrong with Ubuntu packages, that
they do not work properly on my PC?

--

Best regards / Pozdrawiam

Paweł Stankowski

E-mail: ***@fara.no

Nikos Mavrogiannopoulos

2016-01-16 17:22:15 UTC

Permalink

Post by Pawel Stankowski
Hello open-connect developers,

[...]

Post by Pawel Stankowski
# openconnect --version
OpenConnect version v7.06
Using GnuTLS. Features present: PKCS#11, RSA software token, HOTP
software token, TOTP software token, DTLS
# openconnect -v <VPN IP>
POST https://<VPN IP>
Attempting to connect to server XX.XX.XX.XXX:443
SSL negotiation with <VPN IP>
SSL connection failure: Error in the pull function.

This is most likely a networking error. You can check the connection
status with wireshark, and/or set GNUTLS_DEBUG_LEVEL=6 for more
information.

regards,
Nikos

Pawel Stankowski

2016-01-18 12:11:00 UTC

Permalink

Post by Nikos Mavrogiannopoulos

Post by Pawel Stankowski
Hello open-connect developers,

[...]

This is most likely a networking error. You can check the connection
status with wireshark, and/or set GNUTLS_DEBUG_LEVEL=6 for more
information.

Seems that there is some incompatibility between GnuTLS and this VPN
server. I reproduced the same problem on Debian 8 "Jessie". The same
server works fine with both AnyConnect and openconnect compiled without
GnuTLS. I get known that the server I connect to is some Cisco ASA
Firewall.

I set GNUTLS_DEBUG_LEVEL to 99 and here is the output from openconnect:
gnutls[2]: Enabled GnuTLS logging...
gnutls[2]: Intel SSSE3 was detected
gnutls[2]: Intel AES accelerator was detected
gnutls[2]: Intel GCM accelerator was detected
POST ...
Attempting to connect to server ...
gnutls[3]: ASSERT: ...
...
gnutls[5]: REC[0x559752908e70]: Allocating epoch #0
SSL negotiation with ...
gnutls[3]: ASSERT: gnutls_constate.c:586
gnutls[5]: REC[0x559752908e70]: Allocating epoch #1
gnutls[4]: HSK[0x559752908e70]: Keeping ciphersuite: ...
...
gnutls[4]: EXT[0x559752908e70]: Sending extension STATUS REQUEST (5
bytes)
gnutls[4]: EXT[0x559752908e70]: Sending extension SERVER NAME (21
bytes)
gnutls[4]: EXT[0x559752908e70]: Sending extension SAFE RENEGOTIATION (1
bytes)
gnutls[4]: EXT[0x559752908e70]: Sending extension SESSION TICKET (0
bytes)
gnutls[4]: EXT[0x559752908e70]: Sending extension SUPPORTED ECC (12
bytes)
gnutls[4]: EXT[0x559752908e70]: Sending extension SUPPORTED ECC POINT
FORMATS (2 bytes)
gnutls[4]: EXT[0x559752908e70]: sent signature algo (4.1) RSA-SHA256
gnutls[4]: EXT[0x559752908e70]: sent signature algo (4.2) DSA-SHA256
gnutls[4]: EXT[0x559752908e70]: sent signature algo (4.3) ECDSA-SHA256
gnutls[4]: EXT[0x559752908e70]: sent signature algo (5.1) RSA-SHA384
gnutls[4]: EXT[0x559752908e70]: sent signature algo (5.3) ECDSA-SHA384
gnutls[4]: EXT[0x559752908e70]: sent signature algo (6.1) RSA-SHA512
gnutls[4]: EXT[0x559752908e70]: sent signature algo (6.3) ECDSA-SHA512
gnutls[4]: EXT[0x559752908e70]: sent signature algo (3.1) RSA-SHA224
gnutls[4]: EXT[0x559752908e70]: sent signature algo (3.2) DSA-SHA224
gnutls[4]: EXT[0x559752908e70]: sent signature algo (3.3) ECDSA-SHA224
gnutls[4]: EXT[0x559752908e70]: sent signature algo (2.1) RSA-SHA1
gnutls[4]: EXT[0x559752908e70]: sent signature algo (2.2) DSA-SHA1
gnutls[4]: EXT[0x559752908e70]: sent signature algo (2.3) ECDSA-SHA1
gnutls[4]: EXT[0x559752908e70]: Sending extension SIGNATURE ALGORITHMS
(28 bytes)
gnutls[4]: EXT[0x559752908e70]: Sending extension DUMBFW (240 bytes)
gnutls[4]: HSK[0x559752908e70]: CLIENT HELLO was queued [518 bytes]
gnutls[11]: HWRITE: enqueued [CLIENT HELLO] 518. Total 518 bytes.
gnutls[11]: HWRITE FLUSH: 518 bytes in buffer.
gnutls[5]: REC[0x559752908e70]: Preparing Packet Handshake(22) with
length: 518 and min pad: 0
gnutls[9]: ENC[0x559752908e70]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
gnutls[11]: WRITE: enqueued 523 bytes for 0x6. Total 523 bytes.
gnutls[5]: REC[0x559752908e70]: Sent Packet[1] Handshake(22) in epoch 0
and length: 523
gnutls[11]: HWRITE: wrote 1 bytes, 0 bytes left.
gnutls[11]: WRITE FLUSH: 523 bytes in buffer.
gnutls[11]: WRITE: wrote 523 bytes, 0 bytes left.
gnutls[3]: ASSERT: gnutls_buffers.c:1138
gnutls[10]: READ: -1 returned from 0x6, errno=104 gerrno=0
gnutls[3]: ASSERT: gnutls_buffers.c:364
gnutls[3]: ASSERT: gnutls_buffers.c:572
gnutls[3]: ASSERT: gnutls_record.c:1058
gnutls[3]: ASSERT: gnutls_record.c:1179
gnutls[3]: ASSERT: gnutls_buffers.c:1392
gnutls[3]: ASSERT: gnutls_handshake.c:1428
gnutls[3]: ASSERT: gnutls_handshake.c:2719
SSL connection failure: Error in the pull function.
gnutls[5]: REC[0x559752908e70]: Start of epoch cleanup
gnutls[5]: REC[0x559752908e70]: End of epoch cleanup
gnutls[5]: REC[0x559752908e70]: Epoch #0 freed
gnutls[5]: REC[0x559752908e70]: Epoch #1 freed
Failed to open HTTPS connection to ...
Failed to obtain WebVPN cookie
GnuTLS error: Error in the pull function.

And here is the output from "GNUTLS_DEBUG_LEVEL=99 gnutls-cli <server>"
gnutls[2]: Enabled GnuTLS logging...
gnutls[2]: Intel SSSE3 was detected
gnutls[2]: Intel AES accelerator was detected
gnutls[2]: Intel GCM accelerator was detected
Processed 187 CA certificate(s).
Resolving '<server>'...
Connecting to '<server_ip>:443'...
*** Fatal error: Error in the pull function.
*** Handshake has failed
GnuTLS error: Error in the pull function.

In Wireshark the latter command results in following output:
TCP 42272→443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1
TSval=441903 TSecr=0 WS=128
TCP 443→42272 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1380
TSval=2475714439 TSecr=441903
TCP 42272→443 [ACK] Seq=1 Ack=1 Win=29200 Len=0 TSval=441916
TSecr=2475714439
SSL Length=345 Client Hello
TCP 443→42272 [ACK] Seq=1 Ack=280 Win=32768 Len=0
TSval=2475714493 TSecr=441917
TCP 443→42272 [RST] Seq=1 Win=32768 Len=0 TSval=2475714494
TSecr=0

I also checked the output of wireshark, when openconnect is compiled
with OpenSSL. It uses TLSv1 instead of SSL.

BTW: I checked what is wrong with "--with-openssl --without-gnutls"
compilation in master. It was commit c00609ad that broke the
compilation. Here is the patch fixing the problem:

diff --git a/dtls.c b/dtls.c
index 7dc6ba9..81ca7bf 100644
--- a/dtls.c
+++ b/dtls.c
@@ -1098,6 +1098,8 @@ void ms_sleep(unsigned ms)
nanosleep(&tv, NULL);
}

+#if defined(DTLS_GNUTLS)
+
#define MTU_ID_SIZE 4
#define MTU_FAIL_CONT { \
cur--; \
@@ -1330,6 +1332,7 @@ static void detect_mtu(struct openconnect_info
*vpninfo)
gnutls_record_set_timeout(vpninfo->dtls_ssl, 0);
free(buf);
}
+#endif

#else /* !HAVE_DTLS */
#warning Your SSL library does not seem to support Cisco DTLS
compatibility

Regards,
Paweł Stankowski

Nikos Mavrogiannopoulos

2016-01-19 08:07:01 UTC

Permalink

On Mon, Jan 18, 2016 at 1:11 PM, Pawel Stankowski

Post by Pawel Stankowski

Post by Nikos Mavrogiannopoulos

This is most likely a networking error. You can check the connection
status with wireshark, and/or set GNUTLS_DEBUG_LEVEL=6 for more
information.

Which version of gnutls is that? Could you try running
gnutls-cli-debug on that server?

Pawel Stankowski

2016-01-19 11:06:25 UTC

Permalink

Post by Nikos Mavrogiannopoulos
On Mon, Jan 18, 2016 at 1:11 PM, Pawel Stankowski

Post by Pawel Stankowski

Post by Nikos Mavrogiannopoulos

This is most likely a networking error. You can check the
connection
status with wireshark, and/or set GNUTLS_DEBUG_LEVEL=6 for more
information.

Which version of gnutls is that? Could you try running
gnutls-cli-debug on that server?

GnuTLS debug client 3.3.15
Checking <...>:443
for SSL 3.0 (RFC6101) support... no
whether we need to disable TLS 1.2... yes
whether we need to disable TLS 1.1... yes
whether we need to disable TLS 1.0... no
whether %NO_EXTENSIONS is required... no
whether %COMPAT is required... no
for TLS 1.0 (RFC2246) support... yes
for TLS 1.1 (RFC4346) support... no
fallback from TLS 1.1 to... failed
for TLS 1.2 (RFC5246) support... no
for HTTPS server name... unknown
for certificate chain order... sorted
for safe renegotiation (RFC5746) support... yes
for heartbeat (RFC6520) support... no
for version rollback bug in RSA PMS... no
for version rollback bug in Client Hello... no
whether the server ignores the RSA PMS version... yes
whether small records (512 bytes) are accepted... yes
whether cipher suites not in SSL 3.0 spec are accepted... yes
whether a bogus TLS record version in the client hello is accepted...
yes
whether the server understands TLS closure alerts... partially
whether the server supports session resumption... yes
for anonymous authentication support... no
for ephemeral Diffie-Hellman support... no
for ephemeral EC Diffie-Hellman support... no
for AES-128-GCM cipher (RFC5288) support... no
for AES-128-CBC cipher (RFC3268) support... yes
for CAMELLIA-128-GCM cipher (RFC6367) support... no
for CAMELLIA-128-CBC cipher (RFC5932) support... no
for 3DES-CBC cipher (RFC2246) support... yes
for ARCFOUR 128 cipher (RFC2246) support... yes
for MD5 MAC support... no
for SHA1 MAC support... yes
for SHA256 MAC support... no
for ZLIB compression support... no
for max record size (RFC6066) support... no
for OCSP status response (RFC6066) support... no
for OpenPGP authentication (RFC6091) support... no

Regards,
Paweł Stankowski

Nikos Mavrogiannopoulos

2016-01-19 11:52:33 UTC

Permalink

On Tue, Jan 19, 2016 at 12:06 PM, Pawel Stankowski

Post by Pawel Stankowski
GnuTLS debug client 3.3.15
Checking <...>:443
for SSL 3.0 (RFC6101) support... no
whether we need to disable TLS 1.2... yes
whether we need to disable TLS 1.1... yes

This looks like a broken server which fails if the client advertises
anything more than TLS 1.0. Are you sure that's a cisco server and
there is no a box in the middle? Could you send me the IP of the
server?

regards,
Nikos