Little Snitch's primary objective is to monitor processes for internet connections and let the user decide whether to allow or deny them. However, Little Snitch sometimes notices that something is fishy about a program. In this case it wants to let you, the user, know what it has found.
App Translocation warning
This is a hint only, it informs you that permanent rules for the process won't work.
App Translocation is a security mechanism Apple introduced with macOS 10.12 (Sierra). If an application has not been “properly installed”, the operating system maps it to a random path before launching, usually somewhere in
/private/var/folders/. This path randomization prevents loading of resources shipped alongside with the application, a mechanism often used by malware. “Properly installed” means that the application must be started from a code-signed disk image or that it must have been copied to a new location in Finder.
Why is this important to Little Snitch? Since Little Snitch rules refer to processes by their file system path, rules created for one instance of the application won't work the next time it is launched from a different random path. Luckily, the problem can easily be fixed by moving the application to an other location in Finder (and optionally back to its original position, if you prefer to have it there).
Internationalized domain name warning
This is a hint only, it informs you that the displayed domain may be a look-alike.
Internationalized domain names may contain any Unicode character. However, the Unicode character set contains many very similar looking characters. Using these characters, an attacker can construct a domain which is optically indistinguishable from a popular domain in latin characters (“IDN homograph attack”). Consider the domain “applе.com”. Would you have noticed that the “е” is a cyrillic letter? Little Snitch adds a hint when it detects an internationalized domain name, printing its Punycode representation for detailed analysis.
Suspicious program warning
This is a hint only, it informs you that the process may not be trustworthy.
Almost all programs come with a valid code signature from Apple or a registered developer these days. When Little Snitch finds a program without code signature or signed using a certificate not issued by Apple, it warns in the connection alert. The following cases lead to a warning:
- The program has no code signature at all. It's perfectly OK for a program to have no code signature, but you cannot know whether the program has been tampered with or whether it's a look-alike trojan with malicious code.
- The program has a code signature, but the cryptographic verification failed. This means that either the program's executable code itself or a library it has loaded has been modified since the signature was made. You should be worried and research the cause of the modification. Even if there is no malware involved, the files on your disk might be damaged.
- The program has a code signature, but the cryptographic verification failed because it has loaded a library without code signature. This is most likely an error made by the developer. Some developers put libraries into folders where they are not automatically code-signed by Xcode. Little Snitch tells you where the library is located. Inspect it to find out whether it is a legitimate part of the program or whether it is malware. Note that unsigned code always bears the risk that (malicious) modifications cannot be recognized.
- The program has a code signature, but it was made with a development certificate not meant for production releases. This is probably a mistake by the developer, a debug build was released instead of a production build. If you are a developer, you see this warning for your debug builds. Little Snitch warns because development certificates are easier to obtain or steal.
- The program has a code signature, but the certificate chain is formally invalid. An invalid certificate chain may contain certificates which are not made for issuing other certificates or it may have other formal errors. A popular candidate for a formally invalid certificate is a self-signed certificate. You should be very cautious because this type of signature has no advantage over unsigned code or ad-hoc signed code. Maybe somebody wanted to pretend the program had a valid code signature.
- The program has a code signature, but the root of the certificate chain is not Apple. When Apple issues a certificate, they ensure that it contains the developer's real name and a Team Identifier. Certificates issued by other authorities may not contain this information or the information may not be correct. Little Snitch does therefore not know whether the certificate can be trusted.
- The program terminated before Little Snitch could inspect its code signature. You can safely cancel the connection alert because the program has terminated anyway. This case should not happen, but we cannot completely rule out that it occurs.
Program modification warning
This warning is not just a hint, it requires that you make a decision.
Before Little Snitch applies an allow rule, it checks the identity of the program. If this check fails and the identity has changed or cannot be confirmed, it shows an alert with a warning. There are several types of identity check, consisting of several conditions each. This results in a big matrix of possible error messages. All these messages explain how the check was made, what was expected and how the program failed to meet the expectation.
Whatever the message of the warning is, there are usually three choices how to proceed:
- Deny this and every future network connection of the program. When you choose this option, an extra-high priority rule is created which denies all network connections. While the program is detached from the network, you have time to research the issue. If you later decide that the modification was OK and you want to allow connections again, open Little Snitch Configuration, search for the program and double-click the extra-high priority deny rule. Little Snitch now gives you the option to update the identity check and remove the extra-high priority deny rule.
- Accept the change, apply the rule and update the identity check to match the current version of the program. This option is only available if an identity check can be made for the currently running process. Choose this option of you know that the modification was legitimate.
- Disable identity checks altogether. If you frequently update a program without code signature, it may be inconvenient to update the check for every new version. Or if the program always loads an unsigned library and the code signature becomes invalid, you may decide to disable identity checks and accept the additional risk.
Was this help page useful? Send feedback.
© 2016-2021 by Objective Development Software GmbH