Ocsp.pki.goog and associated malware

iOS / iPadOS devices cannot be infected** with Viruses / Malware / Spyware unless you have intentionally downloaded spurious software or unauthorized apps directly from the internet and installed them on your device or/and have Jailbroken. 

**The primary reason for this is Sandboxing. All third-party apps are “sandboxed”, so they are restricted from accessing files stored by other apps or from making changes to the device. Sandboxing is designed to prevent apps from gathering or modifying information stored by other apps.

Security of runtime process in iOS and iPadOS - Apple Support

The sandbox on an iPhone is a security feature that creates a restricted environment for each app to run in isolation from other apps and the operating system. It is a core component of iOS's security architecture and plays a crucial role in making iPhones more secure.

In layman's terms:

The sandbox works by enforcing strict controls and limitations on app behavior, ensuring that each app has access only to the resources it needs to function properly. Here are some key aspects of the sandbox that contribute to iPhone security:

1. Isolation: Each app on an iPhone operates within its own sandboxed environment, which means it has no direct access to the files, processes, or memory of other apps. This isolation prevents apps from interfering with one another, protecting user data and maintaining system stability.
2. Restricted Resource Access: The sandbox restricts an app's access to sensitive resources such as contacts, photos, location data, and system settings. Apps must explicitly request user permission to access these resources, and users have control over granting or denying access. This helps prevent unauthorized data access and ensures user privacy.
3. Limited File System Access: Apps can only access their own containerized storage area and specific system-provided directories. They cannot modify files outside of their designated areas or interfere with the operating system files. This prevents apps from tampering with critical system components.
4. Code Execution Controls: The sandbox enforces restrictions on code execution, preventing apps from running arbitrary code or injecting malicious code into other apps or the system. It helps ensure that apps only execute approved code from their own sandboxed environment.
5. App Review Process: Before an app is allowed on the App Store, it goes through a rigorous review process conducted by Apple. This review examines the app's functionality, security, and adherence to guidelines. It helps detect and remove malicious or poorly designed apps, minimizing the risk to users.

The combination of these sandboxing mechanisms helps create a secure environment on iPhones, protecting user data, maintaining system integrity, and preventing unauthorized access or interference between apps.

User to user support forum.

What you are posting is not going to be understood by average user here.

Im not really sure why you are posting this here instead of a professional security research site.

I have plenty of information.

And they do not need for your device to say it's jailbroken. In fact while my phone, iPad, and computer were infected I got them repaired (still could be tbh) at apple many times and never did they report to me my devices had already been jailbroken.

As sited on reddit:

what is domain ocsp.pki.goog 

Hi

I recently running SIMBA JDBC BigQuery Driver inside GKE Private Cluster and came to see an error saying  http://ocsp.pki.goog is not reachable. Upon seeing JAVA options we found ssl.revocation option was set to true meaning it was trying to check BQ cert revocation check also called OCSP and because route to this domain was blocked we got error.

This made be think that is any call to google api from GCLOUD and Client libraries does this check behind the scene as i never knew about check though we use lot of BQ connections from Python Client Lib and using GCLOUD. This is the first time i came to know this error from GKE private cluster.

n general, any software that connects to a TLS endpoint should (although, may not [1]) verify the validity of a certificate by checking OCSP or CRL status. These are additional checks to ensure certificates are not only valid and chain up to a trusted root, but that they haven't been revoked and can be trusted. Certificate Authorities will revoke certificates if they believe there is a good reason, such as in a key compromise, or duringroutine key rotation. If your TLS client is unable to validate the CRL or OCSP status of a certificate, it may decide to "fail open" and continue, or "fail close" and not allow the connection, which could lead to all kinds of unusual problems. It's best to make sure the CRL and OCSP network connections can be made to work (i.e. DNS lookups are allowed and network firewalls allow the connection) or disable the revocation checking all together if that isn't possible.

[1] https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.2

Though I wouldn't go out of my way to click on anything these guys offer up. <3 These are my hackers