1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › HTTPS/TLS: Zwischenzertifikate von…

Unsicheres Zertifikat > kein Zertifikat

  1. Thema

Neues Thema Ansicht wechseln


  1. Unsicheres Zertifikat > kein Zertifikat

    Autor: wurstfett 07.07.20 - 14:43

    Diese ganze Browserlogik ist funktional kaputt.
    Ohne Zertifikat beschwert sich kein Browser. Bei einem selbstzertifizierten Zertifikat gehen alle Glocken an. Am meisten Vertrauen sollte man dcoh direkt zum Anbieter des dienstes haben können. Der kommt aber nicht ohne die leidigen Zertifikatsstellen aus die sich dazwischen hängen wenn er einen grünen Browser möchte.

  2. Re: Unsicheres Zertifikat > kein Zertifikat

    Autor: wupme 07.07.20 - 15:00

    Die Frage ist, wie soll der Anbieter sein Zertifikat legitmieren?
    Angenommen ich nutze nun ein self signed Zertifikat. Warum sollte der Browser diesem Vertrauen?
    Wie bringe ich den Browsern bei dass dieses Zertifikat legitim ist?

    Die Warnung bei Self Signed sind durchaus berechtigt.

  3. selbst signiertes Zertifikat = kein Zertifikat

    Autor: atomie 07.07.20 - 15:07

    selbst signierte Zertifikate verwende ich nur im Intranet oder bei meinen localhost Seiten. und selbst da meckert der Browser. warum erkennt der Browser nicht die localhost Adresse und akzeptiert mein eigenes Zertifikat ohne murren? teilweise verzichte ich gänzlich drauf. das will ich keinem Benutzer zumuten erst diese gelb-schwarze Seite akzeptieren zu müssen und das "unsichere" Zertifikat herunterladen zu müssen.

  4. Re: Unsicheres Zertifikat > kein Zertifikat

    Autor: atomie 07.07.20 - 15:11

    wurstfett schrieb:
    --------------------------------------------------------------------------------
    > Der kommt aber nicht ohne
    > die leidigen Zertifikatsstellen aus die sich dazwischen hängen wenn er
    > einen grünen Browser möchte.
    Aus diesem Grund würde ich nie wieder zu einem Anbieter ohne Let's encrypt gehen. Einfacher geht es ja gar nicht mehr. was für ein Segen das es das gibt. Ein Hoch auf Mozilla :-)

  5. Re: Unsicheres Zertifikat > kein Zertifikat

    Autor: wurstfett 07.07.20 - 15:16

    Ja das stimmt halt schon aber du holst halt einen eigentlich unbeteiligten dritten mit ins Boot.

  6. Re: selbst signiertes Zertifikat = kein Zertifikat

    Autor: wurstfett 07.07.20 - 15:19

    das zeDtifikatZist aber halt eigentlich sicherer wenn es direkt vom Anbieter kommt und keine unbeteiligte dritte Partei mit eingreift. Bedeutet halt mehr arbeit eine Sichere Übertragung des Zertifikats hinzubekommen und bei einem Zertifikatsupdate das dann wieder auszurollen aber prinzipiell wäre ein selbst Zertifikat vertrauenswürdiger als eines von einer Zertifizierungsstelle.

  7. Re: selbst signiertes Zertifikat = kein Zertifikat

    Autor: nicoledos 07.07.20 - 16:19

    Das Risiko. Ein Angreifer könnte auch jederzeit ein Selfsigned Zertifikat ausliefern. Auch localhost / localnet ist da ein Thema. Auch da könnte ein Angreifer mit selfsigned MiM spielen. Da hilft nur eine eigene CA zu betreiben und die nötigen Zertifikate intern zu verteilen.

    So oder so ist das gesamte Zertifikatssystem kaputt.

  8. Re: Unsicheres Zertifikat > kein Zertifikat

    Autor: 0xffff 07.07.20 - 16:22

    Also:
    Self signed automatisch zu vertrauen nur weil localhost dabeisteht, ist trotzdem fahrlässig da man ja lokal auch kompromittiert sein kann. Egal auf wie viele oder wenige dieser angriffsvektor zutrifft, er bleibt legitim, und Kann von Schadsoftware ausgenutzt werden.
    Und einem Techniker sollte das einmalige einspielen eines Self signed Zertifikates eigentlich nicht weiter stören. Denn das ist in Sekunden erledigt, und kommt danach nicht wieder.

  9. Re: Unsicheres Zertifikat > kein Zertifikat

    Autor: HeroFeat 07.07.20 - 16:43

    Eben. Es gibt genügend "Antivirenprogramme" die nur zu gerne MITM spielen würden. Das sollte aber eine ganz bewusste Entscheidung sein.

    Und im Endeffekt ist es auch gar nicht mal so schwer sich für seinen lokalen Rechner ein Lets Encrypt Zertifikat zu hohlen. Man braucht nur eine Domain und einen autoritativen DNS Server der eine API besitzt, welche man für DNS-01 Challenges nutzen kann. Und schon hat man lokal ein LE Zertifikat.

  10. Re: selbst signiertes Zertifikat = kein Zertifikat

    Autor: Eheran 07.07.20 - 22:36

    >Ein Angreifer könnte auch jederzeit ein Selfsigned Zertifikat ausliefern.
    Dann muss eben nicht das Zertifikat von einer 3. Stelle kommen. Sondern nur die Bestätigung, dass das Zertifikat vom Anbieter selbst ist.
    Sprich statt:
    Anbieter fragt Zertifizierungsstelle --> bekommt von dieser Zertifikat --> Zertifikat ist für sich gültig wenn der Endnutzer es sieht

    Dann:
    Anbieter erstellt sich Zertifikat -> gibt dies einer 3. Partei -> Endnutzer bekommt vom Anbieter das Zertifikat und kann es bei 3. Partei gegenprüfen

  11. Re: selbst signiertes Zertifikat = kein Zertifikat

    Autor: 43rtgfj5 07.07.20 - 22:43

    wurstfett schrieb:
    --------------------------------------------------------------------------------
    > das zeDtifikatZist aber halt eigentlich sicherer wenn es direkt vom
    > Anbieter kommt und keine unbeteiligte dritte Partei mit eingreift. Bedeutet
    > halt mehr arbeit eine Sichere Übertragung des Zertifikats hinzubekommen und
    > bei einem Zertifikatsupdate das dann wieder auszurollen aber prinzipiell
    > wäre ein selbst Zertifikat vertrauenswürdiger als eines von einer
    > Zertifizierungsstelle.

    Warum ist es sicherer? Ich würde sagen, dass es gleich sicher ist, je nachdem, wie sehr man der Zertifizierungsstelle vertraut. Aber selbst wenn man davon ausgeht, dass die Zertifizierungsstelle kompromittiert ist, ist das Zertifikat dahinter nicht unsicherer. Den Private Key kriegt die Zertifizierungsstelle ja nicht zu Gesicht.
    Ob ich also ein Zertifikat habe, das von einer nicht vertrauenswürdigen Stelle signiert ist, oder eins das gar nicht signiert ist, ist egal. Ich kann beiden nicht vertrauen, denn dann weiß ich bei beiden nicht, ob das Zertifikat vom Betreiber kommt, oder ob z.B. mein ISP das Zertifikat zwischendurch getauscht hat.

    Ich stimme aber durchaus zu, dass das ganze System ziemlich kaputt ist. Aber da bleibt am Ende auch die Frage: Was wäre denn ein besseres System für Zertifikate?

  12. Re: selbst signiertes Zertifikat = kein Zertifikat

    Autor: FreiGeistler 08.07.20 - 12:48

    atomie schrieb:
    --------------------------------------------------------------------------------
    > selbst signierte Zertifikate verwende ich nur im Intranet oder bei meinen
    > localhost Seiten. und selbst da meckert der Browser. warum erkennt der
    > Browser nicht die localhost Adresse und akzeptiert mein eigenes Zertifikat
    > ohne murren? teilweise verzichte ich gänzlich drauf. das will ich keinem
    > Benutzer zumuten erst diese gelb-schwarze Seite akzeptieren zu müssen und
    > das "unsichere" Zertifikat herunterladen zu müssen.

    Da wäre eine Abfrage sinnvoll, á la "Ich soll lokale Seite sowieso öffnen. Kommt das von Ihnen oder war es eine verdächtige Software?"

  13. Re: selbst signiertes Zertifikat = kein Zertifikat

    Autor: phade 08.07.20 - 17:09

    43rtgfj5 schrieb:
    --------------------------------------------------------------------------------
    > Aber da bleibt am Ende auch die Frage: Was wäre denn ein besseres System
    > für Zertifikate?

    Eines, bei dem die Verschlüsselung von der Authentizität getrennt wird.

    Faktisch geht es beim Besuch von Webseiten doch nur darum, dass die Inhalte verschlüsselt werden. Die Authentizität ist für Banken notwendig, wichtige Shops etc etc, aber doch nicht für jede kleine Webseite. Da geht es zumeist doch eher um die verschlüsselte Übertragung von Formulardaten usw.

    Browser und Server könnten also für jede Session mit ihren private/public-keys einen session-key aushandeln, so wie das z.B. ein connect mit ssh macht. Da gibt es auch keine Verifizierung.

    Wenn ich mich nicht irre, war das beim SPDY-Protokoll von google mal am Anfang der Entwicklung der Fall. Da den Vergabestellen dann aber der Umsatz weggebrochen wäre, hat man in späteren Versionen von SPDY und dann eben auch in http/2 wohl wieder das alte Zertifikatssystem eingebaut. Wir werden also leider noch lange mit dem Schrott leben müssen.

    Da die meisten Zertifikate nur per eMail oder DNS- oder Web-Code validiert werden, kann man auf die Verifizierung über eine Zertifizierungs-/Vergabestelle auch komplett verzichten. Schlussendlich bestätigt die Vergabestelle nur, dass du unter deiner Domain eine eMail lesen oder einen Web- oder DNS-Code eintragen konntest.

    Das könnte man aber auch generell über DNS machen. Der Server verschlüsselt ja seine Verbindung mit seinem private-key. Der public-key des Servers wird im DNS verankert und damit entschlüsselt der Browser die Session. Bingo. Ist vom Level des Schutzes exakt vergleichbar.

    Dann gäbe es nur gar keine Vergabestellen mehr :o)
    Ok, die gibt es wegen LE sowieso bald nicht mehr.

    NUR HÄNGT DANN ALLES AN DEN ZERTIFIKATEN VON LE ! Und wenn mit denen mal was ist ... :o(

    Browser und Server schicken sich also ihre public keys, verschlüsseln jede Session mit ihren private keys und der Browser verifiziert den Server über den public key des Servers im DNS und kann dann, falls vorhanden und korrekt, neben "verschlüsselt" noch ein "geprüft" anzeigen.



    9 mal bearbeitet, zuletzt am 08.07.20 17:25 durch phade.

  14. Re: selbst signiertes Zertifikat = kein Zertifikat

    Autor: 43rtgfj5 08.07.20 - 17:32

    phade schrieb:
    --------------------------------------------------------------------------------
    > Eines, bei dem die Verschlüsselung von der Authentizität getrennt wird.
    >
    > Faktisch geht es beim Besuch von Webseiten doch nur darum, dass die Inhalte
    > verschlüsselt werden. Die Authentizität ist für Banken notwendig, wichtige
    > Shops etc etc, aber doch nicht für jede kleine Webseite. Da geht es zumeist
    > doch eher um die verschlüsselte Übertragung von Formulardaten usw.
    >
    > Browser und Server könnten also für jede Session mit ihren
    > private/public-keys einen session-key aushandeln, so wie das z.B. ein
    > connect mit ssh macht. Da gibt es auch keine Verifizierung.

    Aber hier kann man selbst prüfen, ob der Key der einem präsentiert wird, auch der richtige ist. Zumindest wenn es der eigene Server ist. Wenn ich zB bei Hetzner einen Server klicke, kriege ich den Fingerprint des SSH Keys im Webinterface angezeigt. Beim ersten Login fragt OpenSSH mich, ob ich dem Key mit dem Fingerprint vertrauen will. Da kann ich die abgleichen. Da ich den Fingerprint von Hetzner über eine authentifizierte Verbindung bekommen habe (SSL Zertifikat für Hetzner Website), habe ich zumindest einen gewissen Schutz davor, dass mir den jemand on-the-fly via MITM ausgetauscht hat. Denn die erste SSH Verbindung kann man auch mitschneiden bzw. manipulieren, wenn man es will.
    Gut, da muss ich zugeben, dass die Chancen generell eher niedriger sind, zumindest bei uns. Die erste Verbindung macht man i.d.R. über ein halbwegs vertrauenswürdiges Netzwerk, z.B. das eigene / Firmennetz. Aber hinter deinem Router kann das trotzdem jeder involvierte austauschen, u.a. der ISP, die Backbone-Provider, der ISP des Servers, ...

    > Da die meisten Zertifikate nur per eMail oder DNS- oder Web-Code validiert
    > werden, kann man auf die Verifizierung über ein Zertifikat auch komplett
    > verzichten. Schlussendlich bestätigt die Vergabestelle nur, dass du unter
    > deiner Domain eine eMail lesen oder einen Web- oder DNS-Code eintragen
    > konntest.

    Ist besser als nichts. Jemand der in meinem Wlan hängt kann mir bei der ersten Verbindung dennoch ein falsches Zertifikat unterjubeln, aber mit LetsEncrypt kann er das nur, wenn er auch Zugriff auf den Server bzw. die DNS Einträge hat. Ich würde jetzt einfach mal behaupten, dass das wohl in den meisten Fälle nicht zutrifft.

    > Das könnte man aber auch generell über DNS machen. Der Server verschlüsselt
    > ja seine Verbindung mit seinem private-key. Der public-key des Servers wird
    > im DNS verankert und damit entschlüsselt der Browser die Session. Bingo.
    > Ist vom Level des Schutzes exakt vergleichbar.
    >
    > Dann gäbe es nur gar keine Vergabestellen mehr :o)
    >
    > Browser und Server schicken sich also ihre public keys, verschlüsseln jede
    > Session mit ihren private keys und der Browser verifiziert den Server über
    > den public key des Servers im DNS (falls vorhanden) und kann dann neben
    > "verschlüsselt" noch ein "geprüft" anzeigen.

    Ist alles richtig - aber woher weiß ich denn ob der Key der richtige ist? Das ist ja das zentrale Problem an der Sache, weshalb ich auch der Meinung bin, dass man Authentizität und Verschlüsselung nicht wirklich trennen kann. Irgendwoher muss ich wissen, dass der Public-Key den ich vom Server kriege, auch dem Server gehört, und nicht dem Typen 3 Tische weiter im Cafe, der an seinem Laptop den Traffic mitschneidet.
    Das geht nur, wenn ich den Public-Key von einer Vertrauenswürdigen Quelle beziehen kann. Das kann unter Umständen der First Connect sein, denn ab da kenne ich den Key und kann vergleichen, solange dieser zeitlich gültig ist. Das ist aber auch der einzige mögliche Weg, und je nach Land kann ich der ersten Verbindung auch nicht vertrauen, weil der ISP nicht vertrauenswürdig ist. Klar, ich kann den Admin bzw. die Firma anrufen und nach dem Fingerprint vom SSL Key fragen, aber...

    Gut, man kann auch einwerfen, dass ja die Verbindung und damit die Verifizierung von LetsEncrypt manipuliert sein kann, was auch durchaus möglich wäre. Damit müsste man aber die gesamte Infrastruktur angreifen, was auffallen würde. Bei einer einzelnen Person wird das vermutlich nie auffallen.

  15. Re: selbst signiertes Zertifikat = kein Zertifikat

    Autor: phade 08.07.20 - 17:38

    43rtgfj5 schrieb:
    --------------------------------------------------------------------------------

    > Ist alles richtig - aber woher weiß ich denn ob der Key der richtige ist?

    Weil du kein private/public-key Paar erzeugen kannst, dass den gleichen public-key wie der des richtigen Servers hat.

    Wenn der Besucher also auf einer gefälschten Seite landet, kann der dortige Server nur mit einem anderen private-key verschlüsseln, weil dieser falsche Server den private-key des richtigen Servers nicht kennt. Somit ist dann dann auch der public-key ein anderer, als der vom richtigen Server.

    Dann ist die Übertragung zwar auch verschlüsselt, aber ...

    ... stimmt dieser public-key nicht mit dem im DNS eingetragen public-key überein, kann der Browser Alarm geben, weil dann klar ist, dass der Besucher auf dem falschen Server ist.



    4 mal bearbeitet, zuletzt am 08.07.20 17:46 durch phade.

  16. Re: selbst signiertes Zertifikat = kein Zertifikat

    Autor: phade 08.07.20 - 17:55

    Das Problem mit den public-private-keys bei https-Verbindungen ist also einfach zu lösen.

    Es gibt nur ein Problem: proxies, die sich dazwischen hängen müssen (z.B. auch AntiVirenprogramme). Die könnten zwar auch die Verbindung als MITM selbst mit dem Server aufbauen, müssten ihren Key aber auch im DNS verankern, um widerum mit dem lokalen Browser eine sichere Verbindung aufzubauen, damit der Browser das auch darstellt. Da das dann lokal beim Endnutzer läuft, wird das wohl eher nicht trivial ...

    Aber es gibt schlauere Köpfe als mich ... sollte doch zu lösen sein.

    (z.B. könnten solche daemons und tools ein per Vergabestelle geprüftes Zertifikat nutzen. Dann würde der Browser immer eine sichere Verbindung mit z.B. dem AntiVirusprogramm darstellen. Stimmt etwas mit dem public-key des Servers nicht, müsste dann das AntiVirusprogramm Alarm schlagen und die proxy-Verbindung zum Browser unterbrechen, der Browser würde ansonsten davon nämlich nichts mehr mitbekommen)



    5 mal bearbeitet, zuletzt am 08.07.20 18:00 durch phade.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. LISTAN GmbH, Glinde
  2. ING-DiBa AG, Frankfurt
  3. Vodafone GmbH, Düsseldorf
  4. Endress+Hauser Conducta GmbH+Co. KG, Gerlingen (bei Stuttgart)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 44,99€
  2. (-82%) 11,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


  1. Smartphone: Google stellt das Pixel 4 ein
    Smartphone
    Google stellt das Pixel 4 ein

    Nach nicht mal einem Jahr beendet Google die Produktion des Pixel 4 und Pixel 4 XL. Noch im Herbst soll aber der Nachfolger erscheinen.

  2. Corona: Gewerkschaft sieht Schulen schlecht digital ausgestattet
    Corona
    Gewerkschaft sieht Schulen schlecht digital ausgestattet

    In vielen Bundesländern beginnt die Schule wieder, die zuständige Gewerkschaft erwartet ein Jahr mit "viel Improvisation". Grund sei die schlechte digitale Ausstattung.

  3. Nach Microsoft: Auch Twitter soll an Tiktok interessiert sein
    Nach Microsoft
    Auch Twitter soll an Tiktok interessiert sein

    Neben Microsoft soll auch Twitter überlegen, die chinesische Social-Media-App zu übernehmen - mehr finanzielle Ressourcen dürfte aber Microsoft haben.


  1. 14:11

  2. 13:37

  3. 12:56

  4. 12:01

  5. 14:06

  6. 13:41

  7. 12:48

  8. 11:51