Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Self-signed certificate with CN=PortSwigger in invisible mode

Michel | Last updated: Nov 09, 2015 06:09PM UTC

Hi, When I'm using an proxy listener with "invisible proxying support" in "Per-host" certificate mode. I get a wrong self-certificate with CN=PortSwigger. It works as expected if I use a browser like firefox or curl: curl --insecure --verbose www.google.com: ... * Server certificate: * subject: C=PortSwigger; O=PortSwigger; OU=PortSwigger CA; CN=www.google.com * start date: 2015-10-10 08:57:42 GMT * expire date: 2035-11-04 09:48:07 GMT * issuer: C=PortSwigger; ST=PortSwigger; L=PortSwigger; O=PortSwigger; OU=PortSwigger CA; CN=PortSwigger CA ... But when I use java http client from apache (org.apache.http.client) or "openssl s_client" I get the wrong self-signed cert with wrong CN: openssl s_client -connect www.google.com:443: ... subject=/C=GB/ST=London/L=London/O=PortSwigger/OU=PortSwigger/CN=PortSwigger/emailAddress=mail@portswigger.net issuer=/C=GB/ST=London/L=London/O=PortSwigger/OU=PortSwigger/CN=PortSwigger/emailAddress=mail@portswigger.net --- No client certificate CA names sent --- SSL handshake has read 1375 bytes and written 513 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-SHA ... I'm able to work-around the issue by creating a listener per domain I want to intercept, but as there is not only one it is not very practical. The "Alert" tab fills with the following message: The client failed to negotiate an SSL connection: Received fatal alert: certificate_unknown It would interesting to have the information about which certificate was rejected (CN from original certificate or domain name). Not having this information make my workaround less practical as it discover which domain was requested using other means. Thank you Best Regards Michel Ganguin

PortSwigger Agent | Last updated: Nov 11, 2015 09:08AM UTC

What you've observed sounds like expected behavior (in some situations). Have a look at the help below, particularly the section "Handling SSL Certificates": https://portswigger.net/burp/help/proxy_options_invisible.html In invisible mode, we don't get a CONNECT request from the client indicating the desired host. Usually with browsers we can figure out the host from the SSL client hello message, but not all user agents use this. The help describes some techniques for dealing with this situation. Hope that helps.

Burp User | Last updated: Nov 16, 2015 09:50AM UTC

Thanks for the response. It confirms my issue, it confirms "per-host" certificate generation only works if SNI is present. So let's transform that to a feature request? Is there any work-in-progress about retrieving the domain name from the real upstream SSL server certificate if SNI is not present? Or are there major issues that would make such feature not appear in burp? AFAIK mitmproxy is doing it that way: http://docs.mitmproxy.org/en/stable/howmitmproxy.html

PortSwigger Agent | Last updated: Nov 16, 2015 09:55AM UTC

I believe that Burp is already using all of the techniques described in the mitmproxy link you posted. If SNI is not being used, then Burp needs to negotiate SSL completely blind. We haven't had a CONNECT request with an IP/hostname, and there is no SNI in the client hello. So at this point, we don't know anything about the intended target, so we're not able to fetch anything from the real upstream server.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.