Note: 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 SSL protocols and ciphers that Burp will use when performing SSL negotiation with upstream servers. You can configure Burp to use the default protocols and ciphers of your Java installation, or override these defaults and enable specific protocols and ciphers as required.
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 negotiations.
The following other options are available:
These settings can be used to enable certain SSL features that might be needed to successfully connect to some servers.
The following options are available:
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 destination host.
The following types of client certificates are supported:
Note: Java does not currently support PKCS#11 on 64-bit versions of Windows.
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.
Get help and join the community discussions at the Burp Suite Support Center.
This release introduces a new scan check for second-order SQL injection vulnerabilities. In situations where Burp observes stored user input being returned in a response, Burp Scanner now performs its usual logic for detecting SQL injection, with payloads supplied at the input submission point, and evidence for a vulnerability detected at the input retrieval point.