Catalina is checking notarization of unsigned executables

There is so much confusion here. The OP and most others are missing one of the biggest points: Look at the packet trace. There is _no data_, not even a hash, being sent. It's a TLS negotiation and then the connection ends. I have to suspect it's a bug...

In prior article "slow by design", this was reported to Apple and the bug was closed that it works like that by design.

I did see the previous article (another comment of mine should be easy to find on its HN post). Do you know how to find the issue that was referenced? There was an ID given but I have no clue what tracker that was on.

It's probably Radar, which is Apple's internal issue tracker, which isn't public (you can see issues you submitted, but nothing else). Sometimes people cross-post issues they submit to http://openradar.appspot.com, so you might be able to find it there.

That ID was likely for feedbackassistant.apple.com. However, those reports are not public, so you can't see them unless you're the one that reported them though. Knowing the ID is still useful for things like emailing Apple people and complaining about their declining software quality ;).

Is the handshake all that is needed to verify? Is the data you're expecting sent during the authentication phase of the handshake?

The Objective-C format strings in the URL would imply that the hash is sent as a path parameter.

That's a string found in the disassembly of syspolicyd (I've found it as well). However, the actual URL you see in the TCP logs has no path whatsoever.

The issue is FB7674490 but it is not on the OpenRadar. Looks like OpenRadar is not Apple's services and issues appear there only if author (which has access to the issue in the Apple system) submits them there.

I'm not sure what you're seeing, but that's not what I'm seeing. When I Wireshark both app notarization and script notarization, I see 2 packets of encrypted Application Data sent to Apple (567 and 101 bytes), and 1 packet of Application Data (varying length) returned from Apple, in each case. What do you see when you trace a regular app notarization check?

Looks like these issues are only visible to originator, so we have to trust the author about it. Perhaps the author could post it on the OpenRadar.

This is odd, my proxy doesn't seem to show this. I will try to load my root cert into Wireshark and check.

Edit: Checked and double checked: When I run a new shell script, syspolicyd just makes a connection with no application data

Any communication is data! There are tracking pixels that return 404! Why? Because once you've hit their endpoint, it did the job.

The TLS negotiation is enough to send quite enough info.

I'd recommend trying this: Download a notarized Mac app, delete any stapled notarization ticket (.app/Contents/CodeResources), and then trace the launch. What do you see, and does the system let you open the app? Does it say it checked for malware?

Ah I see, looks like we're not running quite the same experiment. I suspect that anything including an app bundle ID is going to see some more interesting traffic.

Don't suspect, test. ;-)

I'm running both experiments. I've tested and compared script notarization to app notarization.

You're getting apparently unusual results with script notarization. So the natural next step would be to compare against app notarization.

Open Radar is community maintained and fairly poorly at that these days :(

FB numbers come from Feedback Assistant, which are similarly non-public and feed into Radar through a convoluted process.

Agh, I think it was cert pinning. Looks like the connection is terminated if you're snooping. I see the same results as you now. Thanks!

"no data", just a TLS handshake. Of course information can flow! You could put a hash of the executable in a ClientHello extension, and if the server says "i don't know it to be malware" it can finalize the TLS connection normally.

I have a feeling that there is already a system out there which does something like that.