Feature Request eine generelle Option in der GUI wird benötigt , damit nur Forward Secrecy fähige Ciphers verwenden werden können, damit auch andere TLS Versionen damit abgedeckt wären.

Das Problem ist, das das BSI im April neue technische Maßnahmen für den IT-Grundschutz heraus gegeben hat.

Darin wird für Web-Anwendungen nur noch TLS 1.2 und TLS 1.3 mit FS empfohlen.

Der eingriff über CLI ist nicht gewünscht:
................................................
/var/storage/chroot-reverseproxy/usr/apache/conf/reverseproxy.conf
Finden Sie recht weit oben die Zeile :
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
Das was hier eingetragen ist. wird vom Rev-Proxy angeboten.
Änderungen hier und Folgeprobleme (Sitchwort Backportability alte Clients zu neuen Cipher suites) sind dann out of support scope.

Daher ist es wünschenswert in der GUI einen Schalter dafür zu haben.

Hier ein Beispiel:

https://www.ssllabs.com/ssltest/analyze.html?d=oma.sparkassen-immo.de&hideResults=on
Sollte aber nur noch TLS-ECDHE erlauben mit FS.

If a webserver is resolvable in DNS with both IPv4 and IPv6 addresses (A and AAAA Records) the UTM Proxy will prioritize IPv6, which is ok.

If the server is not reachable on IPv6 no fallback to IPv4 happens if the proxy is running in Standard mode.

The provided workarounds are:
1 -disable IPv6 on the ASG
=> Seriously, disable IPv6 in 2019 ?

2 -add a DNS static entry for every affected site with only an IPv4 record
=> Definitely not starting to statically add internet hosts...

3 -use HTTP proxy transparent mode instead
=> well yeah, but want if you don't want to...

Here is what I suggest: Implemented Happy Eyeballs into the proxy!
Like squid did in Aug 2012.

Cheers,
Marius

The HTTPS Signing CA should be restricted to Enhanced Key Usage Server/Client Auth, Basic Path Length Constraint = 0 and no private key download should be allowed.

The Certs signed by this default CA are (or should be) used only for Server/(Client) Auth?! Currently the CA has no restriction for Enhanced Key Usage and Basic Constraint path length. So a (compromised) CA could offer certs for any purpose and build unlimited SubCAs.
[The Path len may not be so vulnerable, because keyCertSign isn't set]

Also it shouldn't be allowed to download this CAs private Key. For what purpose (other than compromise) should this be good for?
Also if you fixed all of the above with an own created (Sub)CA, the last part still allowes any admin to compromise the private key.
Best way here (and elsewhere) would be to let the utm generate a CORRECT csr and store the private key internal.

When adding a new 'Service Definition', we need to be able to pick one of the proxy services as the 'Type of definition' so that we can enable tighter security on non-standard ports.

An example of this would be to define a new service named "HTTP.8080" of type "HTTP" source port "1:65535" and destination port "8080" to allow 8080 traffic to still be scanned by the Web Security HTTP proxy.

Another example of this would be to make a new service named "HTTPS.444" of type "HTTPS" source port "1:65535" and destination port "444" to allow 444 traffic to still be scanned by the Web Security HTTPS proxy.

etc...

This is similar to many other suggestions for non-standard ports for web or email protection; but this feature _REALLY_ needs to exist so I may as well throw my $0.02 in from a fresh perspective.

Google is using a new method of delivering content securely by using the HTTPS port 443 via UDP and TLS.
I've noticed from analyzing logs that traffic flowing through QUIC does not pass through the Web Filter, thus allowing unfiltered/unscanned traffic through it. This can pose a threat to network security if used maliciously, additionally, it allows advertisers to stream ads to your browser without being filtered at all, which is both annoying and frustrating.

More about QUIC can be read here : https://www.chromium.org/quic

With that said, I would like to see full support for QUIC natively in Sophos UTM Web Filter. At current, I'm blocking 443 (UDP) at the firewall and via Application control. This is just frustrating to deal with.

what is grayware verdict classifies files that behave similarly to malware, but are not malicious in nature or intent. A grayware verdict might be assigned to files that do not pose a direct security threat, but display otherwise obtrusive behavior (for example, installing unwanted software, changing various system settings, or reducing system performance). Examples of grayware software can typically include adware, spyware, and Browser Helper Objects (BHOs). The grayware verdict allows you to quickly distinguish malicious files on the network from grayware, and to prioritize accordingly.
Antivirus signatures are not generated for grayware and security policies cannot be enforced based on the grayware verdict. However, logs and reports can continue to alert to endpoints downloading grayware, enabling you to take any necessary action.