11-30-2016 07:44 AM - edited 11-30-2016 07:48 AM
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 ? 🙂
11-30-2016 07:57 AM
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
11-30-2016 08:05 AM
so when he says to me we aren't using ssl we are using IPsec? How do I answer that?
11-30-2016 12:02 PM
@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.
11-30-2016 12:46 PM
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.
11-30-2016 12:52 PM
I imagine that you guys were used to running the legacy Cisco VPN client; pretty much everyone has started to follow this same method.
11-30-2016 11:48 PM
@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 🙂
12-01-2016 06:10 AM
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
12-01-2016 06:11 AM
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
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
