Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp Suite as Invisible Proxy has trouble with Client Hello containing server_name extension

Burt | Last updated: Jun 24, 2020 12:55AM UTC

Hi - Burp Suite generates the following error message after my client sends an HTTPS request with a Client Hello that includes a server_name extension. I read the documentation about Disable Java SNI extension, but it doesn't seem to help either way. 1592956931011 Error Proxy [4] Illegal server name, type=host_name(0), name=devicehelper.cisco.com., value={64 65 76 69 63 65 68 65 6C 70 65 72 2E 63 69 73 63 6F 2E 63 6F 6D 2E}

Burt | Last updated: Jun 24, 2020 12:59AM UTC

This is the section of the Client Hello as seen with Wireshark Extension: server_name (len=28) Type: server_name (0) Length: 28 Server Name Indication extension Server Name list length: 26 Server Name Type: host_name (0) Server Name length: 23 Server Name: devicehelper.cisco.com. This is the section of the TLS Error response from Burp Suite as seen with wireshark Alert Message Level: Fatal (2) Description: Unexpected Message (10)

Liam, PortSwigger Agent | Last updated: Jun 24, 2020 01:25PM UTC

The site is accessible in our testing and we had no problem connecting using Burp Repeater. Would it be possible to provide us with the pcap dump of the client hello? You can email us at support@portswigger.net.

Burt | Last updated: Jun 24, 2020 10:36PM UTC

Hi Liam - This error happens between the proxy unaware client and Burp Suite when acting as an invisible proxy. No packets are seen sent from Burp Suite to the server. I emailed a PCAP of the entire 10 packet TLS conversation and screen shot of the Burp Suite error message on the dashboard.

Burt | Last updated: Jun 25, 2020 03:50AM UTC

Hi Liam - I think BurpSuite is rejecting this Client Hello because the server_name ends with a dot "devicehelper.cisco.com." I verified that when I generate the TLS connection with curl, Burp Suite will have an error when server_name ends in dot. Here are two curl commands. Burp Suite accepts the first and errors on the second. NOTE: curl needs 2 dots to specify one dot curl -v -4 --path-as-is --connect-to devicehelper.cisco.com https://devicehelper.cisco.com curl -v -4 --path-as-is --connect-to devicehelper.cisco.com.. https://devicehelper.cisco.com..

Liam, PortSwigger Agent | Last updated: Jun 25, 2020 07:12PM UTC

Thanks for sending over the file Burt. We'll investigate and get back to you ASAP.

Liam, PortSwigger Agent | Last updated: Jun 26, 2020 09:28AM UTC

Burt, the SNI has a trailing dot which isn’t valid. Please let us know if you need any further assistance.

Burt | Last updated: Jun 27, 2020 02:14AM UTC

Hi Liam - Nuts, I guess some people want to disagree about this http://dns-sd.org./TrailingDotsInDomainNames.html I can't find anything that specifically prohibits a trailing dot in SNI and we all know that a trailing dot is permissible in a URL. If your team can point me to evidence that trailing dot isn't valid in SNI I will create a bug report for the client that generates this. Otherwise I'll have to switch my work from Burp Suite PRO to https://mitmproxy.org/ which doesn't care about trailing dots in the SNI. It copies the SNI from client conversation to server conversation with or without trailing dot. ALSO - I found that not all versions of curl work with the example I gave yesterday. I hope this isn't why PortSwigger says trailing dot isn't allowed in SNI. Either way, the following curl command is the correct way to generate a client hello packet with a trailing dot in the SNI. It works on rasbian, kali, and MacOSX. curl -kv -4 --path-as-is --connect-to devicehelper.cisco.com..:443:devicehelper.cisco.com:443 https://devicehelper.cisco.com..

Burt | Last updated: Jun 27, 2020 02:22AM UTC

Hi Liam - would it do any good to open another request for this under Bugs?

Liam, PortSwigger Agent | Last updated: Jun 29, 2020 07:39AM UTC

Hi Burt, the trailing dot is essentially a Java restriction rather than something that we’ve imposed. Based on Section 3 of RFC 6066, I think that this is as per spec. Here’s a link for Java which also cites the same RFC: https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SNIHostName.html

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