Larry: Garantie für Serverzertifikate? Beispiel x509

Hallo,

ich verstehe das Garantie bzw. Sicherheitskonzept bei einem Serverzertifikat nicht so ganz.
Soweit ich es beispielsweise nach dem x.509 Zertifizierungsstandard,und dessen ASN1 Sprachspezifikation verstanden habe werden z.B
der Firmenname und weitere Infos,sowie der publickey in einem Zertifikat abgelegt.
Zusätzlich wird ein Hashwert der als Fingerprint dienen soll,dafür sorgen das publickey und Firmendaten nicht manipuliert wurden,dem Zertifikat hinzugefügt.
Aber es besteht doch durchaus die Möglichkeit einen Server zu faken,auf dem dann ein eigenes Keypair,und ein eigener gebildeter
Hashwert die Zertifikatsdaten ersetzt,bzw. ein eigenes Zertifikat erstellt werden kann.
Also wo ist die Garantie für ein authentisches Zertifikat,welche Funktionalität soll denn auf Clientseite ein Zertifikat prüfen?
Der Client kann doch nur den im Zertifikat enthaltenen publickey zur Datenverschlüsselung verwenden,aber nicht wirklich prüfen ob ein Zertifikat authentisch ist.

Also wo ist mein Denkfehler,in der Funktionsweise oder der Idee von Zertifikaten???

Vielen Dank

Larry

  1. Hallo,
    der "Denkfehler" besteht darin, dass Zertifikate von autorisierten Stellen wie Verisign, Thawte... von allen Browsern automatisch erkannt werden, gefakte oder selbstgemachte (was ja durchaus zulässig ist) müssen jedoch jedesmal bestätigt werden.
    Im übrigen ist ein Zertifikat nichts anderes als ein "Pickerl", dem man vertrauen kann oder auch nicht.
    Gruss
    Christian

    1. Hallo,

      [...] müssen jedoch jedesmal bestätigt werden.

      es sei denn, Du importierst das Zert. einmal und belegst es damit als sicher für Deinen Browser.

      Reiner

      1. Danke erstmal
        also nur Browser können trusts wie Thawton oder verisign usw. erkennen anhand der Zertifikate,OK.Aber wie sieht es mit Client Server verbindungen aus,die nunmal keine Browser verwenden,und OpenSSL z.B oder auch upik toolkits werden ja auch für Software angewandt,die keine Browser verwenden.

        Wobei auch bei den Browsern ist mir nicht ganz klar,wie sie erkennen wollen ob dieses Trust was dahinter steckt wirklich authentisch ist,schliesslich gibt es genügend Opensource toolkits,da kann man sich die Routinen ja prima anschauen.

        Und wenn der Algorithmus für den asymetrisch verschlüsselten hashvalue nur den Zertifizierungsstellen bekannt ist,wie in aller Welt weiss dann der Browser ob das Zertifikat sicher ist???
        Also irgendwie werde ich nicht wirklich schlau aus diesem Securitykonzept.
        Selbst bei www.logosec.de werde ich nicht schlau,und da wird eigentlich schon alles ziemlich gut erklärt,aber momentan hab ich das Gefühl,dass das ganze CA konzept nur oberflächlich erklärt wird,aber wie es wirklich funktioniert,finde ich nirgendwo.

        1. Hallo Larry

          Das Zertifikat wird von einer solchen Zertifizierungsstelle mit deren Privatkey signiert.
          Ein Programm, dass überprüfen will, ob das Zertifikat gültig ist, überprüft mit dem Public Key der Zertifizierungsstelle die Signatur.

          Grüße

          Daniel

          1. Hallo Larry

            Das Zertifikat wird von einer solchen Zertifizierungsstelle mit deren Privatkey signiert.
            Ein Programm, dass überprüfen will, ob das Zertifikat gültig ist, überprüft mit dem Public Key der Zertifizierungsstelle die Signatur.

            Grüße

            Daniel

            Danke,aber was mir nicht einleuchten will,wenn jemand einen server faked,dann signiert er doch mit seinem privatekey,und somit macht es doch für den client den Anschein das alles in Ordnung ist,weil der faker sich ja ein eigenes keypair generiert hat.
            Deshalb verstehe ich nicht,wie der Client sich da so sicher sein kann,ob ein Zertifikat wirklich authentisch ist.

            1. Hi Larry

              Er signiert es mit seinem eigenen Key. Das bringt gar nichts, weil ein Browser und andere Anwendungen selbst unterschriebene Zertifikate nicht ohne weiteres akzeptieren.

              Grüße

              Daniel

              1. Hi Larry

                Er signiert es mit seinem eigenen Key. Das bringt gar nichts, weil ein Browser und andere Anwendungen selbst unterschriebene Zertifikate nicht ohne weiteres akzeptieren.

                Grüße

                Daniel

                Erstmal vielen Dank für Eure Geduld.:)
                Wenn ich das nicht langsam verstehe,setze ich mich zur Ruhe als Entwickler,und werde Gärtner.Oder sollte ich einfach mal wieder schlafen.*g*

                Also,was ich irgendwie nicht kapieren will,ist die Tatsache dass man
                sich doch Zertifikate anschauen kann,und sie auch editieren kann,im Hexeditor oder sonst wo.

                Beispiel:
                Server wird gefaked,und es wird ein EIGENES Schlüsselpaar á la RSA generiert,privatekey bleibt beim server,und der public key wird in zusammengebasteltes Zertifikat gepackt,ein EIGENER Hashvalue wird erzeugt.
                Dann ist dies doch ein erschummeltes Zertifikat.
                Jetzt hat der Client doch ein Zertifikat vor sich,und es erfüllt die Bedingungen.Woher weiss der Client jetzt das dies eine Fälschung ist?
                Es hat doch alles was er brauch vom gefaketen,um damit zu arbeiten.
                Er hat einen public key usw.

                1.Oder kennt der Client etwa schon im Voraus,alle offiziell aktuellen Signaturen aller oder der meisten CAs,um sie auf Gültigkeit zu überprüfen???

                2.Demnach haben die binaries der Browser schon längst Informationen über aktuelle CA signaturen?

                3.Das bedeutet,wenn man ClientServer applikationen schreibt,dass der Administrator der Kunden,die die Serverapplikation verwenden dafür sorgen muss,dass die clients stets informiert sind,über alle gültigen Signaturen,so dass die Clientsoftware die Zertifikate anerkennen kann.

                Danke

                Larry

                1. Hallo,

                  Server wird gefaked,und es wird ein EIGENES Schlüsselpaar á la RSA generiert,privatekey bleibt beim server,und der public key wird in zusammengebasteltes Zertifikat gepackt,ein EIGENER Hashvalue wird erzeugt.
                  Dann ist dies doch ein erschummeltes Zertifikat.

                  Nochmals, es ist nicht geschummelt, sondern nur nicht von einem offizellen CA. Sagen wir mal es ist wie ein Firmenausweis.

                  Jetzt hat der Client doch ein Zertifikat vor sich,und es erfüllt die Bedingungen.Woher weiss der Client jetzt das dies eine Fälschung ist?

                  Der Client wieß jetzt einmal nur, daß sich der Server ausweisen kann. Allerdings eben mit einem 'Firmenausweis'.
                  Würde er ein von einem offizellen CA ausgestelltes Zertifikat haben, dann entspräche ev. das einem Pass. Auch das ist ein 'Ausweis', allerdings von einer anerkannt 'zuverlässigen' Stelle (staatliche Behörde) ausgestellt.
                  Wenn Du Dir nicht sicher bist, ob der Ausweis nicht gefälscht ist, kannst Du ja immer bei der ausstellenden Stelle nachfragen. Also beim Firmenausweis bei der entsprechenden Firma, bzw. beim Pass bei der ausstellenden Behörde.
                  Genau das macht der Client grundsätzlich. Er empfängt das Zertifikat, sieht nach, wer der Aussteller ist, und fragt nach. Falls der Aussteller (CA) dieses Zertifikat nihct bestätigen kann, gilt es beim Client als unsicher.
                  Bei den selbst generierten Zertifikaten gibts aber keinen Aussteller, gilt das Zertifikat ebenfalls als unsicher.

                  Dies teilt der Client, sofern er nicht Schrott ist, dem Benutzer dann mit.

                  Du solltest aber bedenken, daß ein Zertifikat bei SSL zwei Aufgaben erfüllt.

                  1.) Es dient zum Schlüsselaustausch für die Übertragung verschlüsselter Daten. Diese Punkt kann erfüllt werden, egal ob das Zertifikat bestätigt wurde oder nicht.

                  2.) Es dient zur Authentifizierung des Servers. Nur dann gilt das Zertifikat auch als sicher.

                  1.Oder kennt der Client etwa schon im Voraus,alle offiziell aktuellen Signaturen aller oder der meisten CAs,um sie auf Gültigkeit zu überprüfen???

                  Alle wird der Client nicht kennen, bei den Browsern sind aber einige wichtige CA's schon eingetragen.

                  2.Demnach haben die binaries der Browser schon längst Informationen über aktuelle CA signaturen?

                  Ja.

                  3.Das bedeutet,wenn man ClientServer applikationen schreibt,dass der Administrator der Kunden,die die Serverapplikation verwenden dafür sorgen muss,dass die clients stets informiert sind,über alle gültigen Signaturen,so dass die Clientsoftware die Zertifikate anerkennen kann.

                  Zumindest über die Signatur des ausstellenden CA's, so daß dieser ein eventuell verwendetes Zertifikat bestätigen kann.

                  Grüße
                    Klaus

                  1. Vielen Dank Klaus,der Groschen ist gefallen.:)

            2. Hallo,

              Danke,aber was mir nicht einleuchten will,wenn jemand einen server faked,dann signiert er doch mit seinem privatekey,und somit macht es doch für den client den Anschein das alles in Ordnung ist,weil der faker sich ja ein eigenes keypair generiert hat.

              Ein selbst erzeugter Schlüssel kann nur dazu dienen, daß die verschlüsselte Übertragung erfolgreich sein kann. Eine validierung des Schlüssels ist damit nicht gegeben.

              Deshalb verstehe ich nicht,wie der Client sich da so sicher sein kann,ob ein Zertifikat wirklich authentisch ist.

              Ist er auch nicht, weil es keine offiziell anerkannte Authorität (CA) bestätigen kann. Das wird auch entsprechend angezeigt.
              Ein Schlüssel wird vom Client eben nur als sicher erachtet, wenn er von solch einem CA authentifiziert werden kann.
              Will jemand als CA auftreten, so muß dies ebenfalls durch einen Schlüssel erfolgen, der wiederum von einer bereits anerkannten Stelle authentifiziert werden muß, und so weiter und so fort.

              Grüße
                Klaus