Zitat
Wann Kommt Endlich Ssl?
#106 _lustiger_affe_
geschrieben 04. Dezember 2009 - 19:36
Anzeige
#107 _The Grim Reaper_
geschrieben 04. Dezember 2009 - 19:38
So wenn man nicht alles selber macht. Habs jetzt einfach manuell eingebunden und siehe da - keine Meldung mehr.
Dieser Beitrag wurde von The Grim Reaper bearbeitet: 04. Dezember 2009 - 19:51
#108
geschrieben 04. Dezember 2009 - 19:53
Oder sind vielleicht Plugins installiert, die zur aktuellen FF Version nicht kompatibel sind, wo Du dann tricksen musstest, damit die laufen?
#109 _Iceweasel_
geschrieben 06. Dezember 2009 - 00:31
Zitat (TO_Webmaster: 04.12.2009, 09:32)
MfG TO_Webmaster
also meiner meinung wäre es genau das, was ein ssl ausmacht. das meine daten vollständig gesichert sind. in dem moment wo ich einen "unsicheren" cookie benutze, bietet es mir keinen durchgängigen schutz.
aber es ist nur so am rande - trotzdem danke für das ssl
#110
geschrieben 18. Januar 2016 - 13:46
#111
geschrieben 18. Januar 2016 - 14:00
#112
geschrieben 18. Januar 2016 - 14:25
Dieser Beitrag wurde von theincogtion bearbeitet: 18. Januar 2016 - 14:26
#113 _d4rkn3ss4ev3r_
geschrieben 18. Januar 2016 - 16:05
Kostenlose Zertifikate mittels letsEncrypt wird sich Winfuture ja wohl leisten können.
Akzeptiert werden die Zertifikate auch. Gibt also keinen Grund das nicht zu nutzen.
#114
geschrieben 18. Januar 2016 - 16:38
Das wird dann kryptographisch sichergestellt, ja. Bringt ja nicht viel, wenn man erst aufwendig bestätigt "ja ich bin das" und dann jegliche Relation dazu in die Tonne tritt.
Nicht mehr. Nicht weniger.
LE unterwandert das. Wenn ich jetzt:
1. DNS erfolgreich umbiege;
2. Mir ein LE-Zertifikat auf winfuture.de beschaffe;
3. Einen Webserver online bereitstelle, der über winfuture.de (wegen umgebogenen DNS) erreichbar ist;
dann ist das Endergebnis, daß jeder Webnutzer, der https://www.winfuture.de ansurft, auf MEINEM Rechner landet UND ein gültiges Zertifikat dafür hat UND wegen LE als rechtmäßiges Angebot eingestuft wird.
Das ist kein Sicherheitsloch, das ist SSL-Mißbrauch.
- Was ein RICHTIGES SSL-Zertifikat angeht, so wäre das natürlich zu begrüßen, aber dann müssen wir uns auch auf jede Menge MEHR Werbung gefaßt machen ODER kostenpflichtige Mitgliedschaft(soptionen) akzeptieren. Denn so ein Zertifikat ist NICHT billig.
Dieser Beitrag wurde von RalphS bearbeitet: 18. Januar 2016 - 16:41
#115
geschrieben 18. Januar 2016 - 16:52
Definitv wird dabei der Transportweg verschlüsselt.
http://www.computerw...tworten,3062972
Damit werden logindaten verschlüsselt übertragen.
#116 _d4rkn3ss4ev3r_
geschrieben 18. Januar 2016 - 16:55
Zitat (RalphS: 18. Januar 2016 - 16:38)
Warum sollen die Certs von letsEncrypt nicht RICHTIG seien?
Es sind keine Hobbymäßig selbst erstellten.
#117
geschrieben 18. Januar 2016 - 19:29
Zitat (d4rkn3ss4ev3r: 18. Januar 2016 - 16:55)
Es sind keine Hobbymäßig selbst erstellten.
Weil die Identitätsprüfung von Lets Encrypt für die Tonne ist.
Wenn du den DNS der Domain kontrollierst, ist das Zertifikat deins.
Nachzulesen hier: https://letsencrypt....rks/technology/
Dann doch lieber ein ehrliches Selfcert.
Zitat (theincogtion: 18. Januar 2016 - 16:52)
Definitv wird dabei der Transportweg verschlüsselt.
http://www.computerw...tworten,3062972
Damit werden logindaten verschlüsselt übertragen.
Die Frage ist nur: zu wem?
Daher muss ein SSL(oder meinetwegen auch TLS)-Zertifkat auch die Identität des Gegenübers sicherstellen.
SSL ohne Identätsprüfung ist Augenwischerei
Dieser Beitrag wurde von Sturmovik bearbeitet: 18. Januar 2016 - 19:34
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
#118
geschrieben 30. Januar 2016 - 23:29
#119
geschrieben 30. Januar 2016 - 23:49
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
#120
geschrieben 31. Januar 2016 - 00:00
Zitat (Ludacris: 30. Januar 2016 - 23:29)
Mh? Also entweder ist Dein Post widersprüchlich oder aber ich verstehe nicht, worauf Du antwortest.
- X509 in sich ist sicher, ja.
- Aber die Anbindung ist es nicht. Das läuft lediglich über einen String Match auf der Serverseite (CN im Zertifikat == FQDN) und schlimmer noch, das "Vertrauen" (im praktischen Sinn) wird von einem teilweise automatisch verwalteten "Trusted Root Certificates"-Store 'erledigt'.
- Weswegen ein simples DNS-Hijacking auf der Serverseite X509 wirkungslos macht.
- Und ein simples "tragen wir mal ne fragwürdige CA bei den vertrauenswürdigen Stammzertifizierungsstellen ein und schaun was passiert" auf Clientseite auch.
- Wenn wir uns dann noch ins Gedächtnis rufen, daß X509 per Design erlaubt, "Listeners" in Form von einer Art Data Recovery Agents zu konfigurieren - daß es also per Design ermöglicht wird, daß ein Dritter mitlauschen *darf*... sollte klar sein, daß Vertrauen für SSL nicht optional, sondern verbindlich und *erforderlich* ist und daß "jo da ist ein Schloß" alles ist außer ausreichend, sondern daß im Gegenteil man gesagt kriegen kann (und wird!) "Modulo geprüft? Nein? Na sowas, tut uns aber leid --- Ja? Gib mal her. ... Nee, das war nicht unserer. Echt, und da hast Du das GEPRÜFT und GESEHEN daß wir das nicht sind und hast aber TROTZDEM Deine TANs alle reingefüttert? Mann bist Du blöde, einself!".
Mit anderen Worten, SSL ohne zu wissen wer der andere ist ist nicht nur nutzlos, sondern sogar gefährlich, und nix anderes hat Sturmovik weiter oben geschrieben.
Dieser Beitrag wurde von RalphS bearbeitet: 31. Januar 2016 - 00:01