Last updated: September 2, 2022
Read time: 4 Minutes
Some of these options can be defined at both the user and project level. For these options, you can configure your normal options at the user level, and then override these if required on a per-project basis.
These settings control the TLS protocols and ciphers that Burp will use when performing TLS negotiation with upstream servers. You can configure Burp to use all supported protocols and ciphers, the default protocols and ciphers of your Java installation, or override these defaults and enable custom protocols and ciphers as required.
The following other options are available:
- Allow unsafe renegotiation - This option may be necessary when using some client TLS certificates, or attempting work around other TLS problems.
- Disable TLS session resume - This option controls whether TLS connections are cached and reused between requests. Using session resume is generally more efficient but causes problems in some situations.
Verify upstream TLS
Burp Suite has always used fully verified TLS to connect to known services, such as
portswigger.net and the public Burp Collaborator server. However, when communicating with arbitrary websites, it does not verify upstream TLS certificates and supports weak ciphers by default. This maximizes compatibility at the expense of protection against active man-in-the-middle (MITM) and DNS rebinding attacks against websites that enforce HTTPS.
If you're concerned about the possibility of an active MITM attack on your communication with the site that you're testing, you can configure Burp to verify upstream TLS certificates. To do this, go to Project settings > TLS and select the Verify upstream TLS checkbox.
In this scenario, we recommend also selecting the Use default protocols and ciphers of your Java installation option to prevent Burp from using weak ciphers.
Burp Suite does not recognize when a certificate is revoked. The system will accept certificates that were previously valid but have since been revoked.
Java TLS options
These settings can be used to enable certain TLS features that might be needed to successfully connect to some servers.
The following options are available:
- Enable algorithms blocked by Java security policy - As of Java 7, the Java security policy can be used to block certain obsolete algorithms from being used in TLS negotiation, and some of these are blocked by default (such as MD2). Many live web servers have TLS certificates that use these obsolete algorithms, and it is not possible to connect to these servers using the default Java security policy. Enabling this option allows Burp to use the obsolete algorithms when connecting to the affected servers. Changes to this option take effect when you restart Burp.
- Disable Java SNI extension - As of Java 7, the TLS Server Name Indication (SNI) extension is implemented and enabled by default. Some misconfigured web servers with SNI enabled send an "Unrecognized name" warning in the TLS handshake. Whilst browsers ignore this warning, the Java implementation does not, and fails to connect. You can use this option to disable the Java SNI extension, and so connect to the affected servers. Changes to this option take effect when you restart Burp.
Client TLS certificates
These settings let you configure the client TLS certificates that Burp will use when a destination host requests one. You can configure multiple certificates, and specify the hosts for which each certificate should be used. When a host requests a client TLS certificate, Burp will use the first certificate in the list whose host configuration matches the name of the host being contacted.
You can use wildcards in the destination host specification (* matches zero or more characters, and ? matches any character except a dot). To use a single certificate whenever any host requests one, use * as the destination host.
The following types of client certificates are supported:
File (PKCS#12) - Note that this must have the
.p12file extension; certificates in
.psxformat are not supported. You will need to configure the location of the certificate file and the password for the certificate.
- Hardware token or smartcard (PKCS#11) - You will need to configure the location of the PKCS#11 library file for your device, your PIN code, and select the certificate from those that are available. The PKCS#11 library file is a native code file that is installed with the software for your device. On Windows, Burp can automatically search common locations to find the library files that you have installed.
Server TLS certificates
This information-only panel contains details of all X509 certificates received from web servers. Double-click an item in the table to display the full details of the certificate.
Was this article helpful?
An error occurred, please try again.