Suite Options: SSL
This tab contains settings for SSL negotiation,
and client and server
These settings control the SSL protocols and ciphers that Burp will use when
performing SSL negotiation with upstream servers.
Sometimes, you may have difficulty negotiating SSL connections with certain
web servers. The Java SSL stack contains a few gremlins, and fails to work with
certain unusual server configurations. To help you troubleshoot this problem,
Burp lets you specify which protocols and ciphers should be offered to servers during SSL
The following other options are available:
- Automatically select compatible SSL parameters on
negotiation failure - If this option is enabled, then when Burp
fails to negotiate SSL using the configured protocols and ciphers, it
will probe the server to try and establish a set of compatible SSL
parameters that are supported by both the server and Java. If compatible
parameters are found, Burp caches this information and uses the
parameters in the first instance for future negotiations with the same
server. This option is generally desirable and can avoid the need to
troubleshoot SSL issues and experiment with protocols and ciphers.
- 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 SSL negotiation, and some of
these are blocked by default (such as MD2). Many live web servers have
SSL 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 SSL
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 SSL 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.
- Allow unsafe SSL renegotiation - This option may be
necessary when using some client SSL certificates, or attempting work
around other SSL problems.
Client SSL Certificates
These settings let you configure the client SSL 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 SSL 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
The following types of client certificates are supported:
- File (PKCS#12) - You will need to configure the
location of the certificate file and the password for the
- 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.
Note: Java does not currently support PKCS#11 on
64-bit versions of Windows.
Server SSL 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.
Wednesday, January 27, 2016
This release adds a new scan check for client-side template injection.
See all release notes ›