Moin, bin gerade dabei ein Webhosting Packet zusammenzustellen, dabei gibt es eine extra Option "Eigenes SSL-Certificate" für 25 dollar extra im Jahr. Für was brauch ich sowas? Gruß Jonas
>https.
Ja schon klar. Ich habs von der falschen Seite betrachtet, also von der
gewohnten Clientseite. Als Server brauch ich natürlich ein
Certificate...
Ok danke!
Nicht unbedingt. Man muss ja nur die Exception am client wegclicken...
jibi schrieb: > Als Server brauch ich natürlich ein > Certificate Das brauchst du nur wenn du dich gegenüber dem Client authentisieren möchtest oder musst, z.B. für Finanztransaktionen, Shopbestellungen usw.. Wenn du nur deine eigene private Homepage darauf betreiben möchtest brauchst du so gesehen erstmal kein Zertifikat.
Flash Gordon schrieb: > Nicht unbedingt. Man muss ja nur die Exception am client wegclicken... Wenn Du normale User daran gewöhnst die SSL-Fehlermeldungen im Client "einfach" wegzuklicken, handelst Du grob fahrlässig: Wenn sich der User einmal dran gewöhnt hat, macht er das auch bei Zugriff über ungesichertes WLAN bei seinem Emailpostfach, seiner Bank, etc. Und schon sind die Passwörter oder die Kohle weg. Die SSL-Zertifikatsprüfung und die dazugehörigen Fehlermeldungen sind ein ganz wichtiger Teil von SSL. Wenn man die ignoriert, braucht man auch kein SSL. Es kann sogar mehr Schaden als Nutzen, siehe oben.
Gerd E. schrieb: > Wenn Du normale User daran gewöhnst die SSL-Fehlermeldungen im Client > "einfach" wegzuklicken, handelst Du grob fahrlässig: Es hängt von der Zielgruppe ab. Ist das beispielsweise sowas wie ein Gaming-Server für den Bekanntenkreis, dann käme auch ein selbst signiertes Zertifikat in Frage, das jeder seinem Client beibringt. > Die SSL-Zertifikatsprüfung und die dazugehörigen Fehlermeldungen sind > ein ganz wichtiger Teil von SSL. Wenn man die ignoriert, braucht man > auch kein SSL. Die Checks garantieren (naja, ein bissel jedenfalls) zwar die Identität des Gegenübers. Die Verschlüsselung ist eine andere Baustelle, insbesondere mit PFS. Weshalb es nicht völlig sinnlos ist, SMTP/TLS auch ohne offiziellem Zertifikat zu betreiben. Tatsächlich haben sehr viele Mailhosts mit TLS kein offizielles Zertifikat, auch bei den Grossen. Das ist zwar kein Traumzustand, aber besser als Klartext.
Gerd E. schrieb: > Die SSL-Zertifikatsprüfung und die dazugehörigen Fehlermeldungen sind > ein ganz wichtiger Teil von SSL. Nicht zwangsläufig. Das SSH-Modell (opportunistic encryption) ist auch im SSL-Kontext nicht grundsätzlich verkehrt.
A. K. schrieb: > Gerd E. schrieb: >> Wenn Du normale User daran gewöhnst die SSL-Fehlermeldungen im Client >> "einfach" wegzuklicken, handelst Du grob fahrlässig: > > Es hängt von der Zielgruppe ab. Ist das beispielsweise sowas wie ein > Gaming-Server für den Bekanntenkreis, dann käme auch ein selbst > signiertes Zertifikat in Frage, das jeder seinem Client beibringt. Wenn die User einmal am Anfang den Hash überprüfen, dann ja. Nur z.B. zeigen Android und iOS in den Details des Zertifikats keine Fingerprints an. Grr. > Weshalb es nicht völlig sinnlos ist, SMTP/TLS auch > ohne offiziellem Zertifikat zu betreiben. Tatsächlich haben sehr viele > Mailhosts mit TLS kein offizielles Zertifikat, auch bei den Grossen. Das > ist zwar kein Traumzustand, aber besser als Klartext. Bei Mail ist das Thema sowieso nochmal ein anderes: durch die zusätzliche Indirektion des MX-Eintrages brauchst Du neben dem Zertifikat zusätzlich DNSSEC um wirklich sicherstellen zu können daß das Zertifikat zum Empfänger gehört. Daher funktioniert das ganze bei Mail in der Praxis nur mit Kommunikationspartnern, mit denen man sich da vorher abgestimmt hat. Alles andere schadet zwar nicht, aber man kann sich halt auf nix verlassen.
Gerd E. schrieb: > Wenn die User einmal am Anfang den Hash überprüfen, dann ja. Nur z.B. > zeigen Android und iOS in den Details des Zertifikats keine Fingerprints > an. Grr. Man kann die Paranoia auch übertreiben. Die Wahrscheinlichkeit, dass sich jemand just zu diesem Zeitpunkt live in die Leitung zwischenmogelt, ist meist doch recht überschaubar. Wenn du auf dem Server nicht grad die Familienjuwelen verwaltest, dann kann man mit dieser Art Ungewissheit oft leben.
A. K. schrieb: > Man kann die Paranoia auch übertreiben. Die Wahrscheinlichkeit, dass > sich jemand just zu diesem Zeitpunkt live in die Leitung zwischenmogelt, braucht er gar nicht, es reicht wenn er den DNS umbiegt. Schon landest du auf eine falschen Seite und merkst es nicht.
Peter II schrieb: > braucht er gar nicht, es reicht wenn er den DNS umbiegt. Schon landest > du auf eine falschen Seite und merkst es nicht. Das muss dann aber schon bei ersten Mal geschehen, also dann wenn das Zertifikat gefischt wird. Danach merkst du es sehr wohl. Hängt halt davon ab, um was es geht. Um den erwähnten Gaming-Server, oder sowas in der Art, oder um al-quaida.org. In letzterem Fall wärs übrigens sogar der sinnvollste Weg, allerdings vorzugsweise mit Zertifikatstransport per Turnschuhnetzwerk. Denn den offiziellen Zertifikaten kann man, wenn wirklich ernsthaft betrachtet, längst nicht mehr über den Weg trauen.
A. K. schrieb: > Die Checks garantieren (naja, ein bissel jedenfalls) zwar die Identität > des Gegenübers. Die Verschlüsselung ist eine andere Baustelle, Die Verschlüsselung kannst du dir völlig in die Haare schmieren, wenn der Bösewicht den Schlüssel vorgibt. Genau das kann passieren, wenn du ohne Zertifikatsprüfung eine auf public keys beruhende Session aufmachst: Angreifer setzt sich statt dem Zielsystem hin (DNS-Umbiegung, Routing-Tricks, ...), handelt mit deinem Browser einen session key aus und decryptet, als wäre er der vermeintlich sichere Webserver. Fazit: Ohne Zertifikatscheck ist die Verschlüsselung in den meisten Anwendungsfällen irgendwo zwischen nutzlos und wertarm.
Alexander T.-Z. schrieb: > Genau das kann passieren, wenn du ohne Zertifikatsprüfung eine auf > public keys beruhende Session aufmachst: Von einem Verzicht auf Zertifikatsprüfungen war meinerseits nicht die Rede. Sondern darum, woher das Zertifikat kommt und wie es in die Browser-Liste bekannter und akzeptierter Server gelangt. Das kann den offiziellen Weg über Zertifizierungsstellen gehen, das kann aber auch anders erfolgen. Dass ohne separaten Kommunikationsweg für Zertifikat oder Hash davon der Schwachpunkt in der ersten Verbindungsaufnahme liegt ist mir klar. Aber wenn man da mal durch ist und nicht umgeleitet wurde, dann dürfte die Sicherheit wahrscheinlich besser sein, als bei offiziellen aber längst durchlöcherten Zertifizierungsstellen. Beachte auch meine Betonung des Einsatzzweckes. Erforderliche Sicherheit und tolerierbarer Aufwand hängen sehr davon ab, wie kritisch die Kommunikation ist und um welchen Personenkreis es geht.
jibi schrieb: > Moin, > > bin gerade dabei ein Webhosting Packet zusammenzustellen, dabei gibt es > eine extra Option "Eigenes SSL-Certificate" für 25 dollar extra im Jahr. > Für was brauch ich sowas? > > Gruß Jonas Ich vermute, dass es in dem Fall um ein Unterschriebenes Zertifikat geht. Ansonsten kannst Du das auch selber machen. Es gibt "sichere" Unterzeichner die Dir das Zertifikat gegenzeichnen, die den meisten Browsern bekannt sind. Also mosert der Browser bei einer https Verbindung auch nicht. Selbstverständlich wird das nicht einfach so unterzeichnet, somit sicherer. Das ist alles Theorie und basiert auf dem 4 resp. 2xX Augen System. Die Benutzer fühlen sich aber dadurch sicherer. Du brauchst das nur, wenn Du einen WEB-Shop betreibst. Grüsse, René
Alexander T.-Z. schrieb: > Fazit: Ohne Zertifikatscheck ist die Verschlüsselung in den meisten > Anwendungsfällen irgendwo zwischen nutzlos und wertarm. Falsch. Wie all die SSH-Nutzer täglich zeigen.
Stefan Rand schrieb: >> Fazit: Ohne Zertifikatscheck ist die Verschlüsselung in den meisten >> Anwendungsfällen irgendwo zwischen nutzlos und wertarm. > > Falsch. Wie all die SSH-Nutzer täglich zeigen. SSH hat genau das gleiche "Problem". Wenn du dich das erste mal mit einer Box verbindest und den Fingerprint des Keys nicht überprüfst, dann kannst du unmöglich sagen ob du dein Kennwort jetzt bei der gewünschten Box eintippst oder in eine Box die einfach nur dein Kennwort mit schreibt und transparent zur richtigen Box eine Verbindung aufbaut. Die Tatsache, dass die Verbindung verschlüsselt ist, hilft an der Stelle nur wenig, dein Kennwort ist weg. (Ja, aus dem Grunde sollte man Keys zum authentifizieren nehmen)
__tom schrieb: >>> Fazit: Ohne Zertifikatscheck ist die Verschlüsselung in den meisten >>> Anwendungsfällen irgendwo zwischen nutzlos und wertarm. >> >> Falsch. Wie all die SSH-Nutzer täglich zeigen. > > SSH hat genau das gleiche "Problem". Genau darauf will ich hinaus. Es ist offensichtlich kein Problem, weil das Bedrohungsszenario "beim ersten Connect werde ich bereits angegriffen" in der Praxis offensichtlich keine Rolle spielt. Key Continuity reicht.
Stefan Rand schrieb: > Es ist offensichtlich kein Problem, weil > das Bedrohungsszenario "beim ersten Connect werde ich bereits > angegriffen" in der Praxis offensichtlich keine Rolle spielt. > > Key Continuity reicht. So offensichtlich finde ich das nicht: Per SSH loggt man sich typischerweise nur auf einem überschaubaren Kreis an Rechnern ein, per HTTPS verbindet man sich dagegen üblicherweise mit einer wesentlich größeren Anzahl von Webservern. Damit findet der kritische Erstkontakt viel häufiger statt. Bei einem SSH-Server richtet einem der Admin (oder sogar man selbst) einen Account ein. Auf diese Weise kann man leicht auf einem anderen Kanal den Fingerprint austauschen und überprüfen. Bei HTTPS z.B. zu einem Webshop ist das nicht praktikabel. Außerdem laufen SSL-Zertifikate regelmäßig ab, typischerweise im Zeitraum von 1 bis 3 Jahren. Das ist auch gut so, da so alte, jetzt nicht mehr als ausreichend sicher angesehene Verfahren (wie z.B. MD5), ersetzt werden können. Damit ist die Key Continuity hierfür nur sehr eingeschränkt brauchbar. SSL-Zertifikate von einer in den Browsern hinterlegten Zertifizierungsstelle gibt es seit einiger Zeit auch kostenlos (http://startssl.com), spätestens damit sehe ich keinen Grund mehr selbst bei privaten Seiten auf selbstsignierte Zertifikate zurückzugreifen.
Ja, startssl ist ne gute Option, wenn man damit leben kann, daß das kostenlose zertifikat nur ein Jahr lang läuft. Nutze ich auch. Das wichtigste ist wohl, sich von CAcert fernzuhalten...
Stefan Rand schrieb: > Das wichtigste ist wohl, sich von CAcert fernzuhalten... warum genau? Deren Kriterien für die Zertifizierung (ich glaube 3 verschiedene Teilnehmer persönlich treffen, jeweils 2 verschiedene Ausweise anschauen lassen) sind zumindest wesentlich höher als das, was die anderen Zertifizierungsstellen machen. Wie sicher deren Infrastruktur und Prozesse momentan sind kann ich aber nicht abschätzen. Das ist ja auch ein durchaus relevantes Kriterium.
Weil die völlig undurchschaubare bürokratische Strukturen haben.
Weil du dich einen Regelwerk unterwirfst, wonach ein Panel aus
"Laienrichtern" aus der Community empfindliche Geldstrafen gegen dich
festsetzen kann, ohne Möglichkeit der Berufung oder Überprüfung des
Urteils.
Weil dieses Urteil meiner vorläufigen Einschätzung nach tatsächlich
durchsetzbar ist, wenn du die Teilnahmevereinbarung erstmal
unterschrieben hast.
Und weil die damals (ist paar Jahre her), als die diese Regeln
einführten, auf hinterfotzige Weise und unter massivem Zeitdruck
("unterschreib gleich, du mußt die Vereinbarung nicht heimnehmen und
erstmal in Ruhe durchlesen) versucht haben, Leute in dieses Abkommen zu
pressen:
"Du willst aussteigen und nach den neuen Regeln nicht mehr mitspielen?
Kein Problem, du mußt nur die neuen Regeln unterschreiben, dann
bearbeiten wir deinen Ausstiegswunsch."
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.