RootForum Community

Moin,

man kann sich die Zertifikate selber generieren.
man kann sich Zertifikate für 19 â?¬ kaufen. Oder 39?
man kann sich Zertifikate für 15000 $ kaufen.
man kann Zertifikate umsonst bekommen, mit Fürsprecher der bürgt! Zum Beispiel IBM, SUN ....

Das alles sind Zertifikate.

Ich meine wen interessiert das?

Wieviele Server gibt es jeden Tag neu? Sind das 1000? Davon haben 100 ein Zertifikat bzw. eine https. Davon sind 98 im "Keller" selber generiert.

Was soll das? Ist das noch Sicherheit oder nur noch Verarschung?

Schönen Tag.
Martin

Ich verschiebe mal ins OffTopic.

schröder wrote:Ich meine wen interessiert das?
Wieviele Server gibt es jeden Tag neu? Sind das 1000? Davon haben 100 ein Zertifikat bzw. eine https. Davon sind 98 im "Keller" selber generiert.
Was soll das? Ist das noch Sicherheit oder nur noch Verarschung?

Ob sie im Keller generiert sind oder nicht spielt erstmal keine Rolle die Daten werden ja trotzdem mehr oder weniger verschlüsselt übertragen.
Aber eigene Zertifikate werden vom Browser nicht als vertrauenswürdig angesehen. Je mehr ein Zertifikat kostet je mehr Browser erkennen es (Ausnahmen bestätigen die Regel ). Außerdem beinhalten die Zertifikate dann meist eine Versicherung gegen Missbrauch. Bei einer hohen Haftungsumme können 15000 $ durch aus gerechtfertigt werden.

Man sollte unterscheiden, ob ich das Zertifikat nur brauche, um zu verschlüsseln, oder ich es (auch) benötige, um die Authentizität des Servers sicherzustellen. Im zweiten Fall sollte das Zertifikat halt von jemandem ausgestellt sein, dem der Benutzer "vertrauen" kann. Ob man allerdings den großen und teuren Zertifizierern nur alleine deshalb (oder weil deren Root-CAs in den gängigen Browser als "trusted" drin sind) mehr vertrauen soll als anderen, steht auf einem ganz anderen Blatt.

Ich denke auch, das Zertifikat dient in erster Linie zum Verschlüsseln. Ok, wenn ich auf eine Seite surfe, bei dem mich der Betreiber erst darauf hinweist, daß ich das Zertifikat akzeptieren soll auch wenn es nicht vertrauenswürdig ist, kratze ich mich auch erst am Kopf. Aber ich mache es ja genauso, da für meine Zwecke ein teures Zertifikat nicht in Frage kommt, da ich meine Rooties (noch) rein privat nutze und mich "meine" User persönlich kennen.

Wenn ich mal irgendwann "fremde" User auf meine Rechner lasse, die den SSL Bereich benutzen, spätestens dann kommt für mich ein vertrauenswürdiges Zertifikat in Frage, denn wenn ich Kohle für einen Service verlange, dann muss ich auch investieren und diese lästigen Hinweise abstellen.

dodolin wrote:Man sollte unterscheiden, ob ich das Zertifikat nur brauche, um zu verschlüsseln, oder ich es (auch) benötige, um die Authentizität des Servers sicherzustellen.

Ich hätts nicht besser formulieren können. ;-)

[TOM]

Outlaw wrote:Ich denke auch, das Zertifikat dient in erster Linie zum Verschlüsseln. Ok, wenn ich auf eine Seite surfe, bei dem mich der Betreiber erst darauf hinweist, daß ich das Zertifikat akzeptieren soll auch wenn es nicht vertrauenswürdig ist, kratze ich mich auch erst am Kopf. Aber ich mache es ja genauso, da für meine Zwecke ein teures Zertifikat nicht in Frage kommt, da ich meine Rooties (noch) rein privat nutze und mich "meine" User persönlich kennen.

Dir ist aber schon klar, dass ein nicht offiziell signiertes Zertifikat anfällig für Man-in-the-middle-Attacks mit DNS-Spoofing ist?
Ein selbst signiertes Zertifikat kann sich jeder für jede beliebige Domain selbst erstellen.
Wenn ich jetzt also über DNS-Spoofing einem Rechner signalisiere ich wäre der Rechner secure.any.domain, und auf meinem Rechner ein selbstsigniertes Zertifikat für diese Domain habe, sieht das für den genau so aus, als würde er auf den "richtigen" Rechner mit selbstsignierten Zertifikat zugreifen.
Ist das Zertifikat hingegen signiert, kann man sich sicher sein, dass es sich um den richtigen Rechner handelt, sonst wäre es von der CA schließlich nicht signiert worden.

Wie ihr seht, sind also Sicherstellung der Authentizität und Verschlüsselung fest miteinander verknüpft, wenn die Authentizität nicht sichergestellt ist, ist auch die verschlüsselte Ã?bertragung nicht sicher.

Die einzige Lösung: Man kann sich eine eigene CA erstellen, mit der man dann die eigenen Zertifikate erstellt, das CA-Zertifikat muss man in diesem Fall über einen sicheren Weg auf allen Clients verteilen. Deshalb ist diese Lösung auch nur dann praktikabel, wenn man nur von bestimmten Rechnern aus zugreift (oder wollt ihr etwa immer eine Diskette mit dem CA-Zertifikat mit euch herumschleppen, damit ihr dieses ggf. erst installieren könnt, bevor ihr einen anderen Rechner als Client benutzt).

Man kann sich natürlich auch ein CA-Zertifikat von einer der offiziell anerkannten CA's ausstellen lassen, das dürfte aber ziemlich teuer werden...

Wie ihr seht, sind also Sicherstellung der Authentizität und Verschlüsselung fest miteinander verknüpft, wenn die Authentizität nicht sichergestellt ist, ist auch die verschlüsselte Ã?bertragung nicht sicher.

Das sehe ich anders bzw. es kommt darauf an, wie du dein letztes "sicher" definierst. Die Ã?bertragung ist auf jeden Fall verschlüsselt und in sofern "sicher" z.B. vor fremden Mitlauschern. Selbstverfreilich kann mit einem selfsigned Zertifikat die Authentizität nicht sichergestellt werden, aber das sind für mich 2 völlig verschiedene paar Stiefel und daher unterscheide ich sehr wohl zwischen Verschlüsselung und Authententifizierung.

dodolin wrote:

Wie ihr seht, sind also Sicherstellung der Authentizität und Verschlüsselung fest miteinander verknüpft, wenn die Authentizität nicht sichergestellt ist, ist auch die verschlüsselte Ã?bertragung nicht sicher.

Das sehe ich anders bzw. es kommt darauf an, wie du dein letztes "sicher" definierst. Die Ã?bertragung ist auf jeden Fall verschlüsselt und in sofern "sicher" z.B. vor fremden Mitlauschern. Selbstverfreilich kann mit einem selfsigned Zertifikat die Authentizität nicht sichergestellt werden, aber das sind für mich 2 völlig verschiedene paar Stiefel und daher unterscheide ich sehr wohl zwischen Verschlüsselung und Authententifizierung.

Falsch: Es könnte sich jemand dazwischenschalten, d.h. die Daten werden sicher verschlüsselt zu einem Host übertragen, der sie dann entschlüsselt, mitloggt und an den Rechner weiterleitet, mit dem du glaubst Kontakt zu haben, auf dem Rückweg das gleiche umgekehrt. Deshalb ist es wichtig sicher zu wissen, dass es sich bei dem Rechner, den ich unter der Domain erreiche, auch tatsächlich um den Rechner handelt, der in Wirklichkeit unter der Domain zu erreichen sein soll (und DNS-Spoofing ist nun wirklich kein Kunststück).

und DNS-Spoofing ist nun wirklich kein Kunststück

halte ich heutzutage für eine etwas gewagte Aussage. Das klingt bei Dir so, als wenn heutzutage jeder gefährdet wäre. Wie begründest Du das?


Gruß, Nyx

Falsch: Es könnte sich jemand dazwischenschalten, d.h. die Daten werden sicher verschlüsselt zu einem Host übertragen, der sie dann entschlüsselt, mitloggt und an den Rechner weiterleitet, mit dem du glaubst Kontakt zu haben, auf dem Rückweg das gleiche umgekehrt.

Und immer noch ist hier nur keine Authentizität vorhanden, Verschlüsselung sehr wohl. Deshalb bleibe ich weiterhin der Meinung, dass das zwei paar Stiefel sind und unterschieden werden sollte.

Wenn ich mir das obige und das

(und DNS-Spoofing ist nun wirklich kein Kunststück).

hier so durchlese, dann dürfte wohl heutzutage keiner mehr das Internet benutzen, wenn das alles so einfach wäre, wie du es darstellst. 100%ige Sicherheit wird es niemals geben, ausser mit der Kabelschere.

Ich würde jedenfalls keine zig Dollars löhnen, für so ein dolles Zertifikat, aber das muss jeder anhand seiner Anforderungen selbst entscheiden.

DNS-Spoofing ist sehr einfach: Du musst nur auf dem DNS die IP für eine bestimmte Domain ändern (dass du an den Server dran kommst, sei mal so dahin gestellt).

Allerdings kannst du dir dein selbstsigniertes Zertifikat auch für deine IP erstellen, so kannst du DNS-Spoofing ausschließen :-)

JamesB

major termi hat schon recht mit seinen überlegungen ;-)

das zertifizieren öffentlicher schlüssel durch ein "trust center" entspricht einer (serverdomain-) authentifizierung. denn ein man-in-the-middle-attack würde kein zertifikat für diesen öffentlichen schlüssel liefern können und somit erkennbar sein. das zertifikat des öffentlichen schlüssels muss natürlich auf einem sicheren weg übertragen werden ;)
allerdings wurden in letzter zeit angriffsmöglichkeiten auf das zertifikat selbst bekannt, die auf sogenanntem "cipher block chaining" beruhen und (unter umständen) serverzertifikate "umgehen" können:
http://www.openssl.org/news/secadv_20030219.txt

"back to the roots"

DNS-Spoofing ist sehr einfach: Du musst nur auf dem DNS die IP für eine bestimmte Domain ändern (dass du an den Server dran kommst, sei mal so dahin gestellt).

Ich dachte bisher immer DNS Spoofing funktioniert so:

Situation: Client a möchte mit Server b kommunizieren. Der Bösewicht c möchte sich mittels DNS Spoofing gegenüber a als b ausgeben.

c DoSed (z.B. mittels Floodping ganz simpel, wenn er die dickere Leitung hat) den/die für b zuständige(n) DNS Server d, sodass diese nicht mehr antworten können. c gibt sich mittels IP-Spoofing als d aus (Absendeadresse) und schickt so (falsche) DNS Antworten an a. Damit landen die Anfragen von a z.B. auf b.

Ich habe jetzt das DNS Protokoll nicht so genau intus, aber es soll wohl sowas wie Checksummen geben, die man erst mal erraten müsste, etc. Außerdem müsstest du die Zeit wissen, in der a auf b zugreifen möchte, usw. Man sieht, soooo trivial ist das nun wirklich nicht.

Allerdings kannst du dir dein selbstsigniertes Zertifikat auch für deine IP erstellen, so kannst du DNS-Spoofing ausschließen

Nö. Das hilft nur, wenn ich dieses selbstsignierte Zertifikat bereits auf meinem Client habe und damit dann erkenne, dass sich das Zertifikat geändert hat. Wenn ich mich aber zum ersten Mal mit einem Server verbinde, d.h. das Zertifikat noch nicht kenne, hilft das genau gar nichts, da hat MajorTermi durchaus recht. Genau für diesen Zweck gibt es dann ja CAs.

EDIT: PS: Da es ja jetzt mehr um die Technik geht, verschiebe ich ins Security.

dodolin wrote: Ich habe jetzt das DNS Protokoll nicht so genau intus, aber es soll wohl sowas wie Checksummen geben, die man erst mal erraten müsste, etc. Außerdem müsstest du die Zeit wissen, in der a auf b zugreifen möchte, usw. Man sieht, soooo trivial ist das nun wirklich nicht.

Hmmm... ich glaube, beim DNS schickt der Client eine Anfrage an einen DNS-Server und wartet auf einem UDP-Port (!) auf eine passende Antwort... das *erste* Paket, das passt, wird genommen (also auch von nicht angefragten Nameservern) so daß es z.B. möglich sein sollte, das man den Client mit DNS-Antworten überhäuft... natürlich muß man dazu auch wissen, was für Anfragen der Client denn stellen könnte um passende Antwort-Pakete zu senden...

Verhindern kann man das z.B. durch einen Paketfilter, der UDP auf Port 53 z.B. nur von den IPs des Providers zuöäßt - aber auch hier ist man dann vor gleichzeitigem IP-Spoofing nicht geschützt...

Abhilfe hierbei würde dann wohl nur Secure-DNS bereiten oder man arbeitet direkt mir IP-Adressen (wenn man z.B. Man-In-The-Middle Attacken zum entführen von SSH-Sitzungen usw. entgehen will)...

Aber das ist alles dennoch sehr theoretisch und von einem Angreifer nicht so ohne weiteres zu realisieren... bei uns an der Uni habe ich sowas mal im Netzwerk der Bibliothek vorgeführt und so eine Sitzung von den Terminals in der Bib 'entführt' - natürlich nur mit Erlaubnis vom Rechenzentrum die das selber mal sehen wollten...

sqrt wrote:

dodolin wrote: Ich habe jetzt das DNS Protokoll nicht so genau intus, aber es soll wohl sowas wie Checksummen geben, die man erst mal erraten müsste, etc. Außerdem müsstest du die Zeit wissen, in der a auf b zugreifen möchte, usw. Man sieht, soooo trivial ist das nun wirklich nicht.

Hmmm... ich glaube, beim DNS schickt der Client eine Anfrage an einen DNS-Server und wartet auf einem UDP-Port (!) auf eine passende Antwort... das *erste* Paket, das passt, wird genommen (also auch von nicht angefragten Nameservern) so daß es z.B. möglich sein sollte, das man den Client mit DNS-Antworten überhäuft... natürlich muß man dazu auch wissen, was für Anfragen der Client denn stellen könnte um passende Antwort-Pakete zu senden...

Ok, jetzt wollte ich's genau wissen und habe mir RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION reingezogen. :)

Ich hatte wohl gar nicht mal so unrecht... ;)

7.3. Processing responses

[...]

The next step is to match the response to a current resolver request.
The recommended strategy is to do a preliminary matching using the ID
field in the domain header, and then to verify that the question section
corresponds to the information currently desired. This requires that
the transmission algorithm devote several bits of the domain ID field to
a request identifier of some sort.

Wenn man dann weiter oben guckt, sieht man, dass dieses ID Feld 16 bit lang ist. D.h. der DNS-Spoofer müsste schon ziemlich viele Möglichkeiten durchtesten, bis er das errät.

ID

A 16 bit identifier assigned by the program that
generates any kind of query. This identifier is copied
the corresponding reply and can be used by the requester
to match up replies to outstanding queries.

Verhindern kann man das z.B. durch einen Paketfilter, der UDP auf Port 53 z.B. nur von den IPs des Providers zuöäßt - aber auch hier ist man dann vor gleichzeitigem IP-Spoofing nicht geschützt...

iptables ist neuerdings stateful, auch für UDP. Das ist zwar irgendwie seltsam, aber gerade für DNS scheint das sehr gut zu funktionieren.

dodolin wrote: Ok, jetzt wollte ich's genau wissen und habe mir RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION reingezogen. :)

Hehehe :-D

[..]

Wenn man dann weiter oben guckt, sieht man, dass dieses ID Feld 16 bit lang ist. D.h. der DNS-Spoofer müsste schon ziemlich viele Möglichkeiten durchtesten, bis er das errät.

Ja, recht hast Du - bei meinen Veruschen in der Uni-Bib. habe ich auch vorher die ARP-Caches des Default-GW und der Rechner 'manipuliert' um die DNS-Anfragen über mein Notebook zu leiten und zu sehen... dann hat man ja die DNS-IDs und kann entsprechende Antworten generieren... Sowas geht natürlich gut in Netzen in denen man auf das Routing 'Einfluss' hat bzw. sich dazwischen hängen kann - im Internet ist das IMHO etwas komplizierter...

Verhindern kann man das z.B. durch einen Paketfilter, der UDP auf Port 53 z.B. nur von den IPs des Providers zuöäßt - aber auch hier ist man dann vor gleichzeitigem IP-Spoofing nicht geschützt...

iptables ist neuerdings stateful, auch für UDP. Das ist zwar irgendwie seltsam, aber gerade für DNS scheint das sehr gut zu funktionieren.[/quote]

Ja, das sollte auch funktionieren, da meistens sowieso die Antwort vom Nameserver kommt, den man auch befragt hat (der Nameserver schickt diese Antwort ja auch). Antworten von anderen Nameservern, die Deine Anfrage auch 'gesehen' haben könnten sollten aber am Paketfilter aufschlagen und nicht durch kommen...

Die Wahrscheinlichkeit, das Dein Provider aber solche DNS-Anfragen sieht und für schnellere Reaktionszeiten einen eigenen Nameserver am Laufen hat sind wohl eher gering... das Feature gehört IMHO zu den Dingen, die man heutzutage im DNS nicht mehr unbedingt benötigt (es sei denn, Nameserver, die sich untereinander unterhalten bräuchten das)...

Ja, recht hast Du - bei meinen Veruschen in der Uni-Bib. habe ich auch vorher die ARP-Caches des Default-GW und der Rechner 'manipuliert' um die DNS-Anfragen über mein Notebook zu leiten und zu sehen... dann hat man ja die DNS-IDs und kann entsprechende Antworten generieren... Sowas geht natürlich gut in Netzen in denen man auf das Routing 'Einfluss' hat bzw. sich dazwischen hängen kann - im Internet ist das IMHO etwas komplizierter...

Danke, danke. Klingt echt interessant, so ein "Feldversuch"... Wenn man natürlich die DNS Anfragen irgendwie abfangen kann, wird es leicht(er), klar. Im Internet sollte das ja allerdings nicht gerade trivial sein, insofern ist dein "etwas komplizierter" wohl noch "etwas untertrieben". ;)

So, und jetzt gute Nacht! :)