Hallo... Also erstmal glaube ich nicht, daß es noch möglich ist, HTTPS/TLS ohne Zertifikat sinnvoll zu nutzen. Ich weiß aber nicht, ob ich irgend eine Möglichkeit vergessen habe, wie man die SSL-Verschlüsselung benutzen kann, ohne eine Warnung vom Browser zu bekommen weil man ein selbst signiertes Zertifikat verwenden muß. Die Verschlüsselung ansich funktioniert ja trotzdem und ist nicht unsicherer als mit dem besten Zertifikat, aber die Warnung vom Browser nervt weil man nicht als vertrauenswürdig eingestuft wird und deswegen erst eine Ausnahme zulassen muß. Ich würde das für einen Server an einer dynamischen IP brauchen (Server zuhause), oder bekommt man irgendwo Zertifikate, die man an dynamischen IPs verwenden kann? Habe ich irgendwas vergessen, gibt es irgendeine Lösung, die die Verwendung von SSL ohne Zertifikat erlaubt ohne diese Browser-Warnung zu erzeugen? Danke.
Das Zertifikat gilt doch für eine Domain nicht für eine IP. Wenn die Domain gleich bleibt kann sich die IP normalerweise ohne Probleme ändern.
Ben B. schrieb: > Habe ich irgendwas vergessen, gibt es irgendeine Lösung, die die > Verwendung von SSL ohne Zertifikat erlaubt ohne diese Browser-Warnung zu > erzeugen? Ja, hast du: Let"s Encrypt und der passende ACME-Client für dein OS. Ohne Zertifikat funktioniert SSL in Verbindung mit dem Browser natürlich nicht, aber Let"s Encrypt ist eine kostenfreie CA und der ACME-Client sorgt für die regelmässige Erneuerung. Alles weitere ist auf https://letsencrypt.org gut erklärt. Läuft bei mir auf einem OpenBSD-Install wunderbar. Ben B. schrieb: > Die Verschlüsselung ansich funktioniert ja trotzdem und ist nicht > unsicherer als mit dem besten Zertifikat Du möchtest dir Dokumentationen zu dem Sinn von CA's und Zertifikaten durchlesen.
Ich weiß wozu Zertifikate "gut sind", ich finde es nur schade, daß es offenbar keinen Modus gibt, der die Verschlüsselung alleine (um die es ja eigentlich geht) ohne Zertifikat verwendet. Meine, HTTP ohne Verschlüsselung läuft auch ohne Zertifikat und da werd ich vom Browser nicht doof angeblökt... Da beißt sich die Katze in den Schwanz wenn die unsicherere Verbindung vertrauenswürdiger erscheint als eine SSL-geschützte Verbindung mit selbst signiertem Zertifikat. Mir geht es auch nicht darum, meinen Heimserver besonders vertrauenswürdig hinzustellen. Das soll jeder selbst entscheiden, ob er mir oder der Kiste vertraut oder ihr irgendwelche Daten anvertraut. Es geht bei der Kiste auch nicht um irgendwelche Bankgeschäfte usw. ich bin mir nur unsicher, ob man nach der Datenscheißgrundversauung noch sowas eMail-Adressen oder Kennwörter unverschlüsselt übertragen darf wenn man einen privaten nicht-kommerziellen Server betreibt.
Ben B. schrieb: > Ich weiß wozu Zertifikate "gut sind", ich finde es nur schade, daß es > offenbar keinen Modus gibt, der die Verschlüsselung alleine (um die es > ja eigentlich geht) ohne Zertifikat verwendet. Doch ein Zertifikat ist zwingend notwendig, da der Schlüsselaustausch der nachfolgenden Verschlüsselung mittels der asymmetrischen Verfahren mithilfe der Zertifikate arbeitet (Diffie-Hellmann-Schlüsselaustausch). Und würde der Browser alle Zertifikate ohne Überprüfung akzeptieren, kann man nicht mehr unterscheiden ob die Daten jetzt tatsächlich vom Server verschlüsselt wurden oder von einem bösartigen MITM Angreifer, daher es kann jeder mitlesen, ohne daß du es merkst. Es ergibt sich also die gleiche Sicherheit, wie ohne jegliche Verschlüsselung...
Ben B. schrieb: > Ich würde das für einen Server an einer dynamischen IP brauchen (Server > zuhause), oder bekommt man irgendwo Zertifikate, die man an dynamischen > IPs verwenden kann? Nein. Zur Prüfung des Zertifikats gehört ein Reverse-IP-Lookup, um sicherzustellen, dass der Kommunikations-Partner auch der ist, für den das Zertifikat gilt. Da geht also eine Anfrage raus "Wem gehört IP x?". Und die liefert dann i.d.R. irgendeinen Hostnamen des Internet-Providers.
Ben B. schrieb: > Meine, HTTP ohne Verschlüsselung läuft auch ohne Zertifikat und da werd > ich vom Browser nicht doof angeblökt... Doch, wirst Du, zumindest seit über einem Jahr von Chrome - und das ist der meistgenutzte Browser. Die Mecker kommt auch zurecht: https://doesmysiteneedhttps.com/ > mir nur unsicher, ob man nach der Datenscheißgrundversauung noch sowas > eMail-Adressen oder Kennwörter unverschlüsselt übertragen darf wenn man > einen privaten nicht-kommerziellen Server betreibt. Nein, darfst Du nicht. Persönliche Userdaten haben nichts mit gewerbsmäßigem Handeln zu tun.
Ben B. schrieb: > an einer dynamischen IP brauchen Man kann Zertifikate für IPs oder Namen erzeugen. Das Dumme ist nur, dass sie 1. irgendwann ABLAUFEN und erneuert werden müssen wenn es ewig funktionieren soll. 2. dass man der Zertifizierungsstelle vertrauen muß und sie verfügbar sein muss 3. dass Zertifikate für private IPs wie 192.168.x.x sinnlos sind, weil jede Fritzbox die selbe IP hat So gesehen ist Bens Wunsch berechtigt, nur das "Werkzeug" https ungünstig.
Heiko L. schrieb: > Nein. Zur Prüfung des Zertifikats gehört ein Reverse-IP-Lookup, um > sicherzustellen, dass der Kommunikations-Partner auch der ist, für den > das Zertifikat gilt. Nein, dann würde keine meiner Webseiten mehr funktionieren, und so ziemlich jedere andere Webseite auch nicht mehr. Und stell dir mal vor, z.B. cloudflair müsste für all seine IPs tausende PTR Einträge im Reverse-DNS anlegen und bei jeder Anfrage alle Senden, das würde vermutlich nichteinmal funktionieren. Und nein, es hilft auch nicht dabei sicherzustellen, dass der Kommunikations-Partner auch der ist, der er sagt. Erstens kann es nicht verhindern, dass sich jemand zwischen die Leitung häng oder per BGP Packete umleitet. Zweitens, falls ein Angreifer DNS Anfragen für eine Domain auf eine eigene Adresse umleiten kann, dann kann er auch den Merpreis beim ISP Zahlen, die Reverse DNS selbst zu verwalten, und reinzuscheiben, was auch immer er will. Der einzige ort, wo reverse DNS in seltenen Fällen verwendet wird, sind ein paar wenige E-Mail Anbieter. Momentan weiss ich nur von AOL und GMX, andere Anbieter, wie z.B. G-Mail, Hotmail/Outlook, Swisscom, Quickline, die meisten privaten Mailserver, Mailing listen (dyne.org, vger.kernel.org, etc.), prüfen reverse DNS nicht. (Ich weiss das, weil ich einen eigenen privaten Mail Server habe, aber mein ISP (Quickline), Reverse-DNS nur mit teuren Business Packeten anbietet, und den Blödsinn mach ich nicht mit. Es gäbe zwar noch andere Wege, an ne IP mit Reverse DNS ran zu kommen, aber das kostet halt auch.). Reverse DNS sollte man endlich mal abschaffen. Ben B. schrieb: > Ich weiß aber nicht, ob ich irgend eine > Möglichkeit vergessen habe, wie man die SSL-Verschlüsselung benutzen > kann, ohne eine Warnung vom Browser zu bekommen weil man ein selbst > signiertes Zertifikat verwenden muß. Es gäbe da DNSSEC+DANE. Nutze ich momentan ergänzend zum LetsEncrypt, falls die mal dicht machen, nehm ich halt DNSSEC+DANE+Selbstsigniert. Bei E-Mail sollte das ganz gut klappen. Bei Browsern gibt es leider noch keine, die reines DANE erlauben. (Nur mal so zum sagen, Let's Encrypt stellt Zertifikate aus, wenn man DNS Kontrolle hat, ich glaube sogar ohne DNSSEC, während DANE DNSSEC voraussetzt. Vorausgesetzt man nutzt DNSSEC mit ECDSA, würd ich das also als sicherer betrachten, als Let's Encrypr und sonstige CAs.). Auch noch zu erwähnen ist, dass man bei DNSSEC stat von 2 Authorities (DNS Registrar und eine CA) nurnoch von einer (DNS Registrar) abhängig ist, den braucht man so oder so, und von denen gibt es viele und viel konkurenz, weshalb dort ein Kontrollverlust unwahrscheinlicher ist. (Wobei es bei gewissen Zohnen ausnehmen gibt, insbesondere ENUM ist mittlerweile schwer zu bekommen.)
Ben B. schrieb: > Die Verschlüsselung ansich funktioniert ja trotzdem und ist nicht > unsicherer als mit dem besten Zertifikat, aber die Warnung vom Browser > nervt weil man nicht als vertrauenswürdig eingestuft wird und deswegen > erst eine Ausnahme zulassen muß. Man kann selbst signierte Zertifikate auch manuell im Browser hinterlegen. > Ich würde das für einen Server an einer dynamischen IP brauchen (Server > zuhause), oder bekommt man irgendwo Zertifikate, die man an dynamischen > IPs verwenden kann? Ja, funktioniert bei mir mit Letsencrypt + dynamic DNS von No-IP problemlos. Das geht mit ziemlich vielen DDNS-Providern. Heiko L. schrieb: > Nein. Zur Prüfung des Zertifikats gehört ein Reverse-IP-Lookup, um > sicherzustellen, dass der Kommunikations-Partner auch der ist, für den > das Zertifikat gilt. Da geht also eine Anfrage raus "Wem gehört IP x?". > Und die liefert dann i.d.R. irgendeinen Hostnamen des > Internet-Providers. Wäre das so, dann würde Letsencrypt zusammen mit DDNS nicht funktionieren, was es aber tut.
Ben B. schrieb: > ir geht es auch nicht darum, meinen Heimserver besonders > vertrauenswürdig hinzustellen. Das soll jeder selbst entscheiden, ob er > mir oder der Kiste vertraut oder ihr irgendwelche Daten anvertraut. Genau darum geht es bei den Zertifikaten ja _NICHT_. Sondern es geht darum, dass ich sicher sein kann, dass der, mit dem ich verschlüsselt kommuniziere, auch der ist, mit dem ich glaube zu kommunizieren. Ohne Zertifikat kann ich nicht sicher sein, dass sich nicht jemand anderes in den Verbindungsaufbau eingeklinkt hat und sich als dein server ausgibt. Das kann ich bei http natürlich auch nicht. Der Versuch per https zu kommunizieren legt aber nahe, dass mir die Daten wichtig sein könnten, die übertragen werden. Bei http kann generell ich davon ausgehen, dass sie jeder lesen kann. Das eine https-light Variante fehlt, die einfach als Ersatz für http benutzt werden kann, ist mir aber auch schon desöfteren aufgefallen.
Vlad T. schrieb: > Das eine https-light Variante fehlt, die einfach als Ersatz für http > benutzt werden kann, ist mir aber auch schon desöfteren aufgefallen. Das ist vor allem bei Kommunikation rein in einem internen Netz oft nervig, wenn ich Passwörter für irgendwelche Web-Interfaces von Geräten nicht immer im Klartext übertragen will, aber auch keine Lust habe, jedesmal mit Zertifikaten rumzuhantieren.
Rolf M. schrieb: > Das ist vor allem bei Kommunikation rein in einem internen Netz oft > nervig, wenn ich Passwörter für irgendwelche Web-Interfaces von Geräten > nicht immer im Klartext übertragen will, aber auch keine Lust habe, > jedesmal mit Zertifikaten rumzuhantieren. Der Punkt ist halt dass dir HTTPS ohne Zertifikat nichts bringt, weil du am Anfang einen Schlüsselaustausch machst, aber ohne Zertifikat nicht weißt mit wem eigentlich. Deshalb kann (auch im lokalen Netz) jemand einfach ein Tool dazwischenstecken, was alles mithört. Die Verschlüsselung bringt dir dann genau nichts.
Das ist zwar jetzt eine ziemlich schlechte/böse Idee, aber wenn man nur lokal mit https zuhause von zeit zu zeit was testen will, und mit letsencrypt und nem raspberry pi bereits wildcard SSL Zertifikate holt, könnte man darauf nen Proxy einrichten, der sich zum anfragenden Rechner verbindet, und dann rechner(browser)-(https)->server-(http)->rechner(lokaler server) macht:
1 | <VirtualHost *:443> |
2 | DocumentRoot /var/www/wildcard |
3 | ServerName self.example.com |
4 | SSLEngine on |
5 | SSLCertificateFile "/path/to/self.example.com.cert" |
6 | SSLCertificateKeyFile "/path/to/self.example.com.key" |
7 | |
8 | <Location "/"> |
9 | Require ip 10.0.0.0/8 |
10 | Require ip 172.16.0.0/12 |
11 | Require ip 192.168.0.0/16 |
12 | Require ip 169.254.0.0/16 |
13 | Require ip fc00::/7 |
14 | Require ip fd00::/8 |
15 | Require ip fe80::/10 |
16 | </Location> |
17 | |
18 | # Proxy back to client, port 80 |
19 | RewriteCond "${lowercase:%{HTTP_HOST}}" "^self\.example\.com$"
|
20 | RewriteRule "^/(.*)" "http://%{REMOTE_ADDR}/$1" [P]
|
21 | ProxyPassReverse "/" "http://%{REMOTE_ADDR}/"
|
22 | |
23 | # Proxy back to client, other port |
24 | ServerAlias *.self.example.com |
25 | RewriteCond "${lowercase:%{HTTP_HOST}}" "^([^.]+)\.self\.example\.com$"
|
26 | RewriteRule "^/(.*)" "http://%{REMOTE_ADDR}:%1/$1" [P]
|
27 | ProxyPassReverse "/" "http://%{REMOTE_ADDR}:[0-9]*/"
|
28 | </VirtualHost> |
Ich habe nicht ausprobiert, ob das geht, und es ist sicherheitstechnisch problematisch, aber falls es funktioniert, könnte man den Server einrichten, das SSL zeug automatisch up-to-date zu halten, und kann am Entwicklungsrechner zum Testen einfach https://self.example.com/ eingeben, wenn man local auf 80 nen server laufen hat, oder z.B. https://8080.self.example.com/, falls man auf Port 8080 was laufen hat. Das könnte dann schon manchmal recht nützlich sein. Muss ich am Wochenende mal ausprobieren.
> Es ergibt sich also die gleiche Sicherheit, > wie ohne jegliche Verschlüsselung.. Nicht ganz richtig. Ein MITM Angriff ist nur erfolgreich, wenn dieser bereits den Verbindungsaufbau verfälscht hat. Das kann Dir aber genau so passieren, wenn der Angreifer ein echtes vertrauenswürdiges Zertifikat verwendet und die verfälschte Domain verbirgt. Bei einem "planmäßigen" Verbindungsaufbau ist ein Mitlesen der Daten durch Fremde nicht mehr möglich, also schon ein Sicherheitsgewinn. Außerdem wird auch das selbst signierte Zertifikat technisch so sicher wie ein kommerziell ausgestelltes, insofern der erste Kontakt bzw. die Erstellung der Ausnahmeregel unverfälscht abgelaufen ist. Mit dem Ablaufen von Zertifikaten könnte ich mich ja noch anfreunden, einmal jährlich ein neues erstellen ist ja nun kein Problem, erst recht nicht auf einem Testserver. > Nein, darfst Du nicht. Persönliche Userdaten haben nichts mit > gewerbsmäßigem Handeln zu tun. Sehe ich prinzipiell genau so, dann bliebe wohl die Frage wie schafft man es, daß die DSGVO für einen Testserver (auf dem bspw. selbst entwickelte Internetseiten mit Login-Funktionen getestet bzw. geschrieben werden) nicht gilt? > dass Zertifikate für private IPs wie 192.168.x.x > sinnlos sind, weil jede Fritzbox die selbe IP hat Die interne IP ist dem externen Benutzer nicht sichtbar bzw. nur wenn der Server sie irgendwo meldet (z.B. phpinfo(), was ja auch garantiert öffentlich zugänglich sein sollte... :]). Von außen sieht man nur die externe IP, die aber eben nicht konstant ist sonden alle paar Tage/Wochen mal wechselt. > DNSSEC+DANE Schaue ich mir an. Ich könnte den Testserver auch an eine Domain binden und von dort auf den Testserver weiterleiten, aber wenn man da mit einem iframe oder so eine neue Verbindung direkt auf die dynamische IP baut, ist das auch nicht sicher bzw. der Browser wird sicherlich ein Zertifikat für diese IP verlangen. Oder alle Anfragen über sowas wie NoIP schicken? Bekommt man da für eine Subdomain ein Zertifikat? > Man kann selbst signierte Zertifikate auch > manuell im Browser hinterlegen. Das macht ja die Ausnahmeregel. Das Problem ist nur, daß man den interessierten Nutzer gar nicht darauf hinweisen kann, wozu er ggf. eine Ausnahmeregel braucht, weil er sofort beim ersten Kontakt mit der Seite auf eine unglaublich unsichere Seite hingewiesen wird. Außer man macht das per unverschlüsseltem HTTP und der User muß einmal auf ein OK klicken bevor auf die SSL-Verbindung kommt (was die Sicherheitswarnung erzeugt) und dann irgendwelche Daten eintragen kann. Lustigerweise wäre das DSGVO-konform solange kein Zertifikat einer Verifizierungsstelle verlangt wird. Allerdings ist absehbar, daß neue Browser spätestens in ein paar Jahren kein unverschlüsseltes HTTP mehr unterstützen bzw. gleich eine Sicherheitswarnung erzeugen. Das bringt's also nicht, man steht dann wieder vor dem gleichen Problem. > Das eine https-light Variante fehlt, die einfach als Ersatz für > http benutzt werden kann, ist mir aber auch schon > desöfteren aufgefallen. Genau sowas suche ich auch. Schützt wegen dem Schlüsselaustausch nicht vor MITM-Angriffen wenn der Verbindungsaufbau kompromittiert wird, aber danach ist die Verbindung sicher, sprich den reinen Datenstrom kann niemand mitlesen. Ich bin auch der Meinung, daß z.B. die NSA schon ihre Mittel haben wird, um selbst korrekt gesichterte und zertifizierte HTTPS-Verbindungen zu belauschen. Für eine so große Institution ist das Fälschen von Zertifikaten sicherlich möglich bzw. man bekommt beim MITM-Angriff auch ein gefälschtes, aber ebenfalls gültiges und als vertrauenswürdig eingestuftes Zertifikat untergeschoben. Also wirklich sicheren Schutz wie sich die verblendete DSGVO-Politik den wünscht, gibts wohl sowieso nur wenn das Zertifikat nicht über das Internet übertragen wird. Edit: HTTPS @home ist kein Problem. Da erstelle ich mir einfach ein selbstsigniertes Zertifikat, gültig bis zum Tag des jüngsten Gerichts und füge das als Ausnahmeregel in meinen Browser ein. Danach kann ich HTTPS@home testen wie ich will, aber für eine Verbindung von außen bzw. wenn man andere User von außen einladen will, funktioniert das nicht so gut bzw. alle diese User müssen auch erst diese Ausnahme zulassen ohne daß man ihnen mitteilen kann wieso die notwendig ist.
:
Bearbeitet durch User
Ben B. schrieb: >> DNSSEC+DANE > Schaue ich mir an. Ja aber das Problem ist eben, die Browser unterstützen das alle noch nicht, zumindest die, die ich kenne. Nur bei Dingen wie Mail kann man DANE momentan wirklich brauchen.
Hmm ok danke für den Hinweis. Also evtl. was für die Zukunft und keine Lösung für jetzt. Schade.
Ben B. schrieb: >> Es ergibt sich also die gleiche Sicherheit, >> wie ohne jegliche Verschlüsselung.. > Nicht ganz richtig. Ein MITM Angriff ist nur erfolgreich, wenn dieser > bereits den Verbindungsaufbau verfälscht hat. Meh, dann starte ich als MTIM-Angreifer sobald ich mitlesen will eine TLS Renegotiation. Das Argument taugt nicht.
... wogegen ein selbst signiertes Zertifikat wieder schützen würde. Man bräuchte halt irgend eine Möglichkeit, dem Benutzer beim Erstkontakt mitzuteilen wieso man ein selbst signiertes Zertifikat verwendet, wann er diesem vertrauen sollte und wann nicht. Das wäre für mich akzeptabel, was mich nervt ist, daß selbst signierte Zertifikate grundsätzlich abgeschmettert werden. Ich habe gerade mal ein wenig damit herumgespielt. Sobald die Ausnahme erstmal steht, funktioniert die Verbindung mit dem selbst signierten Zertifikat wunderbar. Hat jemand Lust herzukommen und einen MITM Angriff dagegen zu fahren? Kann den Server in ein offenes WLAN stellen...
Ich fände es schon gut, wenn in Browsern TOFU (trust on first use) in lokalen Netzen irgendwie einfacher wäre. "Hallo, wahrscheinlich verbinden sie sich zu ihrem Router oder IOT dingens. Wenn sie das zum ersten mal tun oder ein Gerät neu einrichten, dann können sie wahrscheinlich auf 'Zertifikat akzeptieren' klicken. Haben sie sich schon mehrfach mit dem Gerät verbunden, kann es sein, dass ein Angreifer in ihrem Heimnetz ihre Verbindung belauschen will."
Öh, hier muss mal einiges richtig gestellt werden: - https Verbindungen funktionieren IMMER mit Zertifikaten - Zertifikate KÖNNEN von Zertifizierungsstellen (CA) signiert werden. - Ist das Zertifikat von einer CA signiert welcher der Browser vertraut wird das grüne Schloss angezeigt. - Zertifizierungsstellen werden von Browserherstellern (gegen viel Geld und hoffentlich Prüfung) in Browsern eingetragen. - Ein signiertes Zertifikat lediglich sicher, dass sein Inhaber einmal (gegenüber der CA) nachgewiesen hat der rechtmäßige Inhaber der Adresse die zertifiziert wurde ist. - Ein Zertifikat kann selbstsigniert sein. Da es dann nicht von dritter Stelle signiert wurde, wird die bekannte Warnung angezeigt. - Du kannst eine eigene zertifikzierungsstelle aufmachen, musst dann aber sicherstellen, dass du diese selbst an die Browser verteilst. - I.d.R. werden Zertifikate auf DNS Namen vergeben, die IP darf sich darunter ändern.
Bringt mir nicht viel, wenn das nur in lokalen Netzen möglich ist. Wie gesagt, im heimischen LAN kann ich das Problem mit einem Mausklick beheben (wenn ich mich vorher um das Zertifikat gekümmert habe) bzw. ab und an muß ich ggf. ein neues Zertifikat erstellen. Man bräuchte so eine Info-Seite für alle selbstsignierten Zertifikate, ggf. mit der Möglichkeit, daß die angeforderte Seite dort ein Textfeld füllen kann und den Grund für die schwächere Verbindungssicherheit erklären kann. Die Frage ist ja auch was will ein Angreifer mit der Kommunikation meines Testservers. Das bringt ihm nur was wenn der Benutzer weitere grobe Fehler begeht wie z.B. überall das gleiche Kennwort zu verwenden. Internet-verfügbare Admin-Tools sind keine drauf, der kommt von außen noch nicht mal an die MySQL-Datenbank dran. Naja ich schaue mir mal NoIP zusammen mit Let's Encrypt an.
Ben B. schrieb: > Man bräuchte halt irgend eine Möglichkeit, dem Benutzer beim Erstkontakt > mitzuteilen wieso man ein selbst signiertes Zertifikat verwendet, wann > er diesem vertrauen sollte und wann nicht. Das wäre für mich akzeptabel, > was mich nervt ist, daß selbst signierte Zertifikate grundsätzlich > abgeschmettert werden. Herzlichen Glückwunsch, du hast das Problem der CA erfasst ;) Nicht böse gemeint, aber das ist doch genau der Punkt. Klar: "selbst-signiert und ich sage dem Nutzer auf anderem Wege was die richtige Certificate ID ist" ist perfekt. Das ist sogar noch besser als mit CA. Es gibt ja auch die technische Umsetzung dafür: entweder dieses spezifische Zertifikat im Browser akzeptieren, oder, falls es mehrere sein sollen, dem Benutzer auf anderem Wege ein CA Cert zukommen lassen, dem er vertrauen kann. Aber irgendwie musst du's halt machen. Und die CA-Listen in den Browsern sind die sternförmige Variante, bei der sich nicht jeder Endnutzer selbst Gedanken machen muss.
:
Bearbeitet durch User
Dank Let's encrypt gibt es heute keinen wirklichen Grund für selbssignierte Zertifikate für Zeug mit (sub)Domain mehr. Sein IOT Geraffel hängt man hoffentlich nicht direkt ans Netz, da könnte ich noch akzeptieren, dass man nicht alle paar Wochen das Zertifikat erneuern will. Sicherer ist selbssigniert auch nur in sehr speziellen Szenarien. Wenn man Leute dazu bringt, jedes selbssignierte Zertifikat zu akzeptieren, schwächt das auf jeden Fall die Sicherheit. Mehr Sicherheit erreicht man dadurch, dass man dem Browser mitteilt, welche CA signieren darf und die Zertifikate ordentlich gepinnt werden sollen.
Ich will den Benutzer gar nicht dazu bringen, daß er JEDES selbstsignierte Zertifikat ohne Überlegen akzeptiert. Die optimale Lösung wäre für mich wenn man z.B. keine grüne sondern bspw. eine gelbe Adresszeile bekommt, die den Benutzer darauf hinweist, daß hier zwar die Verschlüsselung aktiv ist, aber die Herkunft der Seite nicht sicher nachgewiesen wird. Der nicht-DAU weiß dann okay, für ein Online-Spiel oder eMail-Adresse akzeptabel, aber für Bankgeschäfte vielleicht nicht.
Ben B. schrieb: > daß hier zwar die Verschlüsselung aktiv ist, aber die Herkunft der Seite > nicht sicher nachgewiesen wird. Der nicht-DAU weiß dann okay, für ein > Online-Spiel oder eMail-Adresse akzeptabel, aber für Bankgeschäfte > vielleicht nicht. Es tut mir Leid aber du hast den Punkt nicht verstanden. Das ist einfach nicht der Fall. Das wie auch immer geprüfte Zertifikat ist nötig, um irgendeine Art von Sicherheitsgewinn zu erreichen. Ohne Zertifikatsprüfung kommunziert der Client zwar verschlüsselt mit "der Außenwelt" -- aber er weiß nicht, mit wem! Das bringt genau nichts. Ich weiß, dass es so wirkt, als ob es ein Unterschied wäre, weil es irgendwie komplizierter klingt dagegen einen Angriff zu fahren. Das ist aber in der Praxis völlig egal, weil der Angreifer eh $script aus dem Internet benutzt. Ob das etwas kompliziertes oder etwas einfaches tut, spielt keine Rolle -- entweder es geht prinzipiell nicht oder du hast nichts gewonnen.
DPA schrieb: > Der einzige ort, wo reverse DNS in seltenen Fällen verwendet wird, sind > ein paar wenige E-Mail Anbieter. IPSEC-VPNs tun das auch, können zumindest so konfiguriert werden. Gegen MITM hilft das aber natürlich exakt garnicht. Zertifikate aber übrigens auch nicht, wie man ja leicht an den "Sicherheitslösungen" sehen kann, die in allen größeren und zunehmend auch in kleinere Firmen an den Bordergateways werkeln. Um die zu enttarnen, müsste man schon das Zertifikat jeder besuchten Webseite genau untersuchen. Wer macht das schon im Alltag? (Mal abgesehen davon, dass schätzungsweise 99% der Leute nicht mal wüßten, wo und wie sie das tun müssten). Zertifikate (insbesondere in der Form von Zertifikatshierarchien, die man nicht selber kontrolliert) sind ein Irrweg. Die lösen kein Problem, sondern schaffen nur das Problem gefühlter Sicherheit. Die einzige Zertifikatshierarchie, der ich wirklich traue, ist die, deren CA ich selber verwalte. Und das auch nur, wenn ich obendrein auch noch alle Zwischenzertifizierungsstellen dieser Hierarchie selbst kontrolliere...
Ich finde CAs in ihrer gegenwärtigen Form auch nicht ideal, aber man muss schon auf dem Teppich bleiben -- so ein Cert für "mikrocontroller.net" zu bekommen, dem Firefox vertraut, ist schon ein ordentliches Hindernis. Eher denke ich, dass man Maßnahmen wie Certificate Pinning o.ä. noch stärker in die Browser einbinden könnte.
Sven B. schrieb: > Ich finde CAs in ihrer gegenwärtigen Form auch nicht ideal, aber man > muss schon auf dem Teppich bleiben -- so ein Cert für > "mikrocontroller.net" zu bekommen, dem Firefox vertraut, ist schon ein > ordentliches Hindernis. Das ist aber tatsächlich recht einfach. Machen die genannten "Sicherheitslösungen" millionenfach. Nicht nur für mc.net, sondern für absolut jede Webseite. Alles was dafür nötig ist: Kontrolle über das Gateway (also MITM-Position) und das Einpflegen des CA-Zertifikats in die Systeme der Endnutzer. In Firmen ist das für die Admins natürlich sowieso kein Problem, aber auch bei unbedarften Privatnutzern dürfte es Malware nicht sehr schwer fallen, entsprechende Mechanismen direkt auf dessen Maschine zu installieren. Im Prinzip sind da nur drei Sachen nötig: einen Proxy laufen lassen (geht ohne Admin/root), den Browser dazu zu bringen, diesen Proxy zu benutzen (geht ohne Admin/root) und letztlich, das CA-Zertifikat im System zu verankern. Letzteres ist der einzige Punkt, den man nicht mit normalen Benutzerrechten realisieren kann. Aber, da die meisten nunmal Windows benutzen und ein Klick auf den OK-Button der UAC im Schlaf beherrschen und jederzeit völlig kritiklos ausführen, ist auch das nicht wirklich ein Problem... Bei Linux ist es schon etwas schwieriger, aber auch nicht sehr viel. Wenn man Linux einen User mit ähnlicher Kompetenz wie der des gemeinen Windows-Users verpasst, ist es praktisch auch genauso angreifbar. Nur der Aufwand für den Angreifer wird etwas höher.
c-hater schrieb: > und das Einpflegen des CA-Zertifikats in > die Systeme der Endnutzer. Jo super. Dann ist eh alles vorbei. Das ist keine sinnvolle Diskussionsgrundlage ...
DPA schrieb: > Nein, dann würde keine meiner Webseiten mehr funktionieren, und so > ziemlich jedere andere Webseite auch nicht mehr. Und Rolf M. schrieb: > Wäre das so, dann würde Letsencrypt zusammen mit DDNS nicht > funktionieren, was es aber tut. Ja, dann viel Spaß, wenn sich jemand via IP-Adresse verbindet.
1 | In some cases, the URI is specified as an IP address rather than a |
2 | hostname. In this case, the iPAddress subjectAltName must be present |
3 | in the certificate and must exactly match the IP in the URI. |
https://tools.ietf.org/html/rfc2818#section-3.1 Java-Implementierungen machen dann, soweit ich das mitbekommen habe, immer noch einen reverse lookup. Ob das Sinn macht oder nicht war eigentlich nicht der Punkt. Browser werden den Namen wohl gecacht haben, wenn man sich einmal darüber verbunden hat.
Ben B. schrieb: > Da beißt sich die Katze in den > Schwanz wenn die unsicherere Verbindung vertrauenswürdiger erscheint als > eine SSL-geschützte Verbindung mit selbst signiertem Zertifikat. TLS geht nicht ohne Zertifikat. Du kannst aber natürlich Deine eigene CA machen und das Root-CRT dem Zertifikatsspeicher Deines OS hinzufügen. Ben B. schrieb: > ich bin > mir nur unsicher, ob man nach der Datenscheißgrundversauung noch sowas > eMail-Adressen oder Kennwörter unverschlüsselt übertragen darf wenn man > einen privaten nicht-kommerziellen Server betreibt. Nein, darf man nicht. Und das ist gut so. oszi40 schrieb: > 1. irgendwann ABLAUFEN und erneuert werden müssen wenn es ewig > funktionieren soll. Nichts hindert Dich daran, mit Deiner eigenen CA Zertifikate für Jahrzehnte auszustellen. Das sollte den meisten ausreichen. Heiko L. schrieb: > Nein. Zur Prüfung des Zertifikats gehört ein Reverse-IP-Lookup, um > sicherzustellen, dass der Kommunikations-Partner auch der ist, für den > das Zertifikat gilt. Absoluter Blödsinn. DPA schrieb: > Der einzige ort, wo reverse DNS in seltenen Fällen verwendet wird, sind > ein paar wenige E-Mail Anbieter. Momentan weiss ich nur von AOL und GMX, > andere Anbieter, wie z.B. G-Mail, Hotmail/Outlook, Swisscom, Quickline, > die meisten privaten Mailserver, Mailing listen (dyne.org, > vger.kernel.org, etc.), prüfen reverse DNS nicht. (Ich weiss das, weil > ich einen eigenen privaten Mail Server habe, aber mein ISP (Quickline), > Reverse-DNS nur mit teuren Business Packeten anbietet, und den Blödsinn > mach ich nicht mit. Es gäbe zwar noch andere Wege, an ne IP mit Reverse > DNS ran zu kommen, aber das kostet halt auch.). Reverse DNS sollte man > endlich mal abschaffen. Bitte was? PTR wird nur in seltenen Fällen verwenden? Setzt doch mal einen richtigen MTA auf ohne PTR und bereite Dich dann auf die erbosten Anrufe der Kunden vor, deren Mails im Spam landen. Aber was weiß ich schon, ich administriere ja nur Mailserver für einige Tausend Domains...
bofh schrieb: > Absoluter Blödsinn. Ja, die Welt ist voll davon. https://github.com/spray/spray/issues/993 https://stackoverflow.com/questions/3193936/how-to-disable-javas-ssl-reverse-dns-lookup https://issues.apache.org/jira/browse/KAFKA-5051 ... Dabei ist das doch ganz klar: Wenn die Adresse in dem Fall nicht im Zertifikat steht, war es das.
:
Bearbeitet durch User
Also ein Zertifikat für eine .de Domain zu bekommen ist nun wirklich keine Kunst. Aber dann hat man die Domain und einen irgendwo gehosteten (V)Server, zum Programmieren macht sich das eher schlecht. Außer man stellt eine dedizierte Kiste in irgendein Rechenzentrum und geht da mit einem VPN-Tunnel oder so drauf, aber soviel mag ich nicht bezahlen. > Es tut mir Leid aber du hast den Punkt nicht verstanden. Ich habe den Punkt schon verstanden. Ich grüble ja auch drüber was man machen könnte, damit man die Herkunft auch ohne Zertifikat belegen kann. Und in jedem Fall wird die Verbindung damit so sicher, wie sie beim ersten Kontakt mit der Seite war, bei dem das selbst signierte Zertifikat übermittelt wird. Wenn der Browser dieses für die Dauer der Gültigkeit speichert, sollte ein MITM-Angriff nicht mehr möglich sein, wenn der erste Kontakt sicher war. > deren CA ich selber verwalte Kannst Du mit einem selbst signierten Zertifikat ja machen. Solange dieses korrekt und nicht kompromittiert ist, halte ich so eine Verbindung für sicherer als 'ne grüne Adresszeile. Eine eigene CA aufzumachen bringt mir aber nicht viel, bzw. nur für meinen eigenen Laptop. Kein Browser kennt die CA und wird demzufolge auch nichts akzeptieren, was davon signiert worden ist - sobald ein anderer Mensch von draußen wegen was auch immer auf meine Seite will (und sei es nur ein Auftraggeber wegen Vorschlag anschauen) habe ich das gleiche Problem.
Ben B. schrieb: > Ich habe den Punkt schon verstanden. Ich grüble ja auch drüber was man > machen könnte, damit man die Herkunft auch ohne Zertifikat belegen kann. > Und in jedem Fall wird die Verbindung damit so sicher, wie sie beim > ersten Kontakt mit der Seite war, bei dem das selbst signierte > Zertifikat übermittelt wird. Wenn der Browser dieses für die Dauer der > Gültigkeit speichert, sollte ein MITM-Angriff nicht mehr möglich sein, > wenn der erste Kontakt sicher war. Absolut hoffnungslos. Den Public-Key per USB-Stick weitergeben. Sonst hat man nur die Wahl zwischen dem Trust-Store "Chrome Huawei Edition", "Firefox Patchlevel NSA-C3" oder gleich die offenen Sourcen aus irgendeinem Git. LOL!
Heiko L. schrieb: > Ja, die Welt ist voll davon. > > https://github.com/spray/spray/issues/993 "When connecting to a SSL server with the spray client by IP address" > https://stackoverflow.com/questions/3193936/how-to-disable-javas-ssl-reverse-dns-lookup "I faced this same problem today when I tried to create a SSL socket connection by IP address only" > https://issues.apache.org/jira/browse/KAFKA-5051 "Broker knows only client IP address." > ... > > Dabei ist das doch ganz klar: Wenn die Adresse in dem Fall nicht im > Zertifikat steht, war es das. So, was Du mir hier also erzählst ist, daß manche mit Java direkt an eine IP verbinden, Java einen PTR Query machen. Das ist immer noch absoluter Blödsinn, denn: 1. ist das ein Bug/Fetaure in Java und scheint nur Windows zu betreffen 2. man macht bei TLS üblicherweise einen Connect an die Domain 3. es wäre die IP im Zerifikat wenn der Beitreiber das so authorisiert Aus dem Fehlverhalten einer Programmiersprache auf einem Betriebssystem bei einem IP-Connect der so gar nicht explizit authorisiert ist darauf zu schließen, daß TLS PTR zwingend benötigt zeugt von einem komplett fehlendem Verständnis der Materie. Noch hanebüchener kann man so eine Behauptung ja kaum an den Haaren herbeiziehen. Ben B. schrieb: > Aber dann hat man die Domain und einen irgendwo gehosteten > (V)Server, zum Programmieren macht sich das eher schlecht. Mal so aus Interesse, was für Resourcen brauchst Du denn? Wenn es rein Hobby ist dann reicht auch eine Kiste im Keller. Wenn das beruflich ist, dann wird man doch nicht wegen ein paar €/Monat diesen Aufwand treiben. Eine VM bekommt man nämlich schon für 1-3 €/Monat.
bofh schrieb: > So, was Du mir hier also erzählst ist, daß manche mit Java direkt an > eine IP verbinden, Java einen PTR Query machen. Sollte heissen: So, was Du mir hier also erzählst ist, daß manche mit Java direkt an eine IP verbinden, und Java dann einen PTR Query macht.
bofh schrieb: > Aus dem Fehlverhalten einer Programmiersprache auf einem Betriebssystem > bei einem IP-Connect der so gar nicht explizit authorisiert ist darauf > zu schließen, daß TLS PTR zwingend benötigt zeugt von einem komplett > fehlendem Verständnis der Materie. Wenn man per IP surft und keine IP im Zertifikat steht wird es aber wohl darauf hinaus laufen, dass man wenigstens den bräuchte. Es sei denn man hat einen Browser, der versucht, Requests einzusparen und deshalb irgendwo eine Hostname<->IP Tabelle führt :)
Ben B. schrieb: > Also ein Zertifikat für eine .de Domain zu bekommen ist nun wirklich > keine Kunst. Aber dann hat man die Domain und einen irgendwo gehosteten > (V)Server, zum Programmieren macht sich das eher schlecht. Irgendwie musst du ein anderes Internet haben als ich. Meine .de Domain landet auf dem Server der bei mir im Flur steht, keine 10m von mir entfernt momentan. Der bietet ein paar Services, Subdomains und sonstige Spielereien an, alles wunderbar mit Lets Encrypt verschlüsselt. Wenn man nicht genau hin schaut, weiß man als Besucher der Dienste nicht das die Kiste in meiner Wohnung statt im Rechenzentrum steht.
> Mal so aus Interesse, was für Resourcen brauchst Du denn? Ich habe beides, sowohl die "Kiste im Keller" als ein bißchen Webspace mit Domain im Netz. Was ich im Moment nicht habe und dann wohl brauche ist ein NoIP-Account. Nach der Verkommerzialisierung und der damit einhergehenden Vertreibung aller kostenlos betriebenen Accounts von DynDNS hatte ich mir was vergleichbares selbstgestrickt, aber ohne "echtes DNS". Es war einfach nur eine Seite, auf der ich analog zu DynDNS meine dynamische IP hinterlegt hatte und die Seite einfach in einen iFrame geladen habe. Hat wunderbar funktioniert, über Jahre hinweg - aber eben ohne SSL. > Irgendwie musst du ein anderes Internet haben als ich. Mag sein, vielleicht hat irgendwer mein altes gelöscht. > Meine .de Domain landet auf dem Server der bei mir im Flur steht, > keine 10m von mir entfernt momentan. [..] Wie gesagt, hatte ich über Jahre auch so, aber eben ohne den ganzen SSL-Scheiß --- den ich jetzt dank DSGVO brauchen werde wenn ich mich an die Kacke halten möchte.
Ben B. schrieb: > den ganzen SSL-Scheiß Es sind z.B. heute schon übermäßige viele Zertifikate im Browser vorhanden. Kennt Ihr die alle??? Bei der Menge der sich bald inflationär ansammelden Zertifikate werden wir später mal kräftig aufräumen müssen, da sich garantiert auch FAULE EIER einnisten, wenn jeder User sich noch 1000 selbst signierte herunterladen muß damit irgendwas funktioniert! Sparsamkeit wäre hilfreich (wobei ich aber nicht jeder CA vertraue).
Wenn der TE ein selbstsigniertes Zertifikat erstellt, dies in sein Browser importiert, so hat er eine sehr gute Sicherheit! Nur Browser ohne Import fangen an zu meckern. Aber dafür gibts ja den Import.
Lona schrieb: > Aber dafür gibts ja den Import. Das ist normal. Nur wenn der übliche User für jede Webseite 1x ja drückt sind garantiert 100 DAUs dabei, die auch die dümmsten Fragen aus Gewohnheit mit ja beantworten und die dümmsten Zertifikate herunterladen oder schon haben?
oszi40 schrieb: > Es sind z.B. heute schon übermäßige viele Zertifikate im Browser > vorhanden. Kennt Ihr die alle??? Ich hab grad mal ein "realpath /etc/ssl/certs/* | sort -u" gemacht. Ist schon etwas beunruigend... Hongkong_Post_Root_CA_1.crt, Amazon_Root_CA_1.crt, Deutsche_Telekom_Root_CA_2.crt, Staat_der_Nederlanden_Root_CA, ... Sind vermutlich bei weitem nicht die schlimmsten, aber ob ich denen Trauen würde...
oszi40 schrieb: > Lona schrieb: >> Aber dafür gibts ja den Import. > > Das ist normal. Nur wenn der übliche User für jede Webseite 1x ja drückt > sind garantiert 100 DAUs dabei, die auch die dümmsten Fragen aus > Gewohnheit mit ja beantworten und die dümmsten Zertifikate herunterladen > oder schon haben? Das kann ihm aber egal sein, solange er ein Zertifikat hat das sicher ist!
Ben B. schrieb: > Es war einfach > nur eine Seite, auf der ich analog zu DynDNS meine dynamische IP > hinterlegt hatte und die Seite einfach in einen iFrame geladen habe. Hat > wunderbar funktioniert, über Jahre hinweg - aber eben ohne SSL. Wenn du den Server auf dem die Seite mit dem iFrame gehostet ist kontrollierst kannst du das Problem lösen: - Der Server bekommt ein Letsencrypt Zertifikat - Anstelle des iframe beutzt du die Proxyfunktion des Webservers (zumindest bei Apache und NGINX kein Problem) um die Seite auszuliefern und https zu ergänzen.
DPA schrieb: > Sind vermutlich bei weitem nicht die schlimmsten, aber ob ich denen Trauen > würde... Wem würdest du denn trauen und auf welcher Basis?
Heiko L. schrieb: > Wenn man per IP surft und keine IP im Zertifikat steht wird es aber wohl > darauf hinaus laufen, dass man wenigstens den bräuchte. Es sei denn > man hat einen Browser, der versucht, Requests einzusparen und deshalb > irgendwo eine Hostname<->IP Tabelle führt :) Willkommen in 2019. Mit IP zu surfen ist seit mindestens 1987 tot als das Konzept von Domainnamen eingeführt wurde. Noch töter wurde es vor fast 16 Jahren, als SNI eingeführt wurde um dem IPv4 Mangel entgegenzuwirken. Und übrigens hat jedes OS so eine Tabelle... Ben B. schrieb: > Wie gesagt, hatte ich über Jahre auch so, aber eben ohne den ganzen > SSL-Scheiß --- den ich jetzt dank DSGVO brauchen werde wenn ich mich an > die Kacke halten möchte. Wo ist das Problem? Du holst für Deine Domain ein ganz normales LE Zertifikat. Deinem iFrame gibt's Du eine Subdomain mit LE und mappst die auf einen vhost, der die Anfragen via mod_proxy an Deinen lokalen Rechner weitergibt. Oder Du machst es besser und setzt ein ordenliches OVPN auf, damit Du das docroot mounten kannst und alles verschlüsselt bleibt. Aber Leute die bei der DSGVO einen Beißreflex entwicklen ist eh nicht zu helfen. DPA schrieb: > Ich hab grad mal ein "realpath /etc/ssl/certs/* | sort -u" gemacht. Ist > schon etwas beunruigend... Hongkong_Post_Root_CA_1.crt, > Amazon_Root_CA_1.crt, Deutsche_Telekom_Root_CA_2.crt, > Staat_der_Nederlanden_Root_CA, ... Sind vermutlich bei weitem nicht die > schlimmsten, aber ob ich denen Trauen würde... Diese Root-CAs sind per se nicht negativ. Gucken muß Du, was die damit signieren dürfen. Solange AMZ nur Zerifikate für AMZ Domains signieren kann, was soll's?
bofh schrieb: > Diese Root-CAs sind per se nicht negativ. Gucken muß Du, was die damit > signieren dürfen. Solange AMZ nur Zerifikate für AMZ Domains signieren > kann, was soll's? Das oben sind alles Root CAs, dürfen alles signieren...
DPA schrieb: > Das oben sind alles Root CAs, dürfen alles signieren... https://tools.ietf.org/html/rfc5280#section-4.2.1.10
bofh schrieb: > Willkommen in 2019. Mit IP zu surfen ist seit mindestens 1987 tot als > das Konzept von Domainnamen eingeführt wurde. Jo - es sei denn, man hat mit EDV zu tun. Faktischer Zustand 2019: Es funktioniert nichts. Dauernd ist irgendetwas kaputt und ständig fehlen die root-Zertifikate für X.Y.Z. Im Allgemeinen ist das Internet völlig kaputt! 2019... man zähle doch nur mal die Script-Fehler beim Surfen durch. OMFG! Es gibt keine einzige fehlerlose Seite mit mehr als ein paar Textzeilen drauf! Und du meinst, dass mit dynamischer IP Adresse und SSL-Zertifikat via SNI RFC-Konform hinzubekommen. Klaaaar.
:
Bearbeitet durch User
Heiko L. schrieb: > Jo - es sei denn, man hat mit EDV zu tun. > Faktischer Zustand 2019: Es funktioniert nichts. Dauernd ist > irgendetwas kaputt und ständig fehlen die root-Zertifikate für X.Y.Z. Zeig doch mal ein paar Seiten, wo den Besuchern die Root-CAs fehlen. Und ich meine damit nicht self-signed CAs, die noch niemals für alle funkionierten. > Im > Allgemeinen ist das Internet völlig kaputt! 2019... man zähle doch nur > mal die Script-Fehler beim Surfen durch. OMFG! Es gibt keine einzige > fehlerlose Seite mit mehr als ein paar Textzeilen drauf! Ist damit automatisch alles kaputt, was mit Programmieren zu tun hat, weil ein paar Idioten Fehler machen? Oder gilt das nur bei JS? Oder hast vielleicht nur Du diese Probleme? Ich meine, wenn Dir auch überall Root-CAs fehlen... > Und du meinst, dass mit dynamischer IP Adresse und SSL-Zertifikat via > SNI RFC-Konform hinzubekommen. Klaaaar. Ja. Tut mir leid wenn das Kompetenz und Horizont bei Dir übersteigt.
bofh schrieb: > Zeig doch mal ein paar Seiten, wo den Besuchern die Root-CAs fehlen. Solche Geschichten hatten wir massenweise mit dem Zahlungsanbieter eines unserer Kunden. Alte Clients - konnten nicht updaten. Ist schon blöd. bofh schrieb: > Ist damit automatisch alles kaputt, was mit Programmieren zu tun hat, > weil ein paar Idioten Fehler machen? Oder gilt das nur bei JS? Oder hast > vielleicht nur Du diese Probleme? Ich meine, wenn Dir auch überall > Root-CAs fehlen... Also einer unserer größeren Kunden hat letztes Jahr noch nachgefragt, ob man denn nicht seine WebAnwengung auf IE6 portieren könnte, weil er den Marktanteil in China signifikant genug empfand. Ich habe mit Web-Entwicklung nun nicht so schrecklich viel zu tun, aber das hat schon einige Diskussionen ausgelöst. Wurde nicht gemacht. bofh schrieb: > Ja. Tut mir leid wenn das Kompetenz und Horizont bei Dir übersteigt. Ich glaube ja, dass du in deinem Luftschloss solche Probleme schlicht nicht haben kannst. Viele Endkunden, viel komisches Zeug. Da kann man noch 10 mal sagen: Ja, die sollen gefälligst updaten. Der Umsatz ist trotzdem futsch.
:
Bearbeitet durch User
Heiko L. schrieb: > Ich glaube ja, dass du in deinem Luftschloss solche Probleme schlicht > nicht haben kannst. Naja, deine Perspektive ist aber auch etwas special. Also dass ständig überall alle Zertifikate kaputt wären ist schlicht nicht richtig. Dem Durchschnittsbenutzer passiert das kaum, behaupte ich.
Sven B. schrieb: > Also dass ständig > überall alle Zertifikate kaputt wären ist schlicht nicht richtig. Dem > Durchschnittsbenutzer passiert das kaum, behaupte ich. Naja, mit Google und Co - die Seite von meinem Hausarzt schmeißt auch Security-Warnings. Ordentliche Betriebssysteme halten sich natürlich aktuell. Es gibt aber immer Leute, die Updates deaktivieren, oder von irgendwelchen Herstellern schlicht keine Updates kriegen. Wegen sowas hatte ich erst kürzlich das Vergnügen, eine Kommunikation mit einem NT4(!) System ermöglichen zu dürfen. Das war so eine Drehmaschine, von der es hieß "Läuft noch astrein"...
Heiko L. schrieb: > bofh schrieb: >> Zeig doch mal ein paar Seiten, wo den Besuchern die Root-CAs fehlen. > > Solche Geschichten hatten wir massenweise mit dem Zahlungsanbieter eines > unserer Kunden. Alte Clients - konnten nicht updaten. Ist schon blöd. Working as designed. Alte Clients sollen ersetzt werden, nicht unterstützt. > bofh schrieb: >> Ist damit automatisch alles kaputt, was mit Programmieren zu tun hat, >> weil ein paar Idioten Fehler machen? Oder gilt das nur bei JS? Oder hast >> vielleicht nur Du diese Probleme? Ich meine, wenn Dir auch überall >> Root-CAs fehlen... > > Also einer unserer größeren Kunden hat letztes Jahr noch nachgefragt, ob > man denn nicht seine WebAnwengung auf IE6 portieren könnte, weil er den > Marktanteil in China signifikant genug empfand. Aua. > Ich habe mit Web-Entwicklung nun nicht so schrecklich viel zu tun, aber > das hat schon einige Diskussionen ausgelöst. Wurde nicht gemacht. Das ist auch gut so. IE6 ist EOL 2016-01-12, d.h. seit fast drei Jahren ohne Support. So etwas unterstützt man nicht, man denkt eher darüber nach, so etwas explizit auszuschliessen (möglichst mit einem deutlichen Hinweis auf den fehlenden Support für den veralteten Client). > bofh schrieb: >> Ja. Tut mir leid wenn das Kompetenz und Horizont bei Dir übersteigt. > > Ich glaube ja, dass du in deinem Luftschloss solche Probleme schlicht > nicht haben kannst. Viele Endkunden, viel komisches Zeug. > Da kann man noch 10 mal sagen: Ja, die sollen gefälligst updaten. Der > Umsatz ist trotzdem futsch. Das macht nichts, Umsatz ist nicht alles. Am Ende soll ja Gewinn über bleiben, und von dem knabbert der überhöhte Supportaufwand für veraltete Clients (ja, ich habe in dem Sektor lange genug gearbeitet ...) unangenehm viel weg. Manchmal ist es eben besser, sich von unrentablen Kunden zu trennen, insbesondere wenn diese nicht lernwillig sind. Oder würdest du auch heute noch Kunden mit IE5 unter WinXP unterstützen wollen?
Heiko L. schrieb: > Wegen sowas hatte ich erst kürzlich das Vergnügen, eine Kommunikation > mit einem NT4(!) System ermöglichen zu dürfen. Das war so eine > Drehmaschine, von der es hieß "Läuft noch astrein"... Sowas ist ein Spezialfall; wissenschaftlich-technisches Equipment mit eingebautem Rechner hat eben ein bisschen eigene Regeln. Ich würde sagen: auf sowas gehört außer Benutzername/Passwort kein Security-Kram, das muss eben in einem VPN leben. Das System für die ausgelegte Lebensdauer (von sagen wir mal 30-40 Jahren) sicherheitstechnisch in Ordnung zu halten ist nicht realistisch.
Ralf D. schrieb: > Das macht nichts, Umsatz ist nicht alles. Am Ende soll ja Gewinn über > bleiben, und von dem knabbert der überhöhte Supportaufwand für veraltete > Clients (ja, ich habe in dem Sektor lange genug gearbeitet ...) Schlechte Argumentation. Auch wenn man nur 1-2 Tage da reinstecken müsste, sollte man es trotzdem nicht machen. Workarounds schädigen das Design. Das aber verkauft sich schlecht. Ralf D. schrieb: > IE6 ist EOL 2016-01-12, d.h. seit fast drei Jahren ohne Support. So > etwas unterstützt man nicht, man denkt eher darüber nach, so etwas > explizit auszuschliessen (möglichst mit einem deutlichen Hinweis auf den > fehlenden Support für den veralteten Client). Klar. Verstehen tue ich das. Ralf D. schrieb: > Manchmal ist es eben besser, sich von unrentablen Kunden zu trennen, > insbesondere wenn diese nicht lernwillig sind. Das Problem ist, für uns ist eigentlich jegliche Arbeit rentabel. Wir machen ja nur die Software für die. Wir müssen denen eher verkaufen, dass, auch wenn kurzfristiger Gewinn winkt, man sich längerfristig Probleme schafft. Oder dass man sich dicht an der Grenze der Fahrlässigkeit bewegen würde...
Ben B. schrieb: >> Nein, darfst Du nicht. Persönliche Userdaten haben nichts mit >> gewerbsmäßigem Handeln zu tun. > Sehe ich prinzipiell genau so, dann bliebe wohl die Frage wie schafft > man es, daß die DSGVO für einen Testserver (auf dem bspw. selbst > entwickelte Internetseiten mit Login-Funktionen getestet bzw. > geschrieben werden) nicht gilt? Indem er nur einem abgeschlossenen Nutzerkreis zugänglich gemacht wird, sprich den Testern. Am simpelsten machst Du das mit http-auth in der htaccess. Das läßt eigentlich nur noch die IP als ausdrücklich gesetzlich definiertes persönliches Datum über, und die Logfiles kann man automatisiert nach einem Monat löschen. Insbesondere bei einem Testserver. Aber eigentlich würde man einen Testserver auch nicht ins Internet hängen, sondern der sollte im Intranet sein. Schon deswegen, damit Pentester eventuelle Sicherheitslücken aufdecken können, bevor die Hacker es tun. Und daß während der Entwicklung phasenweise auch mal Scheunentore offenstehen, ist ja eh normal.
Heiko L. schrieb: > Ralf D. schrieb: >> Manchmal ist es eben besser, sich von unrentablen Kunden zu trennen, >> insbesondere wenn diese nicht lernwillig sind. > > Das Problem ist, für uns ist eigentlich jegliche Arbeit rentabel. > Wir machen ja nur die Software für die. Für die müsst ihr aber auch sicherlich Support liefern und ggfls. für Fehler haften. Und da wird das dann mit überholter Client-Sofrtware unlustig. > Wir müssen denen eher verkaufen, > dass, auch wenn kurzfristiger Gewinn winkt, man sich längerfristig > Probleme schafft. Oder dass man sich dicht an der Grenze der > Fahrlässigkeit bewegen würde... Und das kann auch euch treffen, wenn der Kunde nicht kompetent genug ist und ihr ihn nicht hinreichend beraten habt (oder diese zumindest nicht nachweisen könnt). Die Geschäftsbeziehung ist dann zwar eh hinüber wenn man sich vor Gericht trifft, aber das kostet eben auch Geld. Und wenn man es ganz genau nimmt, dann ist das ein Risiko, dass man auch der eigenen Bank gegenüber offenlegen muss wenn man Kredite haben will (da war ja mal was mit Basel II). Alles ekelhaft und möglichst zu vermeiden.
:
Bearbeitet durch User
Heiko L. schrieb: > Alte Clients - konnten nicht updaten. Ist schon blöd. Ja nun gut, daß es mit Windows 3.11 for Workgroups und aktuellen Root-CAs Probleme gibt, sehe ich sogar ein. Aber da kannst Du nicht dem Internet oder den Root-CAs die Schuld geben, sondern euch selber, bzw dem Kunden. Wahrscheinlich sind's noch mit mal die Zertifikate selber, sondern es wird zB TLS 1.2/3 nicht unterstützt. Heiko L. schrieb: > Ich glaube ja, dass du in deinem Luftschloss solche Probleme schlicht > nicht haben kannst. Viele Endkunden, viel komisches Zeug. > Da kann man noch 10 mal sagen: Ja, die sollen gefälligst updaten. Der > Umsatz ist trotzdem futsch. Ich habe viel mit Endkunden zu tun, und ich sage denen genau das: "Was Sie nutzen ist EOL, das supporten wir nicht". Dazu noch die Erklärung was sie sich damit sonst noch einbrocken und gut ist. Wenn der Kunde trotzdem seinen Server weiter laufen lassen will, auch gut. Dann bekommt er schriftlich daß wir jeden Support ablehen und die Kiste vom Netz getrennt wird sobald Abusemeldungen eingehen. Dadurch habe ich bisher noch keinen Kunden verloren. Übrigens, wenn auf solch alten Systemen, für die niemand mehr Updates liefert, personenbezogene Daten verarbeitet werden, dann kann es schnell Probleme wegen der DSGVO geben. Spätestens wenn es ein Leak gibt. Heiko L. schrieb: > Naja, mit Google und Co - die Seite von meinem Hausarzt schmeißt auch > Security-Warnings. Ich tippe einfach mal, daß Du "Mixed Content" Warnungen mit "unbekanntem Root-CA" verwechselst. Die Warnings haben schon ihren Grund.
Sven B. schrieb: > Also dass ständig > überall alle Zertifikate kaputt wären ist schlicht nicht richtig. Ständig nicht, aber auch bei M$ war mal eins abgelaufen, was recht viel Ärger zur Folge hatte, weil es wohl NICHT NUR einen User betraf!!! Manche Folgen überblickt man erst recht spät, wenn schon die halbe Welt betroffen ist. Jetzt Apple.com https://www.heise.de/mac-and-i/meldung/Abgelaufene-Sicherheitszertifikate-Wie-man-jetzt-neue-macOS-Installer-findet-4569853.html
bofh schrieb: > Wahrscheinlich sind's noch mit mal die Zertifikate selber, > sondern es wird zB TLS 1.2/3 nicht unterstützt. Amen. bofh schrieb: > Übrigens, wenn auf solch alten Systemen, für die niemand mehr Updates > liefert, personenbezogene Daten verarbeitet werden, dann kann es schnell > Probleme wegen der DSGVO geben. Spätestens wenn es ein Leak gibt. Och - Endnutzer können so ziemlich tun, was sie wollen. Kommt nur darauf an, wer seine Sorgfaltspflicht verletzt. Weißt du ja selbst. bofh schrieb: > Ich habe viel mit Endkunden zu tun, und ich sage denen genau das: "Was > Sie nutzen ist EOL, das supporten wir nicht". Dazu noch die Erklärung > was sie sich damit sonst noch einbrocken und gut ist. Wenn der Kunde > trotzdem seinen Server weiter laufen lassen will, auch gut. Denn wer eine Seite betreibt ist in der Verantwortung. Wer sie ansurft ist nur für sich selbst verantwortlich. Du siehst das Problem mit alten Clients? Wenn du dann sagst "Für alte Browser bieten wir keine Kompatibilität" sagt manch einer "Ok, nehmen wir nen anderen Hoster" bofh schrieb: > Ich tippe einfach mal, daß Du "Mixed Content" Warnungen mit "unbekanntem > Root-CA" verwechselst. Und ich hoffe, du verwechselst nicht "gültige Root-CA" mit Symantec
:
Bearbeitet durch User
Heiko L. schrieb: > Ja, dann viel Spaß, wenn sich jemand via IP-Adresse verbindet. Was ist eigentlich ein DNS Reverse Lookup?
Sheeva P. schrieb: > Was ist eigentlich ein DNS Reverse Lookup? 192.168.1.1 sehr zuverlässig, da tausendfach vorhanden?
Heiko L. schrieb: > Denn wer eine Seite betreibt ist in der Verantwortung. Jein. Wenn ein Kunde seine Seite auf Deiner Infrastruktur betreibt, bist auch Du mit verantwortlich. Stichwort Auftragsverarbeitung. Heiko L. schrieb: > Wenn du dann sagst "Für alte Browser bieten wir keine Kompatibilität" > sagt manch einer "Ok, nehmen wir nen anderen Hoster" Unterstützte Browser sind in erster Linie Sache des Webmasters. Was ich aber sicher niemals machen würde ist zB RC4 wieder zu aktivieren, weil ein Kunde Besucher mit Netscape nicht aussperren will. Wie willst Du sowas anderen Kunden erklären, denen Sicherheit wichtig ist? Solche Kunden lasse ich gerne gehen; die sollen sich einen unfähigen Hoster suchen dem Sicherheit scheissegal ist. Und meiner Erfahrung nach ist es plötzlich garnicht mehr nötig, Uraltbrowser zu supporten wenn man vom Kunden eine schriftliche Einverständiserklärung einfordert, in der er die volle Verantwortung für Schäden aus diesen Lücken übernimmt. Heiko L. schrieb: > Und ich hoffe, du verwechselst nicht "gültige Root-CA" mit Symantec Symantec. lol, der war gut.
Heiko L. schrieb: > Wenn du dann sagst "Für alte Browser bieten wir keine Kompatibilität" > sagt manch einer "Ok, nehmen wir nen anderen Hoster" Manche Kunden würden mit ihren Wünschen dermaßen viel Schaden anrichten, daß es besser ist, wenn sie woanders hingehen. Das sind nämlich auch genau die Kunden, die nicht bereit sind, für den Schaden dann auch aufzukommen.
bofh schrieb: > Und meiner Erfahrung nach ist es plötzlich garnicht mehr nötig, > Uraltbrowser zu supporten wenn man vom Kunden eine schriftliche > Einverständiserklärung einfordert Die Papierlage ist die eine Seite. Der Kunde, der mit einer einstmals teuren Maschine dasteht die andere Seite. Man sollte ihm aber erklären wie schnell das Licht aus sein Kann wenn Böses passiert. Es muß aber nix Böses passieren. Es brauch nach "nur" 30 Jahren sein Zertifikat ablaufen. Dann steht er plötzlich da. Diese Fälle sollte man vermeiden!
oszi40 schrieb: > Es muß aber nix > Böses passieren. Es brauch nach "nur" 30 Jahren sein Zertifikat > ablaufen. TLS-Zertifikate haben eine maximale Gültigkeitsdauer von zwei Jahren. Es ist gerade der Sinn der Verfallsdauer, daß man sie regelmäßig erneuern muß.
Nop schrieb: > TLS-Zertifikate haben eine maximale Gültigkeitsdauer von zwei Jahren. Hö? Nein. Du kannst da einstellen, was du willst. Mag sein dass gängige Root-CAs momentan keine mit längerer Gültigkeitsdauer ausgeben.
Sven B. schrieb: > Nop schrieb: >> TLS-Zertifikate haben eine maximale Gültigkeitsdauer von zwei Jahren. > > Hö? Nein. Du kannst da einstellen, was du willst. In selbsterstellten natürlich schon. Allerdings war die Browser-Mecker damit ja gerade der Punkt im Eingangsposting. > Mag sein dass gängige Root-CAs momentan keine mit längerer > Gültigkeitsdauer ausgeben. Das meinte ich.
oszi40 schrieb: > Die Papierlage ist die eine Seite. Der Kunde, der mit einer einstmals > teuren Maschine dasteht die andere Seite. Naja, die ist doch buchhalterisch längst abgeschrieben. Und wenn sie in dieser Zeit nicht das Geld für sich selber und einen mindestens gleichwertigen Nachfolger erwirtschaftet hat, hat der Betreiber einfach etwas falsch gemacht. So einfach ist das. Vermutlich hat sie sich aber längst armortisiert und auch längst das Geld für einen Nachfolger eingespielt. Es ist nur für den Betreiber geiler, die Kohle in die eigene Tasche zu stecken, statt wieder zu investieren... Naja, zumindest wenn er es schafft, das an der Steuer vorbei zu tun... Sprich: wenn ich solche "traurigen" Geschichten höre, weiss ich immer schon, wem ich gerne eine Steuerprüfung in's Haus wünsche...
c-hater schrieb: > Naja, die ist doch buchhalterisch längst abgeschrieben. Und wenn sie in > dieser Zeit nicht das Geld für sich selber und einen mindestens > gleichwertigen Nachfolger erwirtschaftet hat, hat der Betreiber einfach > etwas falsch gemacht. So einfach ist das. Also ich sehe kein Problem darin, eine angeschaffte Maschine zu betreiben, solange sie nutzbar ist, bzw bis sie kaputt geht. Das ist nicht nur im Sinne der Wirtschaftlichkeit, sondern auch nachhaltig, resourcen- und umweltschonender. Was aber nicht bedeutet, daß man Service und Wartung aussetzt. Und eventuelle Software aktuell zu halten, gehört dazu. Oder, wenn das nicht mehr geht, die Maschine vom LAN zu trennen und nur noch airgapped zu nutzen. Was ich viel kranker finde sind Leute, die mit Ende der Abschreibung einfach sinnlos den Maschinenpark entsorgen. Typisches BWL Gehabe.
bofh schrieb: > kein Problem darin, eine angeschaffte Maschine zu > betreiben, solange sie nutzbar Opas Hammer kann man auch in hundert Jahren noch benutzen. Eine Maschine durch ablaufende Zertifikate unbrauchbar zu machen ist eine große Umweltsünde würde Greta sagen! Meiner Meinung nach ist es bösartige Trennung von Besitz oder Eigentum. Es ist natürlich richtig, daß Technik auch aus Sicherheitsgründen weiterentwickelt werden muß. Aber wenn eine Firma Pleite geht, müssen doch nicht alle Maschinen sterben, nur weil eingesetzte "Sicherheitszertikate" verfallen! Single Point of Failure!
oszi40 schrieb: > Opas Hammer kann man auch in hundert Jahren noch benutzen. Aber nicht übers Netzwerk, weswegen er auch kein Zertifikat braucht. Genausowenig wie eine Maschine, die nicht übers Netzwerk erreichbar ist. > Aber wenn eine > Firma Pleite geht, müssen doch nicht alle Maschinen sterben, nur weil > eingesetzte "Sicherheitszertikate" verfallen! Dann erstellt man einfach neue. Übrigens, daß der TÜV an einem Neuwagen nach vier Jahren abläuft, bedeutet auch nicht, daß man den Wagen dann in die Schrottpresse geben muß.
Nop schrieb: > oszi40 schrieb: > >> Opas Hammer kann man auch in hundert Jahren noch benutzen. > > Aber nicht übers Netzwerk, weswegen er auch kein Zertifikat braucht. > Genausowenig wie eine Maschine, die nicht übers Netzwerk erreichbar ist. In 20 Jahren wird vermutlich auch Opas Hammer WLAN haben und am Internet hängen. Und sobald der Hersteller keine Updates mehr liefert, muss man den Hammer wegwerfen und einen neuen kaufen. Irgendwie scheint es inzwischen als selbstverständlich zu gelten, dass Geräte, die Elektronik enthalten, heute nicht mehr langlebig sind, sondern halt alle 2 Jahre weggeworfen und durch die Nachfolgeversion ersetzt werden. Und manch einer findet das nicht nur beim Handy normal, sondern auch bei Produktionsmaschinen für ein paar Hunderdtausend Euro. >> Aber wenn eine >> Firma Pleite geht, müssen doch nicht alle Maschinen sterben, nur weil >> eingesetzte "Sicherheitszertikate" verfallen! > > Dann erstellt man einfach neue. Übrigens, daß der TÜV an einem Neuwagen > nach vier Jahren abläuft, bedeutet auch nicht, daß man den Wagen dann in > die Schrottpresse geben muß. Da kann der Autohersteller aber auch nicht einfach sagen, dass das Auto nach 4 Jahren "TÜV" nicht mehr unterstüzt. Denn da ist es die Aufgabe des TÜV, auch mit 20 Jahre alten Autos zurecht zu kommen.
Rolf M. schrieb: > Da kann der Autohersteller aber auch nicht einfach sagen, dass das Auto > nach 4 Jahren "TÜV" nicht mehr unterstüzt. Denn da ist es die Aufgabe > des TÜV, auch mit 20 Jahre alten Autos zurecht zu kommen. Nein, ist es nicht. Es ist vielmehr die Aufgabe dessen, der ein neues TÜV-Siegel haben will, jegliche Zweifel des Prüfers zu zerstreuen. Bezüglich der Software für olle Maschinen bedeutet das: es steht dir frei, selber Updates für Schwächen der Software zu entwickeln. Aufgabe des TÜV-Prüfers wäre es nur, Informationen über bekannte Schwächen zu sammeln und dich dann zu befragen, ob und wie du die behoben hast... Hammerhart ist der TÜV-Prüfer, der dann auch noch einen Exploit für jede dieser Schwächen vorrätig hat, um deine Angaben zu überprüfen. Du könntest ja auch LÜGEN...
c-hater schrieb: > Rolf M. schrieb: > >> Da kann der Autohersteller aber auch nicht einfach sagen, dass das Auto >> nach 4 Jahren "TÜV" nicht mehr unterstüzt. Denn da ist es die Aufgabe >> des TÜV, auch mit 20 Jahre alten Autos zurecht zu kommen. > > Nein, ist es nicht. Es ist vielmehr die Aufgabe dessen, der ein neues > TÜV-Siegel haben will, jegliche Zweifel des Prüfers zu zerstreuen. Der TÜV muss das Auto prüfen, wenn ich da hingehe. Und wenn ich damit einem 10 Jahre alten Serienfahrzeug aufkreuze, muss die Abnahme möglich sein. Der TÜV kann nicht einfach seine Prüfverfahren durch neue ersetzen, mit denen man das alte Auto nicht mehr prüfen kann. Der Autohersteller kann auch nicht einfach sagen, dass ich ein neues Auto kaufen muss, weil das alte nicht mehr kompatibel zum aktuellen TÜV ist. Der TÜV hat dem Auto vor 10 Jahren eine Zulassung erteilt, also muss der TÜV auch heute noch in der Lage sein, zu prüfen, ob sich an dem Auto etwas verändert hat, durch das es die Voraussetzungen für die Zulassung nicht mehr erfüllt. > Bezüglich der Software für olle Maschinen bedeutet das: es steht dir > frei, selber Updates für Schwächen der Software zu entwickeln. Hier ging es aber nicht darum, sondern um ein System, das auf einmal nicht mehr den Vorgaben des TÜVs entspricht, ohne dass sich an diesem System irgendetwas geändert hätte. Lediglich das Prüfverfahren hat sich geändert und bewertet jetzt das System als mangelhaft.
:
Bearbeitet durch User
"Hammer-WLAN.exe has stopped working. Use Hammer-Oldschool.exe to fix the problem!"
Ben B. schrieb: > "Hammer-WLAN.exe has stopped working. Wenn bei MS dieses Zertifikat abgelaufen ist, dürfen Millionen User keinen Hammer mehr benutzen! 8-) Übliche MS-Zertifikate laufen maximal 30 Jahre.
Rolf M. schrieb: > Der TÜV muss das Auto prüfen, wenn ich da hingehe. Und wenn ich damit > einem 10 Jahre alten Serienfahrzeug aufkreuze, muss die Abnahme möglich > sein. Der TÜV kann nicht einfach seine Prüfverfahren durch neue > ersetzen, mit denen man das alte Auto nicht mehr prüfen kann. Der > Autohersteller kann auch nicht einfach sagen, dass ich ein neues Auto > kaufen muss, weil das alte nicht mehr kompatibel zum aktuellen TÜV ist. > Der TÜV hat dem Auto vor 10 Jahren eine Zulassung erteilt, also muss der > TÜV auch heute noch in der Lage sein, zu prüfen, ob sich an dem Auto > etwas verändert hat, durch das es die Voraussetzungen für die Zulassung > nicht mehr erfüllt. Falsch. Der TÜV prüft nur die bestehenden Vorgaben, er macht keine. Und bloß weil Dein Auto den Regeln von gestern nach ok war, muß es das nicht unbedingt auch Regeln von heute nach sein. Der Autohersteller wird Dir aber auch nicht bis zum Sankt Nimmerleinstag Dein Auto supporten. Irgendwann ist das Modell ausgelaufen und Du kannst mit Deinem Auto machen was Du willst; aber der Hersteller muß dann garnix mehr machen. Stell Dir einfach mal vor, morgen wäre Wahl und die Grünen bekämen 67% der Stimmen. Dann wird beschlossen daß Verbrenner ab 2020 nicht mehr am öffentlichen Straßenverkehr teilnehmen dürfen. Und obwohl sich an Deinem Auto absolut nichts geändert hat, bekommst Du keine Zulassung mehr.
bofh schrieb: > Falsch. Der TÜV prüft nur die bestehenden Vorgaben, er macht keine. Hab ich auch nicht behauptet. > Und bloß weil Dein Auto den Regeln von gestern nach ok war, muß es das > nicht unbedingt auch Regeln von heute nach sein. Doch, nach den Regeln von heute für Autos von gestern schon. Neue Autos mögen neuen Regeln unterliegen, aber die alten Autos werden weiterhin nach den Regeln beurteilt, die für sie von Anfang an gegolten haben. Das ist ja mit einer der Streitpunkte beim Diesel-Skandal gewesen. > Der Autohersteller wird Dir aber auch nicht bis zum Sankt Nimmerleinstag > Dein Auto supporten. Irgendwann ist das Modell ausgelaufen und Du kannst > mit Deinem Auto machen was Du willst; aber der Hersteller muß dann > garnix mehr machen. Muss er ja auch gar nicht. Zum TÜV kann ich auch gehen, ohne dass der Hersteller mir dafür extra Support leisten müsste. Das ist ja gerade der Punkt. > Stell Dir einfach mal vor, morgen wäre Wahl und die Grünen bekämen 67% > der Stimmen. Dann wird beschlossen daß Verbrenner ab 2020 nicht mehr am > öffentlichen Straßenverkehr teilnehmen dürfen. Und obwohl sich an Deinem > Auto absolut nichts geändert hat, bekommst Du keine Zulassung mehr. Ob das so zulässig wäre, ist fraglich.
bofh schrieb: > Falsch. Der TÜV prüft nur die bestehenden Vorgaben, Gründlich prüfen, hat man an dem TÜV-geprüfen, gebrochenen Staudamm gesehen. So ähnlich ist das übrigens auch mit einigen Zertifikaten wie man bei Heise lesen konnte. Beispiel "Sicherheitsfirma" Comodo https://www.heise.de/security/meldung/Zertifikats-Klau-Fatale-Sehschwaeche-bei-Comodo-3354229.html Kurzum: Wer ohne Zertifikate leben kann, hat weniger Probleme.
oszi40 schrieb: > Kurzum: Wer ohne Zertifikate leben kann, hat weniger Probleme. Und wer kann das? Du als Webmaster nicht, denn sobald es Logins oder Kontaktformulare gibt brauchst Du TLS zum Schutz Deiner Besucher; und aufgrund der DSGVO. Auch ist da noch Google, der bei TLS einen Bonus im Ranking vergibt. Selbst im Intranet der Firma würde ich mich nicht mehr darauf verlassen, daß TLS unnötig ist. Auch hier dürfte Dank der DSGVO diese Schutzmethode erforderlich sein. Zumal dort meines Wissens nach nicht zwischen LAN/WAN unterschieden wird. TLS ist kein Aufwand mehr und daher nicht entschuldbar. Ein wie im Artikel bestehender Bug bei der CA, der nur auf einen minimalen Kreis zutrifft, macht die Verschlüsselung immer noch besser als das Weglassen derselben.
bofh schrieb: > macht die Verschlüsselung immer noch besser als das Weglassen Für den Transport gebe ich Dir Recht. Für die Archivierung für die nächsten 100 Jahre sehe ich allerdings schwarz, weil irgendwann der Schlüssel fehlt. Nachdem ich schon mal einen alten Mietvertrag von 1941 gesucht habe, weiß ich daß man für Immobilien die Unterlagen 100 Jahre aufbewahren sollte.
Rudi Radlos schrieb: > Für den Transport gebe ich Dir Recht. Für die Archivierung für die > nächsten 100 Jahre sehe ich allerdings schwarz, weil irgendwann der > Schlüssel fehlt. Oder weil man keine kompatible Verschlüsselungssoftware mehr findet, die auf dann aktuellen Rechnern noch lauffähig wäre - und auch schon lange keiner mehr weiß, womit das überhaupt verschlüsselt war. Da hat man aber noch ganz andere Probleme, wie z.B. die Schnittstelle, über die das Medium angeschlossen werden muss. Dass es in 100 Jahren noch Rechner mit USB3-Anschluss und Unterstützung für FAT32 gibt, halte ich für unwahrscheinlich. Das ist das schöne an Papier. Dessen Kompatibilität bleibt erhalten. > Nachdem ich schon mal einen alten Mietvertrag von 1941 gesucht habe, weiß > ich daß man für Immobilien die Unterlagen 100 Jahre aufbewahren sollte. Wobei der Mietvertrag sicherlich auch nicht verschlüsselt war.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.