1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Nach Safari: Chrome und Firefox…

Eine Zumutung ...

Am 17. Juli erscheint Ghost of Tsushima; Assassin's Creed Valhalla und Watch Dogs Legions konnten wir auch gerade länger anspielen - Anlass genug, um über Actionspiele, neue Games und die Next-Gen-Konsolen zu sprechen! Unser Chef-Abenteurer Peter Steinlechner stellt sich einer neuen Challenge: euren Fragen.
Er wird sie am 16. Juli von 14 Uhr bis 16 Uhr beantworten.
  1. Thema

Neues Thema Ansicht wechseln


  1. Eine Zumutung ...

    Autor: phade 29.06.20 - 14:59

    Es gibt nicht nur einfache Zertifikate für Webseiten, sondern z.B. auch für Mailserver oder EV- oder Multihost-Zertifikate, deren Verlängerung sich nicht automatisieren lässt, weil es die Software dafür gar nicht gibt oder manuelle Anrufe oder Papierkram erledigt werden müssen.

    Das jetzt nun jedes Jahr ? Wahnsinn, die Admins werden durchdrehen.

    Warum man weiter die Identitätsprüfung mit der Verschlüsselung protokolltechnisch zusammenwirft, erschliesst sich mir immer weniger. Für einen SSH-Connect brauche ich kein Zertifikat, es wird verschlüsselt und gut. Wenn ich bei http auch noch die Identität prüfen können will, ok, dann kann man das bitte über ein extra Zertifikat regeln, die reine Verschlüsselung könnte aber auch ohne Zertifikat mit einem public/private-key laufen ...

    Wo der Vorteil dabei sein soll, dass ein Zertifikat nur kurz gültig ist, konnte mir auch bisher keiner erklären. Geht es hier um die Identität ? Die in einem einfachen SSL-Zertifikat gar nicht garantiert ist und eine Webseite über die Domain absichert, die es nächste Woche schon nicht mehr so gibt oder jemandem anderen gehört ? Die Inhaberschaft wird ja bei einfachen Zertifikaten nicht geprüft, sondern maximal per eMail, DNS oder Webcode "abgesichert".

    Die ersten Anbieter umgehen diese Jahreslaufzeit, indem Sie Multihostzertifikate verbreiten, die dann z.B. 5 Zertifikate gleich bei der Ausstellung enthalten, jeweils für ein Jahr gültig. Was dann den "Sicherheitsgewinn" völlig ad absurdum.



    1 mal bearbeitet, zuletzt am 29.06.20 15:00 durch phade.

  2. Re: Eine Zumutung ...

    Autor: Quantium40 29.06.20 - 15:21

    phade schrieb:
    > Wo der Vorteil dabei sein soll, dass ein Zertifikat nur kurz gültig ist, konnte mir auch bisher
    > keiner erklären.

    Der Vorteil liegt darin, dass man weniger Probleme mit zurückgezogenen Zertifikaten bekommt.
    Die Listen für zurückgezogene Zertifikate sind im Moment um einige Größenordnungen größer als die Liste mit den gültigen Zertifikaten.

  3. Re: Eine Zumutung ...

    Autor: phade 29.06.20 - 15:38

    Ernsthaft ? Das ist eine DNS-Anfrage pro Zertifikat.

    Und diese Anfrage kann man ja cachen und nur 1x pro Tag machen.

  4. Re: Eine Zumutung ...

    Autor: AynRandHatteRecht 30.06.20 - 01:33

    phade schrieb:
    --------------------------------------------------------------------------------
    > Es gibt nicht nur einfache Zertifikate für Webseiten, sondern z.B. auch für
    > Mailserver oder EV- oder Multihost-Zertifikate, deren Verlängerung sich
    > nicht automatisieren lässt, weil es die Software dafür gar nicht gibt oder
    > manuelle Anrufe oder Papierkram erledigt werden müssen.

    Doch, lässt sich alles automatisieren. Heute schon. Und zwar über DNS statt HTTP als Verifikationsmethode und da man mittels speziellem CNAME auch den DNS für zB let's encrypt unabhängig vom eigentlichen NS der Zone halten kann, braucht man auch keine "Produktiv"-Schnittstelle an den internen oder externen DNS-Provider.

    https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode

    und als DNS:

    https://github.com/acmesh-official/acme.sh/wiki/dnsapi
    oder self-hosted https://github.com/joohoi/acme-dns

  5. Re: Eine Zumutung ...

    Autor: phade 30.06.20 - 10:20

    Ich rede doch nicht von den einfacher Fällen, bei denen der admin sowohl Webserver als auch Domain und Nameserver unter Kontrolle hat und es nur Host-DV-Zertifikate sind und ein ACME-Client integrierbar ist. Also eben nicht von dem Standard-Webseitenprovider.

    Ich redete von EV-Zertifikaten, bei denen die Verifizierung manuell per Anruf beim Chef oder IT-Leiter auf Termin erfolgt, der dann auch erreichbar sein muss. Oder per Papierkram.

    Ich redete von Zertifikaten, die es gar nicht bei LetsEncrypt gibt, z.B. Multihost, Multi-SAN- oder Wildcardzertifikaten. Die gibt es dann nur bei Vergabestellen, die ACME nicht unterstützen und alle eine eigene API haben.

    Und selbst dann hast du eben erstmal nur das Zertifikat. Eine automatische Installation ist dann noch ein ganz andere Hausnummer. Mag bei Apache, nginx, Tomcat und Co noch automatisierbar sein.

    Deshalb rede ich auch von Grosskunden, die Zertifikate auf Hunderten Appliances, Firewalls, Switchen, Routern, Firewalls und speziellen Webservern haben, alle ohne ACME-Integration und mit Webinterfacen, bei denen der admin das Zertifikat manuell uploaden muss. Verstreut auf viele Abteilungen, viele verschiedenen Admins und dutzenden Carrier, Housingcentern und Providern.

    Ich rede von SLAs, bei denen du erstmal Tickets und Wartungsfenster öffnen musst, bevor du überhaupt am Live-Service irgend etwas ändern darfst.

    Und ich rede von IoT-Geräten, bei denen du mit einem USB-Stick durch Fabrikhallen wandern und bei X Sensoren ein Knöpfchen drücken musst, bevor du die config ändern darft (hier arbeiten wir mittlerweile lieber mit einer private CA und stellen eben interne Zertifikate mit einer Laufzeit von 10 Jahren aus und patchen dann alle neue Desktop-Rechner des Kunden mit dem private CA-Root-Zertifikat).

    Wir haben Kunden, die allein fürs Einspielen eines neuen Zertifikats Mannwochen verbrauchen.

    Und das machst du jetzt nicht alle 5 Jahre (wie es noch vor Jahren war), sondern mittlerweile seit einer Weile schon alle 2 Jahre und zukünftig jedes Jahr und bald bestimmt alle paar Monate. Ein riesiger volkswirtschaftlicher Schaden, nur weil https schlecht designed und die Verschlüsselung mit der Identitätsprüfung verknüpft wurde.

    Bei Sectigo kannst du deshalb schon Multi-SAN-Zertifikate kaufen. 5 Zertifikate in Einem, für jedes Jahr eins. Und DigiCert plant das auch schon ...

  6. Re: Eine Zumutung ...

    Autor: AynRandHatteRecht 30.06.20 - 12:57

    phade schrieb:
    --------------------------------------------------------------------------------
    > Ich rede doch nicht von den einfacher Fällen, bei denen der admin sowohl
    > Webserver als auch Domain und Nameserver unter Kontrolle hat und es nur
    > Host-DV-Zertifikate sind und ein ACME-Client integrierbar ist. Also eben
    > nicht von dem Standard-Webseitenprovider.
    >
    > Ich redete von EV-Zertifikaten, bei denen die Verifizierung manuell per
    > Anruf beim Chef oder IT-Leiter auf Termin erfolgt, der dann auch erreichbar
    > sein muss. Oder per Papierkram.


    EV für Mailserver?

    >
    > Ich redete von Zertifikaten, die es gar nicht bei LetsEncrypt gibt, z.B.
    > Multihost, Multi-SAN- oder Wildcardzertifikaten. Die gibt es dann nur bei
    > Vergabestellen, die ACME nicht unterstützen und alle eine eigene API
    > haben.


    Let's encrypt hat wildcard und multi host Zertifikate.


    > Und selbst dann hast du eben erstmal nur das Zertifikat. Eine automatische
    > Installation ist dann noch ein ganz andere Hausnummer. Mag bei Apache,
    > nginx, Tomcat und Co noch automatisierbar sein.


    Wir leben in 2020 und alle ist automatisiert. certbot, acme.sh und co können Services reloaden damit diese neue Zertifikate verwenden zB alle von Dir genannten Anwendungen.

    >
    > Deshalb rede ich auch von Grosskunden, die Zertifikate auf Hunderten
    > Appliances, Firewalls, Switchen, Routern, Firewalls und speziellen
    > Webservern haben, alle ohne ACME-Integration und mit Webinterfacen, bei
    > denen der admin das Zertifikat manuell uploaden muss. Verstreut auf viele
    > Abteilungen, viele verschiedenen Admins und dutzenden Carrier,
    > Housingcentern und Providern.

    Kein Problem. Per sftp kann man das Zertifikat auch überall hinladen . Die DNS validierung ist quasi "out of Band".


    > Ich rede von SLAs, bei denen du erstmal Tickets und Wartungsfenster öffnen
    > musst, bevor du überhaupt am Live-Service irgend etwas ändern darfst.

    Dann solltest Du rasch einen neuen Job suchen, denn wer heute noch so arbeitet, wird die nächsten Jahre nicht mehr überleben.


    >
    > Und ich rede von IoT-Geräten, bei denen du mit einem USB-Stick durch
    > Fabrikhallen wandern und bei X Sensoren ein Knöpfchen drücken musst, bevor
    > du die config ändern darft (hier arbeiten wir mittlerweile lieber mit einer
    > private CA und stellen eben interne Zertifikate mit einer Laufzeit von 10
    > Jahren aus und patchen dann alle neue Desktop-Rechner des Kunden mit dem
    > private CA-Root-Zertifikat).

    Du hast ja selbst eingesehen, dass Zertifikate einer Public CA für den IoT-Betrieb ohne "Kundenkontakt" Blödsinn sind. Hättest den Absatz einfach wieder gelöscht…

    > Wir haben Kunden, die allein fürs Einspielen eines neuen Zertifikats
    > Mannwochen verbrauchen.
    >

    Warum Kunden? Verkauft ihr Zertifikate weiter?!



    > Und das machst du jetzt nicht alle 5 Jahre (wie es noch vor Jahren war),
    > sondern mittlerweile seit einer Weile schon alle 2 Jahre und zukünftig
    > jedes Jahr und bald bestimmt alle paar Monate. Ein riesiger
    > volkswirtschaftlicher Schaden, nur weil https schlecht designed und die
    > Verschlüsselung mit der Identitätsprüfung verknüpft wurde.
    >
    > Bei Sectigo kannst du deshalb schon Multi-SAN-Zertifikate kaufen. 5
    > Zertifikate in Einem, für jedes Jahr eins. Und DigiCert plant das auch
    > schon ...


    Der Mensch ist mit Intelligenz ausgestattet, die es ihm erlaubt, sich auf Unbekanntes oder Veränderungen einzustellen, sich zu adaptieren. Manche Menschen gerade in D scheinen sich lieber daran aufzugeilen, sich nicht anzupassen. Erfinden Sockenpuppen und Strohargumente, wollen immer "die totale Lösung" - die es nicht gibt. Schlaue Leute sind Rosinenpicker und KomplexitätsvermeiderY

  7. Re: Eine Zumutung ...

    Autor: phade 30.06.20 - 14:17

    Niemand redet von EV speziell für Mailserver. Wird zumeist dort nicht gebraucht.

    Die EV-Zertifzierung erfolgt weiterhin per Anruf oder per Papierkram.
    In dem Prozess gibt es KEINE Automatisierung bei der Beantragung. Widerspricht völlig dem Sinn eines EV-Zertifikats.

    Multidomain- und Multihostzertifikate seh ich bei LetsEncrypt nicht.
    Link ?
    Wildcard läuft auch nur mit speziellen PlugIns (die widerum nicht überall laufen) oder eben per DNS. Nicht jeder Webserver ist ein Apache ! Und nicht jeder Kunde hat die Domain und dessen Nameserver bei einem Provider, bei dem du automatisierten Zugriff auf die DNS-Server bekommst.

    Seit die DSGVO die meisten whois-server dicht gemacht hast, kannst du nicht mal mehr per eMail an den tech-c oder zone-c authorisieren.

    Überall per SFTP hinladen ?
    Sehe ich nicht, weder bei aktuellen LoadBalancern, noch Switchen, noch sonstigem "Gerät".
    Sollen die Kunden ihr Equipment nach dem Feature des Einspielens eines Zertifikats aussuchen ?
    Sorry, das ist Quark. Das können wir als Zertifikatsdienstleister dem Kunden nicht vorschreiben.

    Und auf die Vorgaben durch die SLAs des Kunden (und dessen SLAs an deren Kunden) haben wir keinen Einfluss.

    Es gibt dann noch S/MIME und CodeSigning-Zertifikate. Laufen die bald auch nur ein Jahr ? 3 Monate oder noch weniger ? Viel Spass mit den Kunden, wenn du denen erzählst, dass du gerne die eMails von der Vergabestelle auf dem Mailserver wegfischen willst und Zugriff auf alle Mailclients brauchst, um die S/MIME-Zertifikate zu installieren. Und die Dokumente nur noch 3 Monate zu lesen sind ...

    Sorry @AynRandHatteRecht
    Du musst mal ein bisschen in die Realität kommen.
    Automatisierung geht an vielen Ecken, aber eben nicht überall.
    Es gibt auch Kunden, die definitiv KEINE Zertifikate von LetsEncrypt wollen. Aus diversen Gründen.

    (demnächst hängt noch die weltweite Internetverschlüsselung an einem Root-Zertifikat. Na danke schön ...)

  8. Re: Eine Zumutung ...

    Autor: AynRandHatteRecht 30.06.20 - 19:31

    phade schrieb:
    --------------------------------------------------------------------------------
    > Niemand redet von EV speziell für Mailserver. Wird zumeist dort nicht
    > gebraucht.
    >
    > Die EV-Zertifzierung erfolgt weiterhin per Anruf oder per Papierkram.
    > In dem Prozess gibt es KEINE Automatisierung bei der Beantragung.
    > Widerspricht völlig dem Sinn eines EV-Zertifikats.
    >
    > Multidomain- und Multihostzertifikate seh ich bei LetsEncrypt nicht.
    > Link ?

    https://www.internetsociety.org/blog/2018/03/lets-encrypt-offers-free-multi-domain-https-certificates/

    > Wildcard läuft auch nur mit speziellen PlugIns (die widerum nicht überall
    > laufen) oder eben per DNS. Nicht jeder Webserver ist ein Apache ! Und nicht
    > jeder Kunde hat die Domain und dessen Nameserver bei einem Provider, bei
    > dem du automatisierten Zugriff auf die DNS-Server bekommst.

    Nein. Keine Plugins. Ich erkläre es Dir nochmal:

    1. Du hast irgendwo ein acme.sh oder certbot konfiguriert, der per cronjob Zertifikate von LE requested. Hierzu verwendet er die DNS-Validierung
    2. Bei einem Request zu LE erhält er ein Token zurück, dieses schreibt er in einen TXT record der Zone oder(!) delegierten Zone(!), die eine komplett andere Zone sein kann und dessen DNS sonst keine Requests abwickelt. Oder man spricht eine der 100 unterstützten DNS-Provider mit ihren Schnittstellen an, auch einige deutsche Domainanbieter sind drin.
    3. Acme.sh oder Certbot erhalten das Zertifikat, auch Wildcard. Es ist für 90 Tage gültig. Wie Du das in deiner Org verteilst, ist komplett offen. Schieb es per rsync auf andere Server, speichere es auf deinem Chef/Puppet/sonstwas Server und rolle es darüber aus.
    4. Apache, Nginx, Postfix, Dovecot whatever lassen sich alle unterbrechungsfrei reloaden. Einfach Zertifikate auf Platte überschreiben + reload anstossen. Done.


    >
    > Seit die DSGVO die meisten whois-server dicht gemacht hast, kannst du nicht
    > mal mehr per eMail an den tech-c oder zone-c authorisieren.

    Ist auch nicht notwendig. Siehe oben. Die Hürde es zu automatisieren ist so minimal geworden, dass jede Manuelle Interaktion Unfug ist. EV-Zertifikate sind auch unfug, technisch sind sie identisch mit dem Kram, der LE ausstellt, mit dem Unterschied eines Flags. Dieser Flag hat früher Browser etwas besonderes Anzeigen lassen, das wurde ja mittlerweile ersatzlos gestrichen. EV sind deshalb tot.

    > Überall per SFTP hinladen ?
    > Sehe ich nicht, weder bei aktuellen LoadBalancern, noch Switchen, noch
    > sonstigem "Gerät".
    > Sollen die Kunden ihr Equipment nach dem Feature des Einspielens eines
    > Zertifikats aussuchen ?

    Jeder LB hat APIs um mit 1-2 Request die Konfigrationen zu aktualisieren und auch Zertifikate auszutauschen. Worst case per rsync/sftp, best case läuft da eh ein Linux und man hat es im Config-Management-Tool der Wahl (Chef, Puppet, Ansible…).

    > Sorry, das ist Quark. Das können wir als Zertifikatsdienstleister dem
    > Kunden nicht vorschreiben.

    Euere Kunden sind inkompetent und 10 Jahre hinterher. Ihr habt zwei Möglichkeiten: Ihr macht das, was ich mit Dir versuche, nämlich die Hürden zu senken und Aufzuklären. Wenn Ihr das nicht schafft, sind eure Kunden unrettbar hinterher und werden von den Marktkräften in den nächste Jahren liquidiert. AWS und Cloudflare geben ja schon ohne Zutun Zertifikate raus, euer Business ist also sowieso tot.


    > Es gibt dann noch S/MIME und CodeSigning-Zertifikate. Laufen die bald auch
    > nur ein Jahr ? 3 Monate oder noch weniger ? Viel Spass mit den Kunden, wenn
    > du denen erzählst, dass du gerne die eMails von der Vergabestelle auf dem
    > Mailserver wegfischen willst und Zugriff auf alle Mailclients brauchst, um
    > die S/MIME-Zertifikate zu installieren. Und die Dokumente nur noch 3 Monate
    > zu lesen sind ...

    Code Signing-Zertifikate sind eine andere Baustelle und zB bei Apple sowieso unabhängig vom "öffentlichen" CA-Trust der Browser. Apple ist CA und macht die Regeln. Microsoft wird das ähnlich machen. Sie besitzen die Plattform und werden Dritt-CAs nicht mehr dulden aus marktpolitischen Gründen.

    S/MIME ist die einzige Baustelle. Aber da gibt es mW auch nur noch 2 Anbieter von Gratis-Zertifikaten und die allgemeine Nutzung ist weiterhin nahe 0. Da so viele Unternehmen ihre komplette Mail an Google oder Microsoft outgesourced haben, fehlt dort auch der Support für S/MIME (insb im Browser und den nativen Apps).

    > (demnächst hängt noch die weltweite Internetverschlüsselung an einem
    > Root-Zertifikat. Na danke schön ...)

    Das tut es jetzt schon. Die CA-Bundles von MS, Google, Apple und Mozilla sind die Grundlage aller. Wer dort rausfliegt, ist tot. Wer reinwill muss die Hosen runterlassen. Und dann gibt es noch ausserhalb von X.509 DNSSEC und da gibt es *wirklich* eine Root-Instanz, die alles delegiert.

  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. Diamant Software GmbH, Bielefeld
  2. über duerenhoff GmbH, Raum Pfungstadt
  3. Compador Dienstleistungs GmbH, Berlin
  4. FLYERALARM Digital GmbH, Würzburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de