FosterDoug
My feedback
-
7 votes
An error occurred while saving the comment -
19 votes
FosterDoug supported this idea ·
-
9 votes
An error occurred while saving the comment FosterDoug commented
Your post leaves a lot of things unclear. UTM already supports LDAP as a remote authentication service, including support for LDAP with Encryption over port 636. What you want to do may already be implemented.
-
21 votes
An error occurred while saving the comment FosterDoug commented
The presumption is that if your message gets quarantined, the sender is most likely hostile. It is considered unwise to notify bad guys that you consider them to be a bad guy, because it gives them information which may help them determine how they can break into your system.
-
1 vote
An error occurred while saving the comment FosterDoug commented
Signing both inside and out is a best practice. The external signature helps to prove that the encrypted content really came from the nominal sender, which is important for deciding whether to open the message.
The internal signature proves that the encrypted content has not been altered since the signature was applied. I would expect most sites to use double signatures.
I believe Outlook handles both single and double signatures, so if UTM is trying to be an Outlook-equivalent, it should support both single and double signatures.
-
101 votes
FosterDoug supported this idea ·
-
188 votes
An error occurred while saving the comment FosterDoug commented
Multiple issues have been mixed here:
DNS over HTTPS is a tunnelling program for devices that want to override the network administrator's configuration. XG or UTM should be in control of the network, so DNS over HTTPS is not necessary, and I will be trying to block it from my network.DNS over TLS involves two roles: The server role to accept connections from clients, and the client role for DNS requests that XG or UTM sends to the internet because of forwarding, recursion, or local queries.
The client role is needed first, because it is internet traffic that poses the most risk. It needs to attempt DNS over TLS first, then fall back to DNS over UDP if it fails. DNS Flag Day 2020 is working to ensure that TLS queries to public DNS sites will always succeed.
-
34 votes
FosterDoug supported this idea ·
-
5 votes
FosterDoug shared this idea ·
-
32 votes
An error occurred while saving the comment FosterDoug commented
This is an odd thing for the PCI scan to be worried about. If the encryption setup is rejected for using an insufficiently-secure ciphersuite, then it will fall back to an unencrypted connection. This does nothing to prevent a man-in-the-middle downgrade attack, it only makes things easier for the attacker. For email, poor encryption is better than none.
Disabling unencrypted email is not viable, because too much legitimate mail still arrives unencrypted.
I guess ciphersuite control could be important for TLS-required correspondents, but I have found no uses for this feature. Even one of the biggest insurance companies, which uses encrypted communication everywhere that it might needed, does not use encryption for marketing information sent under their identity.
If you are not doing encryption-required, the PCI scan issue is silly, and you should just post an exception to the objection.
-
3 votes
An error occurred while saving the comment FosterDoug commented
From the community forum, I recently learned that it is possible to create country blocking exceptions for SMTP. If your exception rule says only "traffic coming from: ALL", it will not work. You need to add your active interface addresses to the list as well. From the post, I was unclear whether to use the interface address or the interface network. Since I was in a hurry, I added both, and now it works. I have not yet raised this behavior with Support. I have been busy and they often declare this sort of thing as a "Feature". So my variation of this feature request is for UTM to behave so that "All" means "All" for SMTP exceptions to Country Blocking. I don't know if this is needed elsewhere or not.
-
2 votes
FosterDoug shared this idea ·
-
1 vote
An error occurred while saving the comment FosterDoug commented
My mistake. After more testing, I have confirmed that 9.506-2 does NOT block when a root certificate is included in the download chain. This request can be closed as COMPLETED.
An error occurred while saving the comment FosterDoug commented
According to the link that I supplied, this problem should have been resolved in OpenSSL 1.02b. With version 9.506-2, UTM is running OpenSSL 1.0.2j-fips. Why is this still a problem?
FosterDoug shared this idea ·
-
5 votes
An error occurred while saving the comment FosterDoug commented
For Standard Web Proxy, this is accomplished in the proxy script or proxy configuration. For Transparent Web Proxy, use exceptions since the skiplist does not support wildcard. Put your domain list into a website override with a tag, such as "Web Proxy Bypass". Then reference the tag in your Exception. You can make the exception unlimited or partial depending on the exceptions that you enable in the exception definition.
-
2 votes
An error occurred while saving the comment FosterDoug commented
I think DH pairs of 1024 and less are considered insufficiently secure. Java 6 and 7 have been deprecated for a long time. Better to upgrade.
-
3 votes
FosterDoug shared this idea ·
-
23 votes
FosterDoug supported this idea ·
-
39 votes
An error occurred while saving the comment FosterDoug commented
This appears to have lost momentum, but I also wonder if it is really needed: (a) FTP is unencrypted, so it should not be used for anything that requires a login or anything that is transferring sensitive data. (b) Uploaded files should not be allowed without a login, or every bad guy on the network will be pushing up garbage. Consequently, FTP should only be used for anonymous downloading. Therefore, virus scanning, the main feature of the current FTP proxies, is not relevant. But perhaps deliberately malformed requests are still a risk to be mitigated.
-
6 votes
An error occurred while saving the comment FosterDoug commented
Well, it seems I just did not understand the log file layout.
sid="" is the code and reason="" is the text that goes with that code. https://lists.astaro.com has the master list of codes and descriptions.FosterDoug shared this idea ·
-
27 votes
An error occurred while saving the comment FosterDoug commented
In a non-trivial implementation, there is a tremendous amount of traffic, so I am guessing that you want to be able to define a filter rule first, then display traffic that complies with the filter. The current process of displaying the log, and then asking if it should be filtered, is cumbersome for a single log and is rarely useful.
This seems unnecessary. Why not simply configure an SMTP profile to a non-existent IP address?