- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
09-22-2020 02:27 PM
I work for a DoD agency and they are starting to really crack down on TLS Renegotiation. They are stating that we need to "disable insecure renegotiation: Secure Server not supported" or the offending application will be shutdown. Our GlobalProtect VPN would be denied access from clients
I have opened a case with tech support and they are stating that TLS renegotiation is not a feature of Palo Alto. They are not able to produce any documents supporting that argument so I can present it to the DoD agency threatening to turn off what would be our GlobalProtect VPN.
I have run packet captures and I see the client hello with "Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)" and "Extension: renegotiation_info (len=1)". This means the client is requesting a secure renegotiation. Per RFC 5746, the server should or Palo Alto should abort the handshake if it is not capable of secure renegotiation. I do not see the Palo Alto trying to abort the handshake but possibly ignoring it since the conversations keep going. My assumption is that if it does not understand renegotiation, it would not know what to do with the flag.
I am under the gun to find out since we would need to look for another VPN solution if Palo Alto does allow TLS renegotiation. In addition, it is unknown when they implement TLS 1.3 for GlobalProtect.
Does anyone have an idea on what to look for in a packet capture or what they did to overcome this problem with TLS renegotiation and GlobalProtect?