Learn about the Benefits of Multi-Factor Authentication (MFA) . Turn your MFA on now!
Information: Three minute survey on Exploring more ways to contact Sophos Technical Supportt. If you can spare the time, we would love your feedback!
We'd love to hear about it! Click here to go to the product suggestion community
Releasing has recently gone wrong on my macos Sierra machine.
Tried it with Safari, Firefox and Chrome but all fail:
Safari:Safari Can't Open the Page "https://<fqdn>:3840/release.plc?proto=smtp∓cluster_id=0&message_id=1c2X06-0006pM-MV&size=3469&whitelist;0" because Safari can't establish a secure connection to the server "<fqdn>".
Firefox:Secure Connection FailedAn error occurred during a connection to vgk.rcan.nl:3840. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG
Chrome:This site can’t provide a secure connection<fqdn> sent an invalid responseTry running Network Diagnostics.ERR_SSL_PROTOCOL_ERROR
Now, a day later I found out that Safari is redirecting the http://<fqdn>:3840 to a https request. Odd. anyone experiencing similar issue?
In reply to Gary Prosser1:
I dont see any logic have WAF and DNAT rules for web servicesJust for testLOGOUT from UTM and edit the host file in your PC. Put there the hostname of spam release with internal ip. Flush your PC DNS. And click the link after
In reply to oldeda:
The certificate is redirecting you
You're right that the release is done on a different port, so the repaired NAT rule doesn't make a difference. See #5 in Rulz to understand why you got the error message.
If you have DNAT and WAF, see #2 in Rulz to understand that the DNAT causes traffic to bypass WAF (reverse proxy). See the link in my previous post to understand when you need Full NAT instead of a DNAT.
Oldeda is right - the best solution is split DNS where resolution inside your LAN is to the local IP, not the external address where you have nothing to handle port 3840 traffic from inside your LAN.
Cheers - Bob
In reply to BAlfson:
I get your advice. And maybe I have to swallow it and move all our dns to the utm via interface based host definitions.
Meanwhile our current subnets, dhcp, dns config works fine considering we have a single utm and so for resilience we use ISP dns (via forwarders) for some subnets like visitor wireless where no internal hosts should be available, or lan based dns servers for subnet specific services, or in two cases an AD domain.
Its currently a config that works for all except, and then only recently, in one case (and only for some internal clients) - ie the spam release.
The bit of angst I feel is that the ssl error I've reported seems to come from the utm itself simply because either
- it doesn't have an ssl capable listener on port 3840
- the utm is redirecting non-ssl requests to ssl; I note you say this is a 'side effect' of NAT rules - really ? Actually we can't tell as there is no relevant logging (AFAIK).
Since the default hostname for spam release is the utm itself (with an ssl cert defined, either self signed or uploaded) why is the utm release url coded as http not https ?
This morning I changed the dns record* for utm.<fqdn> from its external interface to my PC's relevant subnet interface
* on our local bind server
Then, from my pc on that subnet, I ping / dig utm.<fqdn> which comes back with the IP of the internal interface.
I try release link - get same ssl error as previously stated. The utm http daemon log has
A little later I also found this in the same log
any news about this issue? Its definitly a chrome issue, because if you have visited one time an url with https, it requests in future only https (damn if you type a wrong url ....). i couldnt find a solution for chrome, all thinks i've found on google are to edit the apache server etc.......
In reply to x.cr3w:
This is also an issue in Firefox
If the browser connects to a HTTPS site (such as the user portal), the browser will change all future access to HTTPS even if on a different port.
As this situation only occurs when UTM already has a certificate, one solution could be to add the option to have the the quarantine release on a different port with HTTPS, this would allow existing quarantine emails to continue to work.
In reply to automaton:
This issue affects both FF on Windows (8) and Linux, and Safari on Mac - so it would be very helpful when Sophos fix it.
On our utm9
Listen 3840<VirtualHost 0.0.0.0:3840> ServerAdmin admin DocumentRoot /var/content/httpd-spam SSLEngine Off Options ExecCGI <Directory /var/content/httpd-spam> <Files _*> Order Deny,Allow Deny from All </Files> </Directory></VirtualHost>
it could be
SSLEngine on SSLCertificateFile /etc/httpd/WebAdminCert.pem SSLCertificateKeyFile /etc/httpd/WebAdminKey.pem SSLCACertificateFile /etc/httpd/WebAdminCertCA.pem
which is what is in
BUT the release links would have to be https://etc
HAProxy could be used to listen to both HTTP and HTTPS on the same port, and proxy the connection to the appropriate web server instance
In reply to sachingurung:
The issue is quite simple, HSTS is set on the user portal, because HSTS is set, "modern" browsers that honour the HSTS flag, change all access to HTTPS (the port is irrelevant)
The only fix is to have the quarantine release run on HTTPS
automaton, I agree please see my post of
12 Apr 2018 12:32
how can we make an urgent request for Sophos to provide this 2 part fix ? it seems fairly straightforward.
Sounds good. I think its time to change all the links from utm to https. is there a way to do that? is sophos planing something about this?
Got the same error on our customers. You guys already found out that it seems to be caused from HSTS.
I hope Sophos will fix this soon.
I'm just a home user, as a platinum partner, you might have more "leverage"...
Support Case created and a preliminary response received. I should hear back by Monday evening PDT USA.