Information on Sweet32 for Palo Alto Networks Customers

Showing results for 
Show  only  | Search instead for 
Did you mean: 
L4 Transporter
20% helpful (1/5)

Summary of Sweet32 


Security researchers at INRIA recently published a paper that describes how an attacker could levy an attack against information encrypted using older 64-bit block ciphers, such as 3DES and Blowfish to successfully recover plaintext. To be successful, the attacker would need to monitor a long-lived HTTPS session (the researcher’s proof of concept required a single 3DES HTTPS session be continuously monitored over two days) and be able to exploit a separate cross-site scripting vulnerability (XSS).


These attacks are not effective against modern encryption ciphers like AES and Elliptic Curve Digital Signature Algorithm (ECDSA).


We are not aware of any active attacks against this issue at this time.


Palo Alto Networks customers are only at risk in limited circumstances in the event of a “downgrade attack” which would force Palo Alto Networks systems to use 3DES as an encryption cipher of last resort. Customers who are concerned can prevent these “downgrade attacks” by implementing the workarounds outlined below.



Impact on PAN-OS


Impact on SSL/TLS services on the firewall

PAN-OS system software supports 3DES block cipher as part of the cipher suite list negotiated over SSL/TLS connections terminating on the firewall. These sessions are IP layer 3 SSL services offered by the firewall, such as administrative web access for device management, GlobalProtect portals/gateways and captive portal. Similar to other web servers, PAN-OS maintains an internal cipher preference list. The 3DES cipher is not included in the top priority ciphers in the list since we consider it a weak cipher that will generally not be negotiated by the server. However, a malicious client can offer only the affected block ciphers as part of the client hello message forcing the server to negotiate 3DES.


Another aspect is the duration of the encrypted session that allows for a successful attack. The underlying assumption is that the same set of keys are used for the entirety of the connection.


How to secure SSL access


Palo Alto Networks customers can mitigate the Sweet32 attack by deploying ECDSA certificates and locking down the protocol version to TLSv1.2 for the various SSL/TLS services on the firewall. This ensures that an ECDSA-based cipher suite is negotiated by the server. The 3DES encryption algorithm are supported with RSA authentication. Setting an ECDSA certificate  eliminates the possibility of negotiating the 3DES cipher.


Moreover, elliptic curve ciphers have a built in rekeying mechanism that would kick in sooner than the lifetime of the encrypted session, unlike RSA where rekeying can vary with specific SSL stack implementation. This ensures that a long-lived EC-based SSL session is not susceptible to the Sweet32 issue.


Steps for securing the SSL access:


  1. Generate/import an ECDSA server certificate on the firewall
  2. Create an SSL/TLS service profile with Min and Max versions set to TLSv1.2
  3. Reference the ECDSA certificate in the service profile
  4. Apply the profile(s) to the various L3 SSL/TLS services


Below is a screen capture for securing the web interface admin access of the firewall:




Impact on decrypted SSL traffic through the firewall


Palo Alto Networks customers who have deployed SSL decryption on the internet perimeter (Outbound) or in front of a data center server farm can secure their user population and/or corporate assets against a potential Sweet32 attack.


PAN-OS allows for cipher control on decrypted data traffic flowing through the firewall. The following steps can be used to prevent a potential Sweet32 attack on decrypted data traffic:


  1. Unselect the 3DES cipher in the Objects->Decryption Profile->SSL Protocol Settings->Encryption Algorithms
  2. Apply the decryption profile to your decryption policies

Below is a screen capture of the decryption profile that can be applied to Outbound and Inbound decryption policies:




Impact on SSH administrative CLI access


SSH tunnels are generally used for management access that carry less data at very low data rates. If an SSH connection would have a life size of 32GB or greater of data. An administrator can periodically reset the SSH keys for the management access via a simple expect or tcl script.


The following debug command can be used to reset the SSH keys:

fwadmin@PA-200> debug system ssh-key-reset management


Impact on decrypted SSH access through the firewall


PAN-OS does not support DES/3DES ciphers while performing SSH proxy on management SSH sessions to secured assets behind the firewall. Such a traffic will not be affected by a potential Sweet32 attack.


Impact on IPSec and IKE


Palo Alto Networks next-generation firewalls are deployed in varied environments with a mix of devices supporting older and current IPSec crypto algorithms. PAN-OS supports DES and 3DES ciphers to maintain backward compatibility with such legacy systems and also support them as an IPSec peer.


PAN-OS provides a flexible way to configure each aspect of IKE and IPSec crypto. An administrator has to explicitly select encryption ciphers that need to be negotiated with the peer IKE gateway and IPSec tunnel end point.


This can be achieved by deselecting DES or 3DES algorithms in the IKE and IPSec crypto profile


Below is a snapshot of the crypto profiles that can be used to prevent a Sweet32 attack:




Note: For customers who do not want to remove DES and 3DES as part of phase 1 and phase 2 negotiation, PAN-OS reduces the chances of a potential Sweet32 attack as it rekeys the connection based on the data transferred.


An administrator can set the life size of an IPSec connection by setting the life size as 30GB (or by using a value below 32GB). Here is CLI command that can be used to achieve this:


fwadmin@PA-200# set network ike crypto-profiles ipsec-crypto-profiles corp-ike lifesize

> gb       specify lifesize in gigabytes(GB)

> kb       specify lifesize in kilobytes(KB)

> mb       specify lifesize in megabytes(MB)

> tb       specify lifesize in terabytes(TB)

  <Enter> Finish input


Should you have any questions or need assistance with implementing the steps outlined above, please don’t hesitate to contact our support team at


The Palo Alto Networks Support Team

Rate this article:
L0 Member

We now just need the ability on PANOS to generate a CSR with 2048 bit key for ECDSA certificates and we have a full solution.

L0 Member

According to support the current version of firmware cannot generate a ECDSA CSR stronger than 256 bits. All the CA's (Verisign, etc..) require a minimum bit lenght of 2048 CSR to grant an ECDSA certificate.


How is this solution going to work?





L0 Member

Why cant PAN allow the disabling of DES and 3DES ciphers on the platform?

L1 Bithead

I agree that it would be better to remove 3DES ciphers from the supported cipher list.


Can you even apply SSL/TLS service profiles against the integrated User-ID listening on the management interface of the

PA firewall?

L0 Member

Personally, I would like to know why PaloAlto does not reply to any of these queries.

L1 Bithead



Opened a case with PA. They say it will be addressed in PANOS 9. Not sure what year that will happen so we ended up turning the listener off in Interface Management. 

We have a 3020 and 2050. They aren't releasing PANOS 8 for the 2050 even though the 2050 is supported for a couple more years! Who knows whether they will do the same with the 3020 and PANOS 9.

"Supported" should mean "PA will fix CVEs regardless of PANOS version." 

Register or Sign-in
Article Dashboard
Version history
Last Updated:
‎07-20-2020 12:36 PM
Updated by: