Compatibility with juniper ssl vpn ?

[Guillaume Rousse]

Hello.

I'm using openconnect with Cisco SSL VPN, it works perfectly. However,
we also use juniper-based similar solutions:
http://mad-scientist.us/juniper.html

I have no clues about the internal differences between both
implementations, however I imagine there is some kind of similarity
between two different kind of SSL VPN. Does anyone have any idea about
how much work it would be to make openconnect juniper compatible ?

[David Woodhouse]

Post by Guillaume Rousse
Hello.
I'm using openconnect with Cisco SSL VPN, it works perfectly. However,
http://mad-scientist.us/juniper.html
I have no clues about the internal differences between both
implementations, however I imagine there is some kind of similarity
between two different kind of SSL VPN. Does anyone have any idea about
how much work it would be to make openconnect juniper compatible ?

You'll have to start by showing us how the Juniper VPN works. Can you
show the traffic between client and server? Is it HTTP-based? Can you
point it at your own server or SSL MiTM proxy and show what it's
actually doing?

[Guillaume Rousse]

Post by David Woodhouse
You'll have to start by showing us how the Juniper VPN works. Can you
show the traffic between client and server? Is it HTTP-based? Can you
point it at your own server or SSL MiTM proxy and show what it's
actually doing?

OK, here is what I know about it (I can ask my network colleagues for
details if needed).

For the end-user, it works exactly like Cisco solution: web based
interface only for http tunneling, and 'automatic' deployment of a
native binary for other kind of network traffic.
http://mad-scientist.us/juniper.html has a few screenshot of the
interface, and additional informations about it.

The binary is setuid, and creates a tun interface for vpn traffic. From
ldd and strings output, it seems to be statically linked with openssl. I
made it available as http://www.zarb.org/~guillomovitch/ncsvc

Here is a network capture of a failed attempt to create the VPN. I'm a
bit relunctant to post the successful attempt capture publicly, even if
it seems to be https-only at first glance.

I'd gladly try to set up an SSL proxy, but I'd need additional
informations for this. I quickly checked openssl man page, it doesn't
seem to be possible with it. However, googling point me to
http://crypto.stanford.edu/ssl-mitm/. Is that the way to go ?

[David Woodhouse]

Post by Guillaume Rousse
I'd gladly try to set up an SSL proxy, but I'd need additional
informations for this. I quickly checked openssl man page, it doesn't
seem to be possible with it. However, googling point me to
http://crypto.stanford.edu/ssl-mitm/. Is that the way to go ?

Something like that, perhaps. Or just use 'openssl s_server' and point
your client at it, then manually cut and paste its requests into
'openssl s_client' pointed at the real server.

Or stick a breakpoint on the SSL_write() and SSL_read() functions (or
override them, but that's easier if it's dynamically linked to OpenSSL).

Your packet capture is good enough to confirm that it's really
connecting over HTTPS, but you knew that already. We really need to see
what's *inside* the HTTP connection.

[Antonio Borneo]

Post by David Woodhouse
Something like that, perhaps. Or just use 'openssl s_server' and point
your client at it, then manually cut and paste its requests into
'openssl s_client' pointed at the real server.

If you plan to play with 'openssl s_server' and 's_client' on Unix,
try with and without "-crlf" command line flag.
Many client/server work only with such flag.

Best Regards,
Antonio Borneo

[David Woodhouse]

Post by Antonio Borneo
If you plan to play with 'openssl s_server' and 's_client' on Unix,
try with and without "-crlf" command line flag.
Many client/server work only with such flag.

Yeah, sorry, I forgot to mention that.

It does look like it should work. Use 'openssl s_server' and end your
responses with 'q' on a line by itself to close the connection. Then
relay the responses from the real server, and you should see what it's
doing. For the auth stage at least, beyond which I cannot see, it does
look fairly similar. Not the same, but it doesn't look *stupid* to
contemplate using openconnect for it too.

It depends what you see after the authentication though, of course.

[Guillaume Rousse]

Post by David Woodhouse

Post by Guillaume Rousse
I'd gladly try to set up an SSL proxy, but I'd need additional
informations for this. I quickly checked openssl man page, it doesn't
seem to be possible with it. However, googling point me to
http://crypto.stanford.edu/ssl-mitm/. Is that the way to go ?

Something like that, perhaps. Or just use 'openssl s_server' and point
your client at it, then manually cut and paste its requests into
'openssl s_client' pointed at the real server.

I just tried this, but I didn't achieved to make the client successfully
negociate an ssl session with my proxy.

Here is my proxy server command line:
openssl s_server
-key /etc/pki/tls/private/localhost.key
-cert /etc/pki/tls/certs/localhost.crt
-debug
-accept 443

Here is my client command line:
~/.juniper_networks/network_connect/ncsvc \
-h beria.zarb.home \
-u rousse \
-r smi \
-f /etc/pki/tls/certs/localhost.crt

I'm attaching the proxy output. The certificate/key pair used here has
nothing to do with the actual juniper vpn, but the hostname in the CN
matches the one used in the client command line. I may eventually get a
copy of the original certificate if needed, but I'm not the sure this is
the actual problem.

Sorry if I'm missing something obvious here, it's a bit beyond my own
technicals skills.

[David Woodhouse]

Post by Guillaume Rousse
I'm attaching the proxy output.

You lie.

[Guillaume Rousse]

Post by David Woodhouse

Post by Guillaume Rousse
I'm attaching the proxy output.

You lie.

Indeed :)

Here it is.

[David Woodhouse]

Post by Guillaume Rousse
~/.juniper_networks/network_connect/ncsvc \
-h beria.zarb.home \
-u rousse \
-r smi \
-f /etc/pki/tls/certs/localhost.crt

There's no -m option here. If you look in
~/.juniper_networks/network_connect/ncsvc.log you'll probably see a line
like:

20101228160000.207947 ncsvc[p21179.t21179] dsssl.error ive_cert_hash = 6f13afc3c6815ab480b2ddc27406ba4b, computed_hash = ecb77116a55194c4dfba8e9aa0cc862e (DSSSLSock.cpp:761)

It doesn't like the self-signed cert on your "server". For the above
example log line, you want to add '-m ecb77116a55194c4dfba8e9aa0cc862e'
to your ncsvc invocation. Obviously, yours will differ from mine.

You *may* need to use the -m option with a dummy argument just to make
it give this log line; I'm not sure.

[Guillaume Rousse]

Post by David Woodhouse

Post by Guillaume Rousse
~/.juniper_networks/network_connect/ncsvc \
-h beria.zarb.home \
-u rousse \
-r smi \
-f /etc/pki/tls/certs/localhost.crt

There's no -m option here. If you look in
~/.juniper_networks/network_connect/ .log you'll probably see a line
20101228160000.207947 ncsvc[p21179.t21179] dsssl.error ive_cert_hash = 6f13afc3c6815ab480b2ddc27406ba4b, computed_hash = ecb77116a55194c4dfba8e9aa0cc862e (DSSSLSock.cpp:761)
It doesn't like the self-signed cert on your "server". For the above
example log line, you want to add '-m ecb77116a55194c4dfba8e9aa0cc862e'
to your ncsvc invocation. Obviously, yours will differ from mine.
You *may* need to use the -m option with a dummy argument just to make
it give this log line; I'm not sure.

It work better now, thanks.

I tried the cut/paste gymnastic between s_server and s_client.

Client:
GET / HTTP/1.0
Host: portail.saclay.inria.fr
Accept: */*
Accept-Language: en-us
Connection: Keep-Alive
User-Agent: DSClient; Linux
Content-length: 0

Server:
HTTP/1.1 302 Found
Location:
https://portail.saclay.inria.fr/dana-na/auth/url_default/welcome.cgi
Content-Type: text/html; charset=utf-8
Set-Cookie: DSSIGNIN=url_default; path=/dana-na/; expires=Thu,
31-Dec-2037 00:00:00 GMT; secure
Set-Cookie: DSIVS=; path=/; expires=Thu, 01 Jan 1970 22:00:00 GMT; secure
Set-Cookie: DSSignInURL=/; path=/; secure
Connection: close

Client:
GET /dana-na/auth/url_default/welcome.cgi HTTP/1.0
Host: portail.saclay.inria.fr
Accept: */*
Accept-Language: en-us
Connection: Keep-Alive
User-Agent: DSClient; Linux
Content-length: 0
Cookie: DSSIGNIN=url_default; DSSignInURL=/; DSIVS=

Server:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Tue, 25 Jan 2011 16:50:39 GMT
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1

<html>
[a full web page here]
</html>

Client:
ERROR
140007421920936:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
version number:s3_pkt.c:338:
shutting down SSL
CONNECTION CLOSED
ACCEPT

Beyond the reason of the error, they are two suspicious issues here:
1) is it expected to have the binary acting as a web client, requesting
user-targeted web forms ? The submit action of this form triggers a
javascript function, and I don't think the binary as an embedded
javascript interpreter to work as a robot...
2) the initial client request is wrong, it should be 'GET /smi', due to
the usage of -r smi to ncsvc, not 'GET /' (the former leads to the
user-targeted service), the second to the admin-targeted service)

My setup seems to be unsufficient to correctly work as a traffic proxy.