Server Zertifikat Information auslesen (z.B Ablaufdatum)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Server Zertifikat Information auslesen (z.B Ablaufdatum)

    Hallo zusammen,

    und zwar wollte ich Fragen, wie ich die Information des Zertifikats, dass ich von einem Server bekomme

    mittels

    - (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;

    auslesen kann.

    Gibt es nur diese Möglichkeit über openssl:

    stackoverflow.com/questions/88…e-certificate-information


    Das Ablaufdatum,Firma usw.

    Beste Grüsse
    g4ul1x

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von g4ul1x ()

  • Ich kenn' nix anderes. Vor allem kann das Security-Framework unter iOS nicht alles das, was auch unter OS X geht. Und, nebenbei bemerkt, auch unter OS X ist das Security-Framework ein großer Scheiß: Bugs ohne Ende, furchtbares API, manche grundlegenden Aufgaben sind schlicht und einfach nicht lösbar. Dann doch lieber gleich openSSL. Da gibt's zwar auch ein schlechtes API und Bugs, allerdings werden die wenigstens gefixt und am Ende kann ich zumindest die Sachen machen, die ich machen muß.

    ciao

    gandhi
  • Soweit ich den Zertikatsscheiß verstanden habe (und aus dem GPG Thread kann man erkennen, dass das nicht allzu weit ist), sollte die Einstufung der Zertifikatsinformationen doch eigentlich dem User überlassen werden.

    Eigentlich (so meine Einstellung zum Thema) geht es Deine App doch überhaupt nichts an, wer wann warum wie welches Zertifikat erstellt hat, wie lange es gültig ist und so weiter.

    Entweder das Ding ist von einer dem System bekannten Root-CA Stelle signiert, die Hostnamen passen zusammen und das Ding ist noch nicht abgelaufen – sprich: das Zertifikat ist im Sinne von SSL gültig. Oder eben nicht.

    Deine App hat sich nicht um das Ablaufdatum des Zertifikats zu kümmern. Das sollte der Zertifikatherausgeber im Auge haben.

    Wenn jetzt der Hostname nicht passt, beispielsweise weil example.com eine Weiterleitung auf einen Server *.well-known-isp.co.uk ist; wenn das Zertifikat bereits seit 8 Jahren abgelaufen ist; wenn das System das Root-CA von 'Gretchen Müller Automobile' nicht vertraut; wenn die Prüfsummen oder Hashes nicht stimmen – wann immer das Zertifikat aus Systemsicht nicht zu 100% vertrauenswürdig ist, dann muss der Nutzer entscheiden, wie damit zu verfahren ist.

    Die Anwendung geht das alles doch eigentlich überhaupt nichts an.
    Es sei denn, man heißt Gretchen Müller und möchte in der App zum Automobilhandel unbedingt entgegen aller Systemeinstellungen diesem einen eigenen Zertifikat vertrauen.

    Nur: das führt ja das ganze Prinzip erst so richtig ad absurdum.

    Nicht Du, nicht Deine App soll irgend einer via Zertifikat gesicherten Seite vertrauen. Der User soll das gefälligst tun.

    Also: wofür benötigst Du die Informationen über das Serverzertifikat?
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Marco Feltmann schrieb:


    Also: wofür benötigst Du die Informationen über das Serverzertifikat?

    Stell dir vor du schickst einen Mitarbeiter in einen Schurkenstaat, egal ob west oder Ost oder nur in den Nachbarort.
    Der verbindet sich dann mit dem Firmenserver um Geschäftsgeheimnisse anzusehen. Das Serverzertifikat ist dann aber von einer anderen CA signiert.
    Willst du dem Mitarbeiter dann einen Alert ala "Falsche CA | Weiter | Abbrechen" anzeigen? Oder doch lieber keine Verbindung aufbauen?

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.
  • Der Mitarbeiter bekommt einen Alert ala "Falsche CA | Weiter | Abbrechen".
    Vielleicht noch besser: ein Alert ala "Falsche CA. Key Account Manager informieren! Keine Verbindung!"
    Wenn ich mich nicht vollkommen irre, kann man abfragen, ob das Zertifikat gültig ist (also ohne Details) und dementsprechend die Verbindung einfach unterlassen.

    Der Mitarbeiter ist ganz sicher gebrieft, dass er sich in einem Schurkenstaat aufhält.
    Er wird also auf 'Abbrechen' tippen, sein sicherlich abgehörtes Mobiltelefon schnappen, den Key Account Manager für den Schurkenstaat anrufen, ihm den Umstand mitteilen und auf weitere Anweisungen warten.

    Immer noch besser als ohne Kommentar keine Verbindung aufzubauen, was dann dazu führt, dass der Mitarbeiter nach mehreren vergeblichen Versuchen das Ganze allein zu lösen (vermutlich mittlerweile mit Pistolenlauf im Genick) die IT anruft und auf eine Problembehebung per Telefon besteht.

    Wie nannte @kmr das in seinem Macoun Vortrag noch gleich?
    Nein, nicht PAL (Problem Anderer Leute).
    Eher die Pflicht zum Selber Nachdenken.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Marco Feltmann ()

  • Seufz. Wenn Ihr doch alle mal vorne anfangen und Euch erstmal über die Bedrohungen und erst dann über die Maßnahmen Gedanken machen würdet. ;) Aus den Bedrohungen ergeben sich dann die Maßnahmen.

    Certificate Pinning kann sinnvoll sein. Kann aber auch Unfug sein. Kommt eben auf die Bedrohung an. ^^

    Lesen.
  • Marco Feltmann schrieb:


    Wie nannte @kmr das in seinem Macoun Vortrag noch gleich?
    Nein, nicht PAL (Problem Anderer Leute).
    Eher die Pflicht zum Selber Nachdenken.


    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :P

    Vorträge anhören ohne sich vorzustellen ist übrigens unhöflich. 8)
  • kmr schrieb:

    Wenn Ihr doch alle mal vorne anfangen und Euch erstmal über die Bedrohungen und erst dann über die Maßnahmen Gedanken machen würdet. ;)

    Also ich ging davon aus, dass die Nutzung des Server Zertifikats die Maßnahme ist, die aus den Gedanken zur Bedrohung resultierte. :P
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • kmr schrieb:

    leichtgläubiger Zeitgenosse

    Das erklärt, wie ich zu der Annahme kam. ;)

    kmr schrieb:

    Vorträge anhören ohne sich vorzustellen ist übrigens unhöflich.

    Was, damit Du mich bei Deinen Vorträgen so volllappen kannst wie den armen Pepi? Nee, lass man. :P
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • macmoonshine schrieb:

    kmr schrieb:

    Vorträge anhören ohne sich vorzustellen ist übrigens unhöflich.

    +korrekt+

    Gut, werde ich berücksichtigen, wenn ich mir einen Vortrag von Dir anhöre.
    Reichen die Live-Vorträge, oder muss das auch beim (hoffentlich irgendwann existierendem) Podcast ansehen sein? :P
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Ich brauche die Informationen für das Ablaufdatum. Damit ich sehen kann, ob das Zertifikat abgelaufen ist? Oder gibt es eine andere Möglichkeit das zu überprüfen?

    Also das was zur Zeit passiert ist folgendes:

    Ich connecte zu einem Server, der schickt mir ein Zertifikat. Ich habe im Moment keine Zertifikatsüberprüfung und schicke dann die Client-Credentials sofort zum Server(Client-Authentifizierung). Das Zertifikat ist aber abgelaufen. Ich sollte das überprüfen und wenn das der Fall ist, dann sollte die Verbindung unterbrochen werden und es sollten nicht die Credentials versendet werden.

    Meine Frage wäre, es reicht doch nicht nur das Ablaufdatum auszulesen. Wie kann ich sicher sein, dass ausser dem Ablaufdatum auch das Zertifikat das richtige ist. Gibt es da Möglichkeiten ohne einen Fingerprint oder das Zertifikat selber in der App zu haben. Das hätte nämlich den Nachteil, dass immer wenn das Zertifikat abläuft ich einen neue Version liefern muss.

    Ändert sich der Fingerprint bei einer Verlängerung des Zertifikats?

    Beste Grüsse
    g4ul1x

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von g4ul1x ()

  • g4ul1x schrieb:

    Ich brauche die Informationen für das Ablaufdatum. Damit ich sehen kann, ob das Zertifikat abgelaufen ist? Oder gibt es eine andere Möglichkeit das zu überprüfen?


    Erm … wenn das Zertifikat abgelaufen ist, wird Dir iOS das schon sagen. Dann ist es nämlich nicht mehr gültig, und das Betriebssystem erkennt es nicht mehr als gültiges Zertifikat an (was für ein Satz!). Das ist nichts, was Du zu Fuß machen musst.
  • Wie stell ihr euch die Vorstellung denn vor?
    Der Künstler und der Andere stehen am Eingang, begrüßen jeden mit Handschlag, lassen sich den Lebenslauf und sexuelle Vorlieben erzählen und nach ein bisschen Smalltalk über Wetter und Hobbys ist dann der nächste dran?
    Alternativ könnten die Mikrofonmiezen zu jedem gehen.
    Bleibt dann noch Zeit für einen Vortrag oder ist das dann der einzige am Tag?

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.