Connecting to Pulse Secure results in SSL

[Brandon Liles]

I've found a few others reporting this problem, but no resolution. When
connecting to a pulse secure endpoint, authentication is successful (I
can see the DSID cookie in the http traffic), but when openconnect
tries to establish the VPN connection I get:

Read 3 bytes of SSL record
< 0000: 01 00 08
Server response to hostname packet is error 0x08
Creating SSL connection failed

I initially tried 7.08 from the Ubuntu 18.04 repositories. When that
didn't work I compiled from source so I have:
openconnect --version
OpenConnect version v7.08-125-g31b5c4a
Using OpenSSL. Features present: TPM (OpenSSL ENGINE not present), HOTP
software token, TOTP software token, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp

I've tried configuring the host checker software and altering my os
param, but always get the same error.

Any help would be greatly appreciated.

[Daniel Lenski]

Post by Brandon Liles
I've found a few others reporting this problem, but no resolution. When
connecting to a pulse secure endpoint, authentication is successful (I
can see the DSID cookie in the http traffic), but when openconnect
Read 3 bytes of SSL record
< 0000: 01 00 08
Server response to hostname packet is error 0x08
Creating SSL connection failed
I initially tried 7.08 from the Ubuntu 18.04 repositories. When that
openconnect --version
OpenConnect version v7.08-125-g31b5c4a
Using OpenSSL. Features present: TPM (OpenSSL ENGINE not present), HOTP
software token, TOTP software token, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp

You get the exact same result with both v7.08 and v7.08-125-g31b5c4a?
(The newer build includes some patches I submitted which makes the
Juniper connection a little more resilient in some cases.)

There was another very similar report recently:
http://lists.infradead.org/pipermail/openconnect-devel/2018-July/004954.html

Post by Brandon Liles
I've tried configuring the host checker software and altering my os
param, but always get the same error.

If you're getting past the authentication and you're getting the DSID
cookie, I don't think the OS or host checker have anything to do with
this result.

It appears that some Juniper servers don't respond in the same way to
the "vestigial authentication packet" as most of them, but we don't
understand what's different about them. (At least, I don't.)

In order to figure out what's different about this server, can you
extract the DSID cookie, and run openconnect as follows (highest
logging level), and share as much as possible of the resulting log
output? Obfuscate passwords, and usernames/hostnames/IPs if you want.

openconnect --dump-http-traffic -vvvv --protocol=nc
--cookie="DSID=...." SERVER

-Dan

[Brandon Liles]

Thanks very much for taking the time to look into this.

Yes, I get the exact same result with 7.08 and with v7.08-125-
g31b5c4a.

Here is the output you requested:

Attempting to connect to server xxx.xxx.xxx.xxx:443
Connected to xxx.xxx.xxx.xxx:443
Using certificate file /home/***********
Using client certificate '/CN=********'
SSL negotiation with ***
Matched peer certificate subject name '***'
Connected to HTTPS on ***
Got HTTP response: HTTP/1.1 200 OK
Content-type: application/octet-stream
Pragma: no-cache
NCP-Version: 3
Set-Cookie: DSLastAccess=1535592203; path=/; Secure
Connection: close
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000

0000: 16 00 00 04 00 00 00 09 00 62 6c 69 6c 65 73 2d
0010: 6c 78 bb 01 00 00 00 00

Read 3 bytes of SSL record
< 0000: 01 00 08
Server response to hostname packet is error 0x08
Creating SSL connection failed

Please let me know if there's something else I can do to help you
troubleshoot.

I've found a few others reporting this problem, but no resolution. When
connecting to a pulse secure endpoint, authentication is successful (I
can see the DSID cookie in the http traffic), but when openconnect
Read 3 bytes of SSL record
< 0000: 01 00 08
Server response to hostname packet is error 0x08
Creating SSL connection failed
I initially tried 7.08 from the Ubuntu 18.04 repositories. When that
openconnect --version
OpenConnect version v7.08-125-g31b5c4a
Using OpenSSL. Features present: TPM (OpenSSL ENGINE not present), HOTP
software token, TOTP software token, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp
You get the exact same result with both v7.08 and v7.08-125-g31b5c4a?
(The newer build includes some patches I submitted which makes the
Juniper connection a little more resilient in some cases.)
http://lists.infradead.org/pipermail/openconnect-devel/2018-July/0049
54.html
I've tried configuring the host checker software and altering my os
param, but always get the same error.
If you're getting past the authentication and you're getting the DSID
cookie, I don't think the OS or host checker have anything to do with
this result.
It appears that some Juniper servers don't respond in the same way to
the "vestigial authentication packet" as most of them, but we don't
understand what's different about them. (At least, I don't.)
In order to figure out what's different about this server, can you
extract the DSID cookie, and run openconnect as follows (highest
logging level), and share as much as possible of the resulting log
output? Obfuscate passwords, and usernames/hostnames/IPs if you want.
openconnect --dump-http-traffic -vvvv --protocol=nc
--cookie="DSID=...." SERVER
-Dan

[Daniel Lenski]

Post by Brandon Liles
Thanks very much for taking the time to look into this.
Yes, I get the exact same result with 7.08 and with v7.08-125-
g31b5c4a.
Attempting to connect to server xxx.xxx.xxx.xxx:443
Connected to xxx.xxx.xxx.xxx:443
Using certificate file /home/***********
Using client certificate '/CN=********'
SSL negotiation with ***
Matched peer certificate subject name '***'
Connected to HTTPS on ***
Got HTTP response: HTTP/1.1 200 OK
Content-type: application/octet-stream
Pragma: no-cache
NCP-Version: 3
Set-Cookie: DSLastAccess=1535592203; path=/; Secure
Connection: close
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000

0000: 16 00 00 04 00 00 00 09 00 62 6c 69 6c 65 73 2d
0010: 6c 78 bb 01 00 00 00 00

Read 3 bytes of SSL record
< 0000: 01 00 08
Server response to hostname packet is error 0x08
Creating SSL connection failed
Please let me know if there's something else I can do to help you
troubleshoot.

Thanks. I noticed the local hostname specified in your auth packet contains
a '-', which I thought might conceivably confuse some buggy server. But
I tried specifying hostnames with '-' on two different Juniper VPNs, and
both accepted it. So that's not it.

More thing to try:

1) You may want to try varying the local hostname (e.g.
`--local-hostname localhost` or
`--local-hostname NAME_OF_A_COMPUTER_THAT_WORKS_WITH_THE_OFFICIAL_CLIENT`)

2) Try removing the local hostname entirely (e.g.
`--local-hostname ""`). Do you get "error 0x05" instead?

Post by Brandon Liles
0000: 0d 00 00 04 00 00 00 00 00 bb 01 00 00 00 00

Read 3 bytes of SSL record
< 0000: 01 00 05
Server response to hostname packet is error 0x05

3) I notice that your connection requires a client certificate. VPN
servers have many quirky and buggy behaviors when client
certificates are involved. Try this: specify the client certificate
for authentication (to get the DSID), but omit it when trying to
actually connect.

In other words, first get the DSID as you've been doing, and then…

# LEAVE OFF THE CLIENT CERT!
openconnect -C 'DSID=...' vpn.company.com

Does that give the same result?

Assuming #1 and #3 don't change anything, and #2 gives you error 0x05
instead, MITM'ing and capturing traffic from a working official client
would probably be the only next step.

Dan

ps- I found another report of the same error 0x08:
http://lists.infradead.org/pipermail/openconnect-devel/2015-March/002820.html

pps- Here's some evidence that Juniper does strange things with client
certificates, although this one is from the authentication part and
*not* from the connection-initiation part:
http://lists.infradead.org/pipermail/openconnect-devel/2015-April/002899.html

[Brandon Liles]

Thanks! Here are the results.

1. I tried the hostname of a machine that is able to connect (which
incidentally has a dash in it also), I tried "localhost", still error
0x08.

2. Yes I get error 0x05 when I set the hostname to "".

3. Yes I get the same result when I remove the client cert after
authenticating and only include the cookie.

David Woodhouse also replied and said this reminds him of a Pulse
endpoint that only allows Proxy Web Access and not an IP Tunnel. I
think he may be correct that this is what error 0x08 indicates. When I
authenticate in a browser, I get a page that is limited to various
proxy web bookmarks and RDP sessions that it tells me are not supported
n my OS (I'm assuming Java only maybe?). However, when I use the Pulse
Secure client software on a supported machine, after authentication, it
runs the hostchecker to verify compliance, checking things like AV and
firewall and then establishes the tunnel. So my guess is, when
openconnect is sending the hostname, the Pulse Secure app is doing some
second level of authentication or requesting the host checker bits or
something.

I'll see if I can get some captures of the official client to get more
information.

Thank you both.

Post by Brandon Liles
Thanks very much for taking the time to look into this.
Yes, I get the exact same result with 7.08 and with v7.08-125-
g31b5c4a.
Attempting to connect to server xxx.xxx.xxx.xxx:443
Connected to xxx.xxx.xxx.xxx:443
Using certificate file /home/***********
Using client certificate '/CN=********'
SSL negotiation with ***
Matched peer certificate subject name '***'
Connected to HTTPS on ***
Got HTTP response: HTTP/1.1 200 OK
Content-type: application/octet-stream
Pragma: no-cache
NCP-Version: 3
Set-Cookie: DSLastAccess=1535592203; path=/; Secure
Connection: close
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000
0000: 16 00 00 04 00 00 00 09 00 62 6c 69 6c 65 73 2d
0010: 6c 78 bb 01 00 00 00 00
Read 3 bytes of SSL record
< 0000: 01 00 08
Server response to hostname packet is error 0x08
Creating SSL connection failed
Please let me know if there's something else I can do to help you
troubleshoot.
Thanks. I noticed the local hostname specified in your auth packet contains
a '-', which I thought might conceivably confuse some buggy server. But
I tried specifying hostnames with '-' on two different Juniper VPNs, and
both accepted it. So that's not it.
1) You may want to try varying the local hostname (e.g.
`--local-hostname localhost` or
`--local-hostname
NAME_OF_A_COMPUTER_THAT_WORKS_WITH_THE_OFFICIAL_CLIENT`)
2) Try removing the local hostname entirely (e.g.
`--local-hostname ""`). Do you get "error 0x05" instead?

Post by Brandon Liles
0000: 0d 00 00 04 00 00 00 00 00 bb 01 00 00 00 00

Read 3 bytes of SSL record
< 0000: 01 00 05
Server response to hostname packet is error 0x05
3) I notice that your connection requires a client certificate. VPN
servers have many quirky and buggy behaviors when client
certificates are involved. Try this: specify the client
certificate
for authentication (to get the DSID), but omit it when trying to
actually connect.
In other words, first get the DSID as you've been doing, and then…
# LEAVE OFF THE CLIENT CERT!
openconnect -C 'DSID=...' vpn.company.com
Does that give the same result?
Assuming #1 and #3 don't change anything, and #2 gives you error 0x05
instead, MITM'ing and capturing traffic from a working official client
would probably be the only next step.
Dan
http://lists.infradead.org/pipermail/openconnect-devel/2015-March/002
820.html
pps- Here's some evidence that Juniper does strange things with client
certificates, although this one is from the authentication part and
http://lists.infradead.org/pipermail/openconnect-devel/2015-April/002
899.html

[David Woodhouse]

Post by Brandon Liles
Read 3 bytes of SSL record
< 0000: 01 00 08
Server response to hostname packet is error 0x08
Creating SSL connection failed

From distant memory, that seems remarkably like the error we were
getting when it's configured only to let you have proxy web access, not
an IP tunnel?

This server definitely provides a full VPN if you use the "real"
client?

[Daniel Lenski]

Post by David Woodhouse

Post by Brandon Liles
Read 3 bytes of SSL record
< 0000: 01 00 08
Server response to hostname packet is error 0x08
Creating SSL connection failed

From distant memory, that seems remarkably like the error we were
getting when it's configured only to let you have proxy web access, not
an IP tunnel?
This server definitely provides a full VPN if you use the "real"
client?

You mentioned that on one of the previous incidences of this error,
and there too the user reported that the server *did* indeed provide
full connectivity:
http://lists.infradead.org/pipermail/openconnect-devel/2015-March/002822.html

It's hard to tell what the common feature of all of the "error 0x08"
reports is … possibly that they all require Host Checker / TNCC? Is it
possible that this error means something like, "you're trying to
connect the tunnel but haven't yet proven your very speshul securiteh
to Host Checker"?

What's confusing to me is that I thought Host Checker has to run
*before* the server will hand out a DSID cookie, and that once it does
no further special handling is needed.

Dan