https content inspection

rv@kaufmann.dkrv@kaufmann.dk
in Firebox - Proxies

Hi,

M370 running 12.7 U1

If i set the domain *.a.ecaserver.eset.com to _allow_ in https proxy Content Inspection using pattern match is does not work and i get this error:

2021-06-26 07:24:43 NetGroup-HA1 pxy 0x23c1420-1697548 51: 77.66.18.243:50580 -> 51.105.114.167:443 [B t] {N}: Connect SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/sslv3 alert handshake failure] Domain: angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com PFS: ALLOWED | ALLOWED Debug

If i set domain angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com to allow it works.

Why do the * not work for me?

Regards
Robert

Comments

  • Bruce_BriggsBruce_Briggs

    Maybe the table entry size for saved Domain names is less than 47 bytes?

  • rv@kaufmann.dkrv@kaufmann.dk
    I am not sure, i understand the logic to this?
  • Bruce_BriggsBruce_Briggs

    The firewall will save DNS lookups which match .a.ecaserver.eset.com
    If the table size for saved entries is shorter then 47 bytes (such as 44 bytes) then the entry saved can't match all 47 bytes of angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @RVilhelmsen
    Keep in mind with the HTTPS proxy (if you're listing things to inspect or allow) that we're matching the SNI of the certificate, and not necessarially the FQDN (though they're often the same.) I'd venture a guess that eset probably loads these on a CDN for distribution, so the cert may not be what you think it is.

    If you're looking to match based on FQDN, a https packet filter with that FQDN may work better for you.

    -James Carson
    WatchGuard Customer Support

  • rv@kaufmann.dkrv@kaufmann.dk

    @James_Carson
    I did not have this in mind. I will look into this, thank you.

    /Robert

  • greggmh123greggmh123
    edited June 2021

    Robert, is there a trailing /* on your rule? I just looked at my clients' T35 boxes running 12.5.7 U3 and then my T20W running 12.7 U1. In my T20, about the first half of my DPI exceptions end with a slash and star as in "* .ca.gov / *" (I added spaces because I don't think the forum will post it correctly. It's star-dot-ca-dot-gov-slash-star, while the T35s both have just star-dot-ca-dot-gov format. I think I remember there being an issue with this before, maybe during a beta, and I had to drop the slash-star at the end to get them to work. The reason I bring it up is that my wife could not reach LLCbizfile.sos.ca.gov despite there being a star-dot-ca-dot-gov exception. I added a *.sos.ca.gov exception and the site loaded fine.

    Gregg Hill

  • greggmh123greggmh123
    edited June 2021

    EGAD. This forum just does not let one make a plain old post! It made a bunch of my text in italics.

    Gregg Hill

  • rv@kaufmann.dkrv@kaufmann.dk

    @Greggmh123

    All my exceptions has no /* in the end. This would note make sense to enter a /* in the end as this would refer to files and directories and not domains and hosts.

  • greggmh123greggmh123

    @RVilhelmsen said:
    @Greggmh123

    All my exceptions has no /* in the end. This would note make sense to enter a /* in the end as this would refer to files and directories and not domains and hosts.

    That's what I thought. I think it happened during a beta and they fixed it, but either it's back, or I never fixed this Firebox. I just exported my exceptions and used Notepad++ to dump the slash-star, then imported that file back into my config.

    Gregg Hill

  • rv@kaufmann.dkrv@kaufmann.dk

    @Greggmh123

    I have testet with a /* in the end and it does not work.

    In fact i noticed even my exclusion for angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com did not work all the time. Sometimes i got the Connect SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/sslv3 alert handshake failure.

    What i have done now is made a packet filter which is above my https proxy policy excluding fqdn *.a.ecaserver.eset.com and this seems to solve the issue with the SSL connect error.

    But now i see this getting logged:
    2021-06-29 10:41:41 NetGroup-HA1 Allow 10.100.1.21 51.105.114.167 https/tcp 52035 443 Internal Network External-Eth4 HTTPS Request (HTTPS-proxy-Internal-OUT-00) HTTPS-Client.InternalNetwork proc_id="https-proxy" rc="548" msg_id="2CFF-0000" proxy_act="HTTPS-Client.InternalNetwork" tls_profile="TLS-Client-HTTPS.KaufmannInternalNetwork" tls_version="SSL_0" sni="angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com" cn=".a.ecaserver.eset.com" cert_issuer="CN=Thawte RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US" cert_subject="CN=.a.ecaserver.eset.com" action="allow" app_id="0" app_cat_id="0" sig_vers="18.156" sent_bytes="6053" rcvd_bytes="9585" geo_dst="NLD"

    So traffic going to angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com works now via a https filter, but still i am seeing the above. What´s the logic here?

  • rv@kaufmann.dkrv@kaufmann.dk

    @Greggmh123 @James_Carson

    The SNI is the same as the FQDN, sni="angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com".

    Could it be a issue the tls connection is not a rfc standard ssl/tls protocol connection maybe?

  • Bruce_BriggsBruce_Briggs

    This suggests that the packet filter is not being used for all of the packets for that destination. Some seem to be using the HTTPS proxy.

  • RalphRalph WatchGuard Representative

    Hello @RVilhelmsen

    "...Connect SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/sslv3 alert handshake failure] Domain: angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com...."

    This error is caused by the server side requesting the client certificate which the proxy does not have and cannot provide during TLS negotiation. This negotiation process isn't currently supported by the proxy.

    The proxy emits the following log when it runs into this snag.
    "...pxy server requested client certificate - not supported Debug..."

    RE: CI exceptions. Your wildcard exception should absolutely work here and allow the client to connect to the server. If you test the connection manually, eg. in a browser, the rule should fire...

    2021-06-29 14:34:30 Allow ProxyAllow: HTTPS domain name match rule_name="*.a.ecaserver.eset.com" sni="angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com"

    ...and the browser should report the same as the Firebox...

    "....angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com didn’t accept your login certificate, or one may not have been provided.
    Try contacting the system admin. ERR_BAD_SSL_CLIENT_AUTH_CERT....."

    Ralph

  • rv@kaufmann.dkrv@kaufmann.dk

    Hi @Ralph

    Here is what I see when traffic is going through a fqdn packet filter vs. proxy with content exclusion.

    PROXY content exclusion:
    2021-06-30 10:39:00 Webshop-HA1 Allow 172.16.1.38 51.105.114.167 https/tcp 53001 443 Internal network TDC-EXT ProxyAllow: HTTPS domain name match (HTTPS Internal-OUT-00) HTTPS-Client.Webshop internal proc_id="https-proxy" rc="590" msg_id="2CFF-0003" proxy_act="HTTPS-Client.Webshop internal" rule_name=".a.ecaserver.eset.com" sni="angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com" cn="" ipaddress="" src_user="robert@kaufmann.local" geo_dst="NLD" Traffic
    2021-06-30 10:39:00 Webshop-HA1 Allow 172.16.1.38 51.105.114.167 https/tcp 65452 443 Internal network TDC-EXT HTTPS Request (HTTPS Internal-OUT-00) HTTPS-Client.Webshop internal proc_id="https-proxy" rc="548" msg_id="2CFF-0000" proxy_act="HTTPS-Client.Webshop internal" tls_profile="TLS-Client-HTTPS.Standard.1" tls_version="SSL_0" sni="angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com" cn="    .a.ecaserver.eset.com" cert_issuer="CN=Thawte RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US" cert_subject="CN=.a.ecaserver.eset.com" action="allow" app_id="0" app_cat_id="0" sig_vers="18.157" sent_bytes="1365" rcvd_bytes="8633" src_user="robert@kaufmann.local" geo_dst="NLD" Traffic
    2021-06-30 10:39:00 Webshop-HA1 Allow 172.16.1.38 51.105.114.167 https/tcp 65452 443 Internal network TDC-EXT ProxyAllow: HTTPS domain name match (HTTPS Internal-OUT-00) HTTPS-Client.Webshop internal proc_id="https-proxy" rc="590" msg_id="2CFF-0003" proxy_act="HTTPS-Client.Webshop internal" rule_name="    .a.ecaserver.eset.com" sni="angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com" cn="" ipaddress="" src_user="robert@kaufmann.local" geo_dst="NLD" Traffic
    2021-06-30 10:39:00 Webshop-HA1 pxy 0x2bc7300-563474 199: 195.249.78.2:65452 -> 51.105.114.167:443 [B t] {N}: Connect SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/sslv3 alert handshake failure] Domain: angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com PFS: ALLOWED | ALLOWED Debug
    2021-06-30 10:39:00 Webshop-HA1 pxy 0x3df0620-915040 250: 195.249.78.2:53001 -> 51.105.114.167:443 [B t] {N}: Connect SSL Error [ret -1 | SSL err 1 | Details: ssl3_read_bytes/sslv3 alert handshake failure] Domain: angf225hyrme5n3xn5tbclqteu.a.ecaserver.eset.com PFS: ALLOWED | ALLOWED Debug

    packet fqdn filter:
    2021-06-30 10:43:53 Webshop-HA1 Allow 172.16.1.38 51.105.114.167 https/tcp 57885 443 Internal network TDC-EXT Allowed 52 127 (HTTPS-TEST-00) proc_id="firewall" rc="100" msg_id="3000-0148" fqdn_dst_match="a.ecaserver.eset.com" src_ip_nat="195.249.78.2" tcp_info="offset 8 S 3861107008 win 61690" src_user="" geo_dst="NLD" Traffic
    2021-06-30 10:43:53 Webshop-HA1 Allow 172.16.1.38 51.105.114.167 https/tcp 58099 443 Internal network TDC-EXT Allowed 52 127 (HTTPS-TEST-00) proc_id="firewall" rc="100" msg_id="3000-0148" fqdn_dst_match="a.ecaserver.eset.com" src_ip_nat="195.249.78.2" tcp_info="offset 8 S 3762636906 win 61690" src_user="" geo_dst="NLD" Traffic

    It works through with the exclusion in the proxy policy, but i still get the SSL err 1 logged. Is this expected?

    /Robert

  • RalphRalph WatchGuard Representative

    thanks Robert,

    Glad we got the exceptions issue sorted.

    "...It works through with the exclusion in the proxy policy, but i still get the SSL err 1 logged. Is this expected?..."
    Yes on the A channel (external) alongside exception match (if Log enabled).

  • Bruce_BriggsBruce_Briggs

    I don't understand why there should be an error logged when the goal here is to not Inspect this traffic.
    I would expect the Allow exception to be essentially the same as having a HTTPS packet filter for this site with Log enabled.
    What am I not understanding here about the HTTPS proxy processing with an Allow exception with Log enabled ?

  • rv@kaufmann.dkrv@kaufmann.dk

    Technical it might be right, but confusing to understand the log when infact there is no end user error.

Sign In to comment.