globalprotect key

[jdprovine]

When I install the globalprotect client on a pc I never have to enter a key, how and when does the key get passed

[reaper]

ehm

well you can slap him with the SSL rfc 😄 (rfc 6101 and 5246 , if you realy want to know 😉 )

the globalprotect ssl relies on exactly the same mechanism any website uses to establish a connection, so you do the

-3 way TCP handshake,

-client hello (i can accommodate these encryption algorythms),

-server hello (i prefer this 'ciphersuite', here is my certificate, and do you happen to have a client cert of your own)

-client key exchange w/ client certificate if you set it up (send secret key info encrypted with server's public key, based off of the server certificate)

-server verifies and finishes 

-communication is encrypted

---- and here globalprotect kicks in----

globalprotect sends username/password

GP server authenticates

etc

etc

if you do a packetcapture of the communication between the client and GP portal, that first sequence of events is visible (the client/server hellos and all), the bit where GP sends user/passwd information will not be visible as it is encrypted 

hope this makes more sense ? 🙂

[jdprovine]

The real question came up when we do installs of the client on a users pc and there is no place to enter a key on the client like there is with a cisco vpn client, so it appears to them that there is no key to pass and no way to encrypt the users password

[jdprovine]

so when he says to me we aren't using ssl we are using IPsec? How do I answer that?

[BPry]

@jdprovine This page might get you what you need to know: LINK. Take a look at the Network tab under IPSec Crypto and you'll see that the default key (the one I believe reaper referenced) uses ases-128-cbc and 3des with sha1 authentication. 

[jdprovine]

I did a packet capture as well as verified that the user through the GP client is connecting via SSL (no clear password) and then the key exchange occurs which is found in the configuration on the firewall. I think the fact that you can't find a place to manually enter the key on the GP client was what was tripping my coworkers up.

[BPry]

I imagine that you guys were used to running the legacy Cisco VPN client; pretty much everyone has started to follow this same method. 

[reaper]

---

@jdprovine wrote:

I did a packet capture as well as verified that the user through the GP client is connecting via SSL (no clear password) and then the key exchange occurs which is found in the configuration on the firewall. I think the fact that you can't find a place to manually enter the key on the GP client was what was tripping my coworkers up.

---

yes.. the 'legacy' vpn clients worked on the principle of basic ipsec: you need to have a preshared key (or similar preshared something) and have determined how you will communicate (encryption algorythms) before you can even start communicating. theres a lot of things you need to manually do and know before you can get started

SSL takes out that need by using a simplified negotiation process reliant on certificates

hope you've been able to bring light to your coworkers 🙂

[jdprovine]

yes I showed them through the packet capture and the monitor logs that the first connection is a ssl one. thanks reaper I really like your new avatar

[jdprovine]

correct we  were have to change your whole thing with GP just like you have to change your whole thinking on how a firewall works a PA that is LOL