SSL_ERROR_RX_UNEXPECTED_APPLICATION_DATA

intrusus said:

When entering its FQDN in the browser I get the following error: SSL_ERROR_RX_UNEXPECTED_APPLICATION_DATA

From time to time entering its FQDN I also get forwarded to a wrong IP and see the following in the address line: https://172.27.15.1:8090/ips/block/tls?te=[...]
172.27.15.1 is the LAN adress of the XG firewall which seems a bit weird now...

When in DPI mode, the XG cannot display block pages.  In the simpler HTTP case it can only do two things:

1) If the data stream is already in progress (eg at least one packet from the server's HTTP response has been sent back to the client) then the XG can kill the connection.

2) If the data stream is not yet started then the XG can fake an HTTP response that is maximum size of one packet.  That is small enough that we cannot do a block page, but we can do a redirection.

If 1) occurs the XG will remember for 2.5 minutes that the client was blocked to that URL and if the client tries to go to the same URL again then 2) occurs.

So in HTTP, if you are blocked (midstream) you will first get a data error (for example failed download) and then if you try again you get a redirection.

HTTPS is more complicated because the first packets are SSL negotiation.  However effectively the same thing occurs.  The first attempt the XG will drop the connection (causing the browser to display SSL_ERROR_RX_UNEXPECTED_APPLICATION_DATA) and the second attempt to the same URL gets a redirect.

There may be additional complication in your case because the cause for the block is because of part of the SSL negotiation and the drop may be occurring mid-negotiation.

The system is behaving as expected, as far as I can tell.

Hey Michael,

first of all, thanks for your answer.

It's really nice that you clarify/describe how the XG handles this specific situation.

But can you explain me the difference between the SSL/TLS rule for Xstream and the "Scan http/https" setting in the firewall rule?

Like I wrote in my second post I can relate this error on the name mismatch in the certificate of the ESXi. It would be great if the error messages in the SSL/TLS widget would be more detailed than e.g. "Internal error" but I think your team will also consider this in the next releases of SFOS.

Thank you again and happy new year,

Leon

When using the traditional web proxy the options are the same as 17.5, and the HTTPS decryption choice is coupled with the web settings in the firewall rule.

When using the new DPI engine, the HTTPS decryption choice is decoupled from the firewall rule, which gives the administrator more flexibility.

[ ] Use web proxy instead of DPI engine

If this is checked then the system uses the web proxy (eg the system from 17.5) and the "Web proxy options" below take effect.  This option applies to "common web ports" such as port 80 and 443.  This option does not apply to the direct/explicit/standard mode which uses the defined proxy port 3128, that will always use the web proxy and always use the Web proxy options.

[ ] Decrypt HTTPS during web proxy filtering

If the web proxy is being used then will turn on and off HTTPS decryption.  This option only applies to port 80/443 (if "use web proxy" selected) and port 3128.

If the DPI engine is being used then this has no effect.  The SSL/TLS Inspection Rules are used instead.  The SSL/TLS Inspection Rules apply to every port.

Clicking on the (i) icon for more details.

A question that we have had a few times is when using the DPI mode, why not disable the "Decrypt HTTPS" option because it does not apply in DPI mode.  The reason we don't is that the firewall rule also enables the explicit proxy port 3128 which used the web proxy.

Thank you so much!

intrusus said:

Like I wrote in my second post I can relate this error on the name mismatch in the certificate of the ESXi. It would be great if the error messages in the SSL/TLS widget would be more detailed than e.g. "Internal error" but I think your team will also consider this in the next releases of SFOS.

I don't know as much about the details of this.  AFAIK the "Internal Error" is a catchall for all errors that we don't have specific logging for.  I believe that they are trying to reduce these to increase the ability to troubleshoot, however this has lower priority than other issues currently reported.  In other words we know about the general issue but may not have improvements before 18.0 GA.

intrusus said:

Like I wrote in my second post I can relate this error on the name mismatch in the certificate of the ESXi. It would be great if the error messages in the SSL/TLS widget would be more detailed than e.g. "Internal error" but I think your team will also consider this in the next releases of SFOS.

I don't know as much about the details of this.  AFAIK the "Internal Error" is a catchall for all errors that we don't have specific logging for.  I believe that they are trying to reduce these to increase the ability to troubleshoot, however this has lower priority than other issues currently reported.  In other words we know about the general issue but may not have improvements before 18.0 GA.