• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Wer ist »ocspd« und was will der auf Port 80?

stk

Grünapfel
Registriert
05.01.04
Beiträge
7.141
Moin,

seit einigen Tagen springt bei mir mehr oder minder regelmässig einmal am Tag LittleSnitch hoch und verkündet:

»oscpd want's to connect to 12.166.243.30 on TCP Port 80«

Rufe ich die IP im Browser auf bekomme ich eine Datei mit einer »0« drin geliefert. Ansonsten keine Hinweise wer oder was hinter der IP steckt. »ocspd« ist ein Systemjob (root:wheel) der launchd als übergeordneten Prozess in der Aktivitätsanzeige ausweist, aber ich habe nicht die leiseste Ahnung was der tut, ob er tun soll und ob er dabei auch eine Internetverbindung braucht. Google liefert mir nur irgendwas im Kontext von OpenCA, was mich aber genauso wenig schlau macht.

Vielleicht kann mir hier einer auf die Strümpfe helfen.

Gruß Stefan
 

LaK

Reinette Coulon
Registriert
30.03.05
Beiträge
952
hey aber immerhin danke für deine IP ;)

Port 80 ist ja eigentlich für HTTP wenn ich mich nicht täusche.
 

ricobeck

Gast
ich schätze mal grob:
es ist ein programm, das auf port 80 (der normale http-port) nach
einem update sucht. wenn man die ip 12.166.243.30 im browser
eingibt, erhalt man eine antwort aus 5bytes, deren erstes 0 ist:

0=false; keine neue version vorhanden.

also wenn ich richtig liege: keine gefahr.
 

Rusty

Gast
VeriSign Infrastructure & Operations VERISIGN166-243

Cheers Rusty
 

Nick

Rheinischer Krummstiel
Registriert
26.02.05
Beiträge
387
Ein Tool, dass Zertifizierungen überprüft!?
 

stk

Grünapfel
Registriert
05.01.04
Beiträge
7.141
Moin,

also - das Port 80 für den "gemeinen" Internetzugriff zuständig ist, war schon klar. Daher ja auch mein Test mit dem Browser, da ich mir sicher sein konnte das der eine brauchbare Antwort erhalten würde.

Nachdem ich den "until quit"-deny von LittleSnitch durch einen permanenten deny ersetzt hatte, kam prompt noch eine andere IP hoch, die sich per DNS auf einen VeriSign-Server auflöste. Also die Idee mit Authentifizierungsüberprüfung scheint mir auch die naheliegendeste Erklärung zu sein.

Bleibt mir nur die Frage, wie der Daemon auf mein Book kommt. Möglicherweise durch den Einsatz eines LDAP-Useraccounts auf OS X Server!?

Gruß Stefan
 

Rusty

Gast
Hmmmmmmm? Warum schreit niemand? DAS THEMA IST DOCH INTERESSANT? TIPP DOCH mal "Verisign Daemon" in google ein.......
 

maelcum

Jonathan
Registriert
03.10.08
Beiträge
82
Hi,

ich weiss, der Thread ist alt, aber vielleicht sucht ja nochmals jemand nach "ocspd" und stösst hier drauf, daher hier die kurze Ergänzung:

man ocspd erklärt eigentlich alles:
DESCRIPTION
ocspd performs caching and network fetching of Certificate Revocation Lists (CRLs)
and Online Certificate Status Protocol (OCSP) responses. It is used by Secu-
rity.framework during certificate verification. Security.framework communicates with
ocspd via a private RPC interface. When Security.framework determines that a CRL is
needed, or that it needs to perform an OCSP transaction, it performs an RPC to ocspd
which then examines its cache to see if the appropriate CRL or OCSP response exists
and is still valid. If so, that entity is returned to Security.framework. If no entry
is found in cache, ocspd obtains it from the network, saving the result in cache
before returning it to Security.framework.

In deutschen Worten:
ocspd verifiziert auf Anforderung des Security.frameworks ein Zertifikat. Diese Zertifikate sind i.d.R. im Schlüsselbund hinterlegt und werden von einer Applikation verwendet, um eine Verbindung zu irgendeinem Dienst im Internet aufzubauen.

Beispiel:
Bei mir erscheint die Meldung zum Bleistift immer dann, wenn Mail bei Gmail und MobileMe/.Mac nachfragt, ob schon Mails eingegangen sind. Beide Dienste verwenden Zertifikate, in diesem Fall SSL/TLS. Wenn Mail also eine Verbindung zu Gmail aufbauen will, und dafür das Zertifikat aus dem Schlüsselbund abruft, rennt eben noch schnell ocspd los und checkt, ob das Zertifikat noch gültig ist. Könnte ja sein, dass Gmail kompromittiert wurde und dann möchte ich gerne erst mal ne Warnung, bevor Daten ausgetauscht werden.

In einfachsten Worten: Lasst den Dienst gewähren, er tut nur nützliches.
 
  • Like
Reaktionen: thrillseeker

wolfsbein

Jerseymac
Registriert
29.06.05
Beiträge
448
Ein klassiches Beispiel wie PersonalFirewalls versagen. Um mal unseren Sicherheitsmenschen zu zitieren:
Benutzer berichten stolz, dass ihre Personal
Firewall Spyware daran gehindert hat, auf
crl.verisign.com zuzugreifen.
 

valen

Erdapfel
Registriert
14.11.08
Beiträge
2
In deutschen Worten:
ocspd verifiziert auf Anforderung des Security.frameworks ein Zertifikat. Diese Zertifikate sind i.d.R. im Schlüsselbund hinterlegt und werden von einer Applikation verwendet, um eine Verbindung zu irgendeinem Dienst im Internet aufzubauen.

Genau, das Ganze hat mit Zertifikaten und PKI (Public Key Infrastructure) zu tun.

Zertifikate dienen als elektronischer "Ausweis" für die verschiedensten Dinge (für SSL zwischen Server und Browser, zu Authentisierungszwecken an Diensteplattformen, zum Signieren von E-Mails etc.).

So ein Zertifikat beinhaltet Informationen über den Aussteller des Zertifikats, Informationen über den Inhaber des Zertifikats, Angaben zur Gültigkeit des Zertifikats und noch ne Menge andere Dinge (sogenannte Extensions/Erweiterungen).

Wenn nun im von maelcum genannten Beispiel der signierten E-Mails der Mailclient diese Signatur vorfindet, passiert folgendes:

1. Der Mailclient prüft, ob die Signatur mathematisch korrekt ist.
2. Das in der Signatur enthaltene Zertifikat wird überprüft.
2a. Mathematische Prüfung des Zertifikats
2b. Prüfung der Zertifikatskette unter Zuhilfenahme des Zertifikatsspeichers im Betriebssystem/in der Anwendung
2.c Überprüfung des Sperrstatus des Zertifikats (geht nur bei Onlineverbindungen).

Beim Punkt 2c. kommt dann der ocspd ins Spiel.

--

Welche Möglichkeiten der Statusprüfung gibt es?

1. Sperrlistenprüfung (CertificateRevocationList - cRL)
Eine Sperrliste enthält eine Aufzählung von Zertifikatsseriennnummern und den dazugehörigen Sperrzeitpunkten und optional anzugebenen Sperrgründen. Wie man an diese Sperrlisten kommt (also die URL für den Download) findet man im Allgemeinen in einer Zertifikatsextension mit dem Namen "crlDistributionPoint".

Gängige Wege der Beschaffung sind über http (Port 80) oder über das ldap-Protokoll (meist Port 389). Die genaue URL ist aber wie gesagt in der Extension zufinden.

Der Vorteil einer cRL ist, dass man eine Struktur hat, welche man einfach parsen kann und diese Struktur enthält mehr als einen Sperreintrag. Der Nachteil ist, dass so eine cRL sehr gross werden kann und damit mehr als unhandlich wird.

2. OCSP (Online Certificate Status Protocol )
Wie es der Name schon sagt, ist dies ein eigenes Protokoll zur Statusabfrage. Bei der Abfrage wird das ausstellende CA-Zertifikat und die zu überprüfende Zertifikatsseriennnummer übergeben.
Als Antwort erhält man keine Datenstruktur im Sinne einer cRL sondern eine siognierte Antwort, die verschiedene Auskünfte gibt.
Mögliche Antworten sind:
- gültig
- gesperrt inkl. Sperrdatum und optionalem Sperrgrund
- unbekannt

Der Vorteil dieses Protokolls ist, dass die Antworten immer sehr klein bleiben und nicht ins Uferlose wie bei cRLs wachsen.

Der Nachteil ist, dass man für jedes Zertifikat eine separate Abfrage tätigen muss.

Die URL für den Zugriff auf diesen Dienst steht in einer Zertifikatsextension mit dem Namen "authorityInformationAccess".

Der Zugriff kann native erfolgen (oft der Port 9000) oder in http eingapckt, also Port 80.

Damit erklärt sich auch der Zugriff über den Port 80 im hier konkret aufgebarchten Fall.

Viele Grüße
Tom
 
  • Like
Reaktionen: fantaboy

MacAlzenau

Golden Noble
Registriert
26.12.05
Beiträge
22.501
Ein klassiches Beispiel wie PersonalFirewalls versagen. Um mal unseren Sicherheitsmenschen zu zitieren:
Benutzer berichten stolz, dass ihre Personal
Firewall Spyware daran gehindert hat, auf
crl.verisign.com zuzugreifen.

Da versagt der Benutzer, nicht die Firewall.
Soll die vielleicht selbst entscheiden, welche Zugriffe sie erlaubt und welche nicht? Vielleicht nachdem die Firewall mal selbständig gegoogelt hat, um zu schauen, worum es geht?
 

wolfsbein

Jerseymac
Registriert
29.06.05
Beiträge
448
Da versagt der Benutzer, nicht die Firewall.
..

Widerspruch? Beispiel: Windows-Rechner deiner Mutter/Vater/Oma/andere unbedarfte Nutzer. Natuerlich muss der Benutzer die Meldung interpretieren. Aber er kann es nicht.

Soll die vielleicht selbst entscheiden, welche Zugriffe sie erlaubt und welche nicht? Vielleicht nachdem die Firewall mal selbständig gegoogelt hat, um zu schauen, worum es geht?

Die Firewall soll Google fragen, ob sie etwas erlaubt? Um Himmels Willen.
 

gaffer

Schöner von Nordhausen
Registriert
20.12.06
Beiträge
322
Ist sogar jetzt, 10 Jahre später und wahrscheinlich 6 OSXe später noch interessant. Ich habe der kleinen Petze gesagt sie soll bestimmte Dienste innerhalb OCSPD blocken, nachdem diese hohe CPU Last erzeugten. Jetzt habe ich an vierzehn Stellen, u.A. hier nachgelesen was das ganze soll, weiss jetzt Bescheid und überlege, ob ich bei ungünstigen Kombinationen cRL und OCSPD die Sicherheitsprüfung deaktiviere oder die erhöhte Last ertrage... ;)