This document is outdated. It describes versions before Little Snitch 4.3, which brought many changes to how the identity of a process is verified. The current documentation can be found in chapter Process identity checks

Little Snitch License Key informs you when the program tries to establish an outgoing connection. Now you can enable or disable this connection, or define the rules for how to proceed with similar connection attempts in the future. Little Snitch Crack reliably prevents the sending of confidential data without your knowledge. Jun 13, 2018 Little Snitch’s kernel extension sees that the rule requires a valid code signature by Apple. But the running process is based on the second slice of the fat binary and has no code signature. We call this a code signature mismatch. Little Snitch shows a connection alert that prominently notifies you about this mismatch. Mar 30, 2020 In addition to checking that an application’s code signature is valid, Little Snitch now also checks the code signing certificate that was used to create the signature. Only certificates that were issued by Apple are currently accepted. Improved Little Snitch Installer to prevent malicious software from hijacking the installation procedure.

Code signatures are cryptographic signatures over an application and its resources. They are created by the developer of the application, confirming authorship with this signature. macOS provides functionality that Little Snitch uses to determine whether an application has a valid code signature at the location where it is installed on disk, as well as when it is loaded into memory and running.

For security reasons, Little Snitch requires processes to have a valid code signature when they try to establish network connections. Exceptions can be made by creating rules that do not require valid code signatures or by allowing connections to the local network for processes without a code signature.

Applications without a code signature

Applications without a code signature are suspicious because nobody is taking responsibility for their integrity. There may be several reasons that an application is not signed at all:

The developer does not pay for an Apple Developer Program membership and hence has no trusted certificate to sign with.
The application is very old and was built before code signatures were available.
The application contains malware and nobody wants to take the legal responsibility for it.
Something or somebody removed the signature after a modification (e.g. malware or a person).

If you encounter a software without code signature, it’s up to you to decide whether you want to trust it. If you want to be safe, don’t trust.

Applications without a code signature may get a so-called “ad-hoc code signature” by macOS under certain circumstances. These ad-hoc code signatures can also be created by any user or application without the need for a code signing certificate. Because of this ad-hoc signatures do not offer any security at all.

Therefore, Little Snitch treats applications that are ad-hoc signed as if they had no code signature.

Applications with an invalid code signature

If a code signature exists, but a check turns out that it is invalid, the executable or a resource of the application has been modified after the developer has signed it. It may have been corrupted by erroneous network transmission, by a disk error, something may have been added to the resources intentionally or by accident or it may have been modified with malicious intent.

Do not continue to use the modified application! We recommend that you download the application from its developer and replace the broken version.

Applications with a valid code signature that is broken

Applications that have a valid code signature from their developers on disk may suddenly have no code signature or even an invalid code signature when they are running.

One reason why this may happen is that malware tries to inject malicious code into the running application and thereby change its behavior. The intention behind this could be to use the application’s privileges to do something that was not intended by the application’s developer, like sending personal information about the user to a server on the internet controlled by the malware’s developer.

Another – less nefarious – reason may be that the application loaded a dynamic library that does not have a valid code signature (the same may apply for loading plug-ins). This adds executable code to the running application that runs with the same privileges as the rest of the application. Therefore, anything the application can do, the code from the dynamic library can do. Consequently, if the dynamic library cannot be trusted (i.e. does not have a valid code signature), the whole application cannot be trusted anymore (i.e. cannot be considered to have a valid code signature anymore).

In both of these cases, macOS treats the application as having no valid code signature. This may prevent access to system services such as Location Services, Calendar, Reminders, Keychain (including passwords). Also, Little Snitch rules that require a valid code signature will stop allowing connections. But instead of failing silently like the services in macOS, Little Snitch will notify you about this fact by showing a Code Signature Alert if you are using alert mode, or a notification in the top right corner of the screen if you are using Silent Mode — Allow Connections.

Applications that update themselves without restarting

As explained further below in Accepted code signing certificates, Little Snitch checks the code signing certificate that was used by the developer of an app. To do that, Little Snitch reads the certificate from the app on disk. When an app is running and replaces itself on disk – for example by updating itself – the running process and the executable on disk don’t match up and the certificate for the “old” code signature cannot be verified.

Starting in version 4.1.3, Little Snitch asks you to restart the app in these situations to make the running process and the executable on disk match up again so the certificate can be verified. That’s generally a good idea because the update may also have added or removed resources in the app bundle that the old code doesn’t know about.

Applications that change their bundle identifier in an update

All applications on macOS have a so-called bundle identifier that uniquely identifies it. The bundle identifier is written in reverse DNS notation and is defined by an application’s developer. For example, the bundle identifier for Little Snitch Configuration is at.obdev.LittleSnitchConfiguration

Sometimes, developers change the bundle identifier in an update. For example, if the bundle identifier contains a version number (e.g. com.example.SomeApp2 is changed to com.example.SomeApp3) or if a pro version of an app becomes the only version (e.g. com.example.SomeAppPro becomes com.example.SomeApp).

The code signature of an application contains the bundle identifier and Little Snitch rules that require a valid code signature store this identifier. If an update to an app changes the bundle identifier, there’s a mismatch between the code signature that the rule expects and the code signature the new version of the application has. In earlier versions of Little Snitch 4, this would result in a Code Signature Alert, but in Little Snitch 4.0.5 and later, the existing rules will be updated automatically if the following conditions are met:

The application is located at the same path as the previous version.
The application is signed by the same developer as the previous version.

The developer is identified using a so-called team identifier that is also part of the code signature and that is also stored in Little Snitch rules that require a valid code signature.

Accepted code signing certificates

Little Snitch does not only verify that the process’ code signature is valid, it also checks that the code signing certificate that the developer used for signing comes from Apple. This includes certificates for developers who sign their apps using a Developer ID certificate, apps distributed via the App Store, and apps that ship with macOS. Little Snitch currently does not accept code signing certificates that were not issued by Apple.

If you run an app that has a valid code signature, but the code signing certificate that was used to create that signature is not accepted by Little Snitch, you will see a warning about it in the connection alert and any rules you create will not be able to require a valid code signature. When you create a rule that allows a connection for such an app, Little Snitch will ignore the app’s code signature and everything should work as normal.

Expired certificates

To create a code signature for an application, its developer must have a code signing certificate. For macOS applications, Apple supplies these certificates to developers who are enrolled in its developer program.

Like most cryptographic certificates, code signing certificates have an expiry date after which they become invalid. But what does this mean for code signatures created with that certificate? Will every application’s code signature become invalid, when the certificate used to sign it has expired?

The answer is no. A code signing certificate must be valid at the time the developer signs the application. At the time of signing, a (certified) timestamp is added so that everybody can check whether the certificate was valid at that time.

So it’s perfectly OK if you inspect a certificate and it turns out to be expired, as long as it was valid at the time of signing.

Rule matching and code signatures

Little Snitch rules can be set to require a valid code signature. This is the default for new rules for applications with a valid code signature. These rules do not only demand that the code signature is valid, they also ensure that the app’s developer has not changed since the rule was created. You can update an app without making rules invalid (because the developer is the same), but you cannot replace it with something that has the same name but is from a different developer. Rules for Any Process do not require a valid code signature by a specific developer, only that the application has a valid code signature.

If you upgrade from Little Snitch 3, Little Snitch 4 will require a valid code signature for all rules where possible.

When a rule is matched against a process, the in-memory code signature of the process is used, not the code signature of the executable on disk. This has two consequences:

Modifications of the process are detected, even if they have been made dynamically in-memory only, e.g. by loading an untrusted library or by code injection (see above for more details).
Application resources are not checked, only the code executed. Verifying an application‘s resources may take minutes to complete for large applications. Doing that on every data packet transferred is simply not possible. Verifying the executable code costs no time because the macOS kernel caches this information anyway.

When an allow rule matches a connection but the code signature does not match what is required, Little Snitch does not silently skip over to the next rule. Instead, Little Snitch will notify you about it by showing a Code Signature Alert if you are using alert mode, or a notification in the top right corner of the screen if you are using Silent Mode — Allow Connections.

Deny rules never require a valid code signature because there’s no harm in denying connections of an application with no valid code signature compared to denying connections of an application with a valid code signature. These rules are not a privilege any malware might want to gain.

Special handling of local network connections

There is one exception to the procedure outlined above: Little Snitch ships with two factory rules that allow Any Process outgoing connections to and incoming connections from the local network. This rule requires that the connecting process has a valid code signature (issued by any arbitrary developer) in order to prevent malware such as ransomware to spread to all computers in the local network. However, it turned out that many applications that are active in the local network do not have code signatures, especially printer drivers for networked printers from reputable companies. This will probably change in the future, but currently (mid 2017), this is the status quo. Since Code Signature Alerts are not always easy to understand, we want to save unexperienced users from them, at least for local network activity. We could have removed the code signature requirement from the local network rules, but that would have weakened security for all users and made these processes without a code signature harder to find.

Little Snitch therefore has an other mechanism: If the factory rules for local network connections do not match because the process has no code signature (note: not because the signature is invalid), a rule for any local network connection for that process is automatically created that ignores the code signature. This rule is shown in Little Snitch Configuration under Suggestions and a notification is shown in the top right corner of the screen so that you know that this happened.

For security-aware users who don’t fear a Code Signature Alert, there is a preference setting: Preferences > Security > “Ignore code signature for local network connections”. If the status quo changes and more printer drivers ship with a valid code signature, we will probably change the default for this preference in a later release.

Code Signature Alerts for code signature issues

In alert mode, Little Snitch shows a connection alert whenever an application tries to establish a connection and there is no existing rule for that particular connection. If the connecting process has no code signature, Little Snitch will point this out as a warning. The rules created from the connection alert will not require a valid code signature.

But if there is an existing allow rule that requires a valid code signature and the connecting process either does not have any code signature at all, or its code signature is invalid, the rule will not be applied and instead a special kind of connection alert will be shown:

The alert distinguishes the following cases:

An existing rule matches, but requires a valid code signature and:
- the process has no code signature.
- the process’ code signature is invalid.
- the process’ code signature is from a different developer than what the rule requires.
An existing rule for Any Process would match, but it requires a valid code signature and:
- the process has no code signature.
- the process has an invalid code signature.

All of the above cases can occur separately for an application as well as a helper tool it might use (the via process).

The Code Signature Alert offers the following options depending on the situation:

You can Deny Any Connection. If you choose this option, a special Code Signature Issue Override rule will be created. See below for more information on what this means.
If any rules for the application exists already, the alert offers an option to update them with the current code signature of the running process:
- If the process has a valid code signature, the rules will require that code signature in the future.
- If the process does not have a code signature or if it has an invalid code signature, the rules will ignore the code signature in the future.

Update existing rules only if you know why the code signature changed and if you trust the currently running application!

Silent Mode and code signature issues

In Silent Mode, Little Snitch automatically allows or denies connection attempts for which no existing rules match. To actually stay “silent”, Little Snitch will also not show a Code Signature Alert if there is an issue with an application’s code signature. Depending on the current operation mode, the behavior will be slightly different:

Silent Mode – Allow Connections: A special Code Signature Issue Override rule is created (see below for more information) and a notification will be shown in the top right corner of the screen telling you that a connection was denied. Click the notification to open Little Snitch Configuration and automatically select the rule in Suggestions > Code Signature Issue.

Silent Mode – Deny Connections: Because connections for which no rules exist are denied anyway, no special rule is needed for new connections. But if an allow rule exists that matches a connection, Little Snitch will override that rule by behaving the same way as in Silent Mode – Allow Connections described above.

Special Code Signature Issue Override Rules

To prevent an application any further network access in case of a code signature issue, Little Snitch may create a special Code Signature Override rule. This rule is created when you click Deny Any Connection in a Code Signature Alert or for certain code signature issues in Silent Mode.

This kind of rule denies any network connection to the respective application. It is recommended that you fix the cause for the application’s problematic code signature and then delete or edit the rule in Little Snitch Configuration, where it can be found in Suggestions > Code Signature Issue. For more information, see What you can do when Little Snitch reports a code signature issue.

Little Snitch Disable Code Signature Free

Troubleshooting

If an application has an issue with its code signature, it is often not obvious what the cause is. Depending on the severity of the problem and the specific circumstances Little Snitch will behave differently. This section describes which issues Little Snitch handles and what you can or should do in these situations to fix it.

No rules for the process exist and it has no code signature

or

Non-matching rules for the process exist that ignore the code signature, and it has no code signature

Example 1

You launch an application for the first time. The application was not signed by its developer.

Example 2

You installed a command line tool via Homebrew. Because Homebrew downloads the source code and compiles it on your machine, there is no code signature. These commands are usually run in Terminal (or another a terminal emulator) and are therefore often via-connections. In this example, no rules for Terminal exist.

Note: If there are rules for Terminal that require a valid code signature, this case is not applicable. Instead, see Matching rules for an application exist, but the connecting via-process has no valid code signature.

What Little Snitch does:

Alert Mode: A normal connection alert is shown with a warning in the upper portion. You can Allow or Deny the connection as usual.
Silent Mode – Allow Connections: Connection is allowed.
Silent Mode – Deny Connections: Connection is denied.

See below for common reasons for code signature issues and what you can do about them.

No rules for the process exist and it has an invalid code signature

or

Non-matching rules for the process exist that ignore the code signature, and it has an invalid code signature

Example:

You launched an application for the first time. The application was not signed properly by its developer.

What Little Snitch does:

Alert Mode: A Code Signature Alert is shown and you can either Deny Any Connection or Create a New Rule.
Silent Mode: Connection is denied. See Silent Mode and code signature issues.

See below for common reasons for code signature issues and what you can do about them.

Matching rules for the process exist, but it does not have the required code signature

Example:

You have a rule for a web browser that requires a valid code signature and that allows any outgoing connection. The web browser’s code signature is different from what the rule requires (it is either invalid, or it was signed by a different developer than expected). The rule would match, but there is a code signature mismatch.

What Little Snitch does:

Alert Mode: A Code Signature Alert is shown that allows you to Reveal the matching rule. You can either Deny Any Connection or:
- Accept the New Code Signature if the currently running application has a valid code signature. All existing rules will be updated to require the currently running process’ code signature.
- Ignore the Code Signature if the currently running application has no code signature or an invalid code signature. All existing rules will be updated to ignore the code signature. This weakens the security of these rules.
Silent Mode: Connection is denied. See Silent Mode and code signature issues.

See below for common reasons for code signature issues and what you can do about them.

Non-matching rules for the process exist, but it does not have the required code signature

Example:

You have a single rule for an application that requires a valid code signature and that allows outgoing connections to its developer’s server for software update checks. For whatever reason the application tries to connect to a different server for which no rule exists. Also, the app’s code signature is different from what the existing rule requires (the code signature is missing, it is invalid, or it was signed by a different developer than expected). The existing rule does not match the connection attempt, but it specifies the exact code signature that any rule for that process requires – and that code signature is different, so there is a code signature mismatch.

What Little Snitch does:

Alert Mode: A Code Signature Alert is shown that allows you to Reveal the matching rule. You can either Deny Any Connection or Create a New Rule. If rules for the application exist, creating a new rule also affects them in the following way:
- All existing rules will be updated to require the new code signature if the currently running application has a valid code signature.
- All existing rules will be updated to ignore the code signature if the currently running application has no code signature or an invalid code signature. This weakens the security of these rules.
Silent Mode: Connection is denied. See Silent Mode and code signature issues.

Little Snitch Disable Code Signature Card

See below for common reasons for code signature issues and what you can do about them.

Matching rules for an application exist, but the connecting via-process has no valid code signature

Example:

You installed the wget command using Homebrew. Commands installed via Homebrew do not have a code signature.

You use wget in Terminal to connect to example.com. There is a rule for Terminal that allows any connection and that requires a valid code signature. This rule automatically covers any possible via process (like Terminal via wget) and it requires the via process to have a valid code signature, too (not a specific one – just any valid code signature). But because wget does not have a valid code signature, there’s a code signature mismatch.

Note: If there are no rules for Terminal, this case is not applicable. Instead, see No rules for the process exist and it has no code signature.

What Little Snitch does:

Alert Mode: A Code Signature Alert is shown that allows you to Reveal the matching rule. You can either Deny Any Connection or Create a New Rule. If rules for the application and via process pair exist, creating a new rule also affects them in the following way:
- All existing rules will be updated to require the new code signature if the currently running application and via process both have a valid code signature.
- All existing rules will be updated to ignore the code signature if the currently running application and via process both have no code signature or an invalid code signature. This weakens the security of these rules.
Silent Mode: Connection is denied. See Silent Mode and code signature issues.

See below for common reasons for code signature issues and what you can do about them.

Matching rules for “Any Process” exist, but the connecting process has no valid code signature

Example:

Little Snitch ships with a rule group for macOS Services that contains (among others) a rule that allows “Any Process” outgoing connections to apple.com and that requires a valid code signature. You use an application or a command line tool that has no code signature (e.g. a tool installed via a package manager like Homebrew). The application tries to connect to apple.com and the “Any Process” rule matches, but there is a code signature mismatch between the rule and the application.

What Little Snitch does:

Alert Mode: A Code Signature Alert is shown that allows you to Reveal the matching rule. You can either Deny Any Connection or Create a New Rule. You cannot modify the existing “Any Process” rule because that would affect other applications as well. If rules for the application exist, creating a new rule also affects them in the following way:
- All existing rules will be updated to require the new code signature if the currently running application has a valid code signature.
- All existing rules will be updated to ignore the code signature if the currently running application has no code signature or an invalid code signature. This weakens the security of these rules.
Silent Mode: Connection is denied. See Silent Mode and code signature issues.

See below for common reasons for code signature issues and what you can do about them.

Common reasons for code signature issues reported by Little Snitch

This is a list of reasons for why an application does not have a code signature or why it has an invalid code signature. This is by no means an exhaustive list and only represents what we encountered ourselves, or what our users reported.

If the application does not have a code signature (see Applications without a code signature):

The developer of the application did not sign it.
The developer of the application did sign it, but somehow the signature was removed (possibly for malicious reasons).

If the application has an invalid code signature:

The developer of the application made an error while building or distributing the application (see Applications with an invalid code signature).
The application loads a dynamic library or a plug-in that has an invalid code signature (see Applications with a valid code signature that is broken).
The application was modified either in memory while it’s running, or on disk before it was launched (possibly for malicious reasons).

What you can do when Little Snitch reports a code signature issue

The first thing you should try is to download the application directly from its developer again and re-install it, then try again. If Little Snitch created a special code signature issue override rule, you’ll have to delete that rule (or edit it to not deny any connection) before connections can be allowed. If Little Snitch still reports the same issue, contact the app’s developer about the issue. They may have to fix this on their end.

Of course, you can still use Little Snitch with an application that has no valid code signature. The only thing you have to do is tell Little Snitch that it should ignore the code signature for that particular application. You can do so by creating an allow rule for the application in Little Snitch Configuration that has Require valid code signature unchecked. (This checkbox is disabled anyway if the application does not have a code signature.)

Note that it does not matter whether this rule allows any connection or only specific connections. As soon as a single allow rule that does not require a valid code signature exists, Little Snitch will completely ignore the code signature for that application. Please keep in mind that this means that these rules will continue to work even if the application is modified in the future, which is a security risk.

Will there be an updated version of Little Snitch that is compatible?Yes. Mac little snitch competitive upgrade program.

Independently verifying code signature issues reported by Little Snitch

This section is intended for users who are comfortable in using Terminal commands.

From our experience in tech support, users and especially developers of other applications do not believe what Little Snitch reports about code signatures. We suspect that this is because most users and developers only ever come in contact with a static code signature, which is the code signature created during the build process and written to the application bundle (or executable) on disk.

Most problems that Little Snitch reports concern the dynamic code signature, though, which is the code signature that the running process has.

The difference is subtle: An application bundle on disk contains an executable. When that executable is launched, the operating system creates a process by loading the executable into memory. At that point, the dynamic code signature of the process is the same as the static code signature of the executable. But then dynamic libraries or plug-ins are linked into the process and if any of these dynamic libraries has no code signature or an invalid code signature, the dynamic code signature of the process is invalidated (see Applications with a valid code signature that is broken).

Applications with a broken code signature may lead to Little Snitch showing a Code Signature Alert. The confusion starts when users try to independently confirm what Little Snitch shows using the codesign command in Terminal:

… and that command reports that everything is fine. In our example, this is actually true because the above command only checks the static code signature of the application on disk. But it does not check the dynamic code signature of the running process, which is what actually matters. To check that, you can substitute the application’s path with its PID:

This command should then report an issue with the code signature of the running process.

Note that when the application on disk was replaced without the process being restarted (see Applications that update themselves without restarting), the last command will correctly report that “the code on disk does not match what is running”.

A warning about the codesign command’s options

Please note that on many internet forums you can find an invalid combination of options passed to codesign that do not what you’d expect. You can often find instructions that codesign -dv can be used to display (-d for --display) and verify (-v for --verify) the code signature at the same time. But as the man page of the command states, -v is interpreted as --verbose if another option like --display is passed. Therefore, codesign -dv does not mean codesign --display --verify, but instead it simply means codesign --display --verbose and therefore does not verify anything – it just shows information about the code signature.