Deine Dienste werden nicht SSL benötigen, wenn du dich gar nicht damit beschäftigt hast. Vermutlich sendest du alles Klartext über das Netz.
Aber wichtig ist doch das SSH irgendwie -Login sicher ist oder nicht? Ich bin ja Root, aber lese auch nur hin und wieder hier und da was, habe also kein fundiertes Wissen oder könnte mich sicherer Experte nennen. Jaein, das ist (nicht) so.
OpenSSH benutzt OpenSSL, ist aber nicht betroffen. Login über SSH ist sicher.
auf Grund „eines Fehlers“ in der Sprache betrachtest Du OpenSSL als EOL? Finde ich etwas weit her geholt.
genau wie in Java …
… wird das mit ArrayIndexOutofBoundsException quittiert, dennoch kann man aus der JVM ausbrechen.
Es ist egal welche Sprache verwendet wird, das Problem ist die CPU. Solange wie man der CPU die Anweisung geben kann N Bytes von $A nach $B zu kopieren, wird es immer Sicherheitslücken geben. Die logische Unterteilung zwischen Programm und Daten macht das BS bzw. der Compiler. Die CPU ist nur der dumme, gutgläubige Rechenknecht - der nichts überprüft.
Danke für die Kurzerklärung, hat nicht irgendein Computer Experte in den 80ern gesagt, kein Computer, der mit WLAN oder Netzwerkkabel mit dem inet verbunden ist, ist sicher?
Ich betrachte OpenSSL mit C als EOL. Ich kann die Archtektur von OpenSSL nicht beurteilen, gut möglich, dass die noch zehn, fünfzehn Jahre passt. Aber in Hinsicht auf C sollten sie sich langsam eine Ausstiegsstrategie überlegen.
Es steht jedem frei, diesen Vorschlag zu machen, das Projekt zu forken, Alternativen zu starten…
Zum einen gibt es GnuTLS, PolarSSL, aber auch alles wieder C. Ansonsten kann ich diesem Post nur zustimmen: http://coderinaworldofcode.blogspot.co.uk/2014/04/my-heart-bleeds-for-openssl.html
Die Sprache selbst ist nicht das Problem, sondern die fehlenden Entwickler und auch die fehlenden Tests.
geht das einen Tick genauer?
wie kann man in Java mit Befehl in Bereich X auf völlig anderen Speicher Y zugreifen?
kann mich nicht erinnern das in 10 Jahren selber gehabt oder z.B. hier den Foren gesehen zu haben,
(außer normale Programmabläufe, wie mit falschen Index aus globaler Liste der User fremdes Paswort holen usw.)
und wenn eine Exception kommt (und wohlgemerkt KEINE Daten), dann ist das ein heftiger Programmunterbrecher,
dass man mit gezielten Befehlen etwas erreichen kann, ob durch bösartigen Insider oder Angriff von außen durch andere Lücken,
ist (falls überhaupt möglich) eine andere Frage,
es geht hier doch um unbedarfte Fehler der gutgesinnten direkten Programmierer,
in C mit kaum erkennbaren Fehlern gravierende Probleme wie dieses hier, ich höheren Sprachen (sicher!) so nicht mehr möglich?
Naja, wenn man so wie in openSSL einen eigenen Allokator hat, könnte das auch wo anders passieren, falls man sowas braucht ^^
o.O
Du hast schon die Sicherheitsfehler in Java letztes Jahr mitbekommen (sorry das ich fragen muss)? Wie das in Detail funktioniert habe ich mich ehrlich nicht damit auseinander gesetzt. Tatsache ist aber das viele Religiösefanatiker Java gleich wieder dem Untergang geweiht haben, weil ja Java nicht sicher ist.
Wieso kann man dann aus einer JVM ausbrechen und einen fremden Rechner übernehmen? Es ist eine sehr naive Annahme davon auszugehen das man in einem Sandkasten sicher ist. Das Problem auf CPU-Ebene bleibt: memcpy #N, $A, $B
Man könnte genauso gut ein Allokator in Java schreiben, mit der Behauptung dass die Speicherverwaltung von Java viel zu langsam ist. 
kannst du entsprechenden Code zum Ausbrechen posten?
grob erinnert und aktuell gesucht bleibt es auch für mich nur bei abstrakten Exploits, nirgendwo konkreter Code, konkrete Anwendungen?
„Hacker haben einen neuen Exploit veröffentlicht, der die letzthin eingeführte Sicherheitsabfrage beim Ausführen von unsigniertem Code aushebelt.“
lese ich gerade, das ist schon eine ganz andere Art des Angriffs,
sich fremden Code auf den Computer zu laden und den frei agieren zu lassen ist sowieso Wagnis,
dass es darum Grenzen geben soll ist klar und Fehler sicherlich möglich
wie würde erst OpenSSL sehen wenn da andere die Programmzeilen bestimmen dürften…,
wobei wer weiß, vielleicht die Sicherheitstore in entsprechenden Sandbox-Versuchen in Sprache C besser, keine Wertung
aber das hat doch nichts direkt mit der Programmiersprache und den elementaren JVM-Möglichkeiten zur Ausführung zu tun,
dazu gehören Klassen, Methoden, Threads, Speicherverwaltung usw.,
ein Internet und Protokolle und übertragende Nachrichten muss es da noch gar nicht geben,
und ob man dann eine Sandbox-Umgebung baut ist völlig freie sekundäre Entscheidung,
ein Stück Software, die gut oder schlecht sein kann, unabhängig von der Sprache
das hat doch alles nichts mit der Ebene des Fehlers hier zu tun, dass man mit simplen Code-Zeilen 60 kb Arbeitsspeicher auslesen kann?
mit ganz normalen Code auf den jeder Neuling auch trifft,
immerhin wahrlich bekanntes Problem, hilft ein wenig bei Vermeidung, aber tritt anscheinend doch immer und überall wieder auf,
kann leicht bei Kontrolle übersehen werden,
und zwar wie gesagt auch nicht von einem Angreifer mit üblen untergemogelten Hacks sondern vom Programmierer der Software selber,
beste Absichten, normalen harmlosen Code der eine solche Lücke ermöglicht, in Java unvorstellbar, außer man baut konkrete Befehle
Frage von Dummie an Schlaui: Seh’ ich das richtig, mit dem private key wird verschlüsselt, mit dem public key wird entschlüsselt. Der public key sollte für alle bekannt sein (über eine Zertifizierungsstelle), deshalb ist es auch wichtig, ob FF den kennt. Die Verschlüsselung sollte so sein, dass mit dem public key zu entschlüsselnde Nachrichten nur der verschlüsseln kann, der den private key kennt/besitzt? Wie läuft dann die Verschlüsselung von Client nach -> Server? Jeder, der den public key kennt, kann doch mitlesen?
Edit: Sorry, es ist genau anders herum, nach einem Blick auf Wikipedia (siehe alles bitte kurz hier: https://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem ). De Webbrowser-Client verschlüsselt mit public key, und nur der, der den private key hat, kann entschlüsseln. Di Zufallszahlen sind für beide Schlüssel wichtig. Dann kann der Webbrowser-Client dem Webserver ja auch mitteilen, wie der seine Nachrichten zu verschlüsseln hat. Ok, dann habe ich es nun ganz abstrakt verstandenen.
das ist auch richtig und ein wichtiges Feature:
die Nachricht/ die Daten sind dann nicht geheim, aber jederman kann mit dem public key verifizieren, dass sie vom Sender X stammen,
denn nur dieser hat den private key, nur dieser kann diese Daten erstellt haben
also Digitale Unterschrift, signierte Daten/ Programme/ Updates usw.,
nicht unbedingt alle Daten zu verschlüsseln, es reicht auch ein Hash-Wert davon
Also ich muss das wirklich komplett noch mal machen, aber ungefähr insoweit habe ich das verstanden:
pri sei der private key, pub sei der public key
Webbrowser-Client verschlüsselt mit pub, nur Webserver kann mit pri entschlüsseln,
das von Webbrowser-Client Verschlüsselte kann jemand mitlesen aber nicht entschlüsseln,
das von Webbrowser-Client Verschlüsselte kann jemand anderes an Webserver schicken,
…,
Webbrowser-Client kann aber mitteilen, wie verschlüsselt werden soll,
nur Webbrowser-Client (und Webserver) kann dann die Antwort lesen, weil jemand anderes den Schlüssel zur Ver- und Entschlüsselung nur in verschlüsselter Form kennt,
ist das richtig?
Nopedinope. Alles viel komplizierter und viel mehr Verfahren dahinter. Wenn dich das wirklich interessiert, lies dir die RFC 5246 für TLS1.2 durch, oder wenigstens den Wikipedia-Artikel zu TLS durch, bevor du hier rumtrollst…
es ging mir im ganzen um die Aussage das „C alt ist und mit modernen Sprachen alles sicherer wird“, was definitiv falsch ist. Klar hätte theoretisch Java hier eine Exception geworfen - aber auch nur theoretisch. Was wirklich passiert wäre läge an der wirklichem Implementierung.
Das BSI bringt es auf den Punkt:
Trotz der umfangreichen Sicherheitsfeatures in Java ist diese Technologie mitsamt ihrer Implementierung nicht gänzlich vor Bedrohungen geschützt.
Das zeigt auch die Liste der Schwachstellen: SUN » JRE : Security Vulnerabilities.
Das die Schwachstellen schwieriger zu verstehen sind, macht sie nicht ungefährlicher.
und wenn ein Anfänger ein Webanwendung schreibt, in der SQL-Injection möglich ist, ist das dann auch Fehler/ Sicherheitslücke von Java oder gar SQL?
JRE/ Applet Class Loader sind natürlich sehr nahe an der Sprache/ geradezu unumgänglich,
aber letztlich auch nur geschriebene austauschbare Software, die sicher oder unsicher sein kann,
ironischerweise kann/ ist die ja auch zum Teil in anderen Programmiersprachen wie C++ geschrieben?
all dies kann sowieso nur (wiederholte Aussage) in waghalsigen Spezialfällen wie Ausführung von fremden Code auf eigenen PC interessant werden,
wenn wie bei OpenSSL eine Protokollnachricht mit Daten zur lokalen Entschlüsselung ankommt,
dann möchte ich mal das Nachrichtenformat sehen, welches einen Exploit der JVM ausnutzt?!
die läuft doch lokal unangreifbar
was real passiert in der Welt sind im Protokoll erlaubte Nachrichten wie im Comic dargestellt http://xkcd.com/1354/
- dazu kann ein Anwender Mist programmieren in jeder Sprache (
return getUser(indexFromClient).getPassword()) - oder es kann durch wahnwitziges Speichermanagement bei kaum erkennbaren Code-Ungenauigkeiten Daten herausgegeben werden
letzteres sollte in zivilisierten Hochsprachen nicht möglich sein,
einfache Anwendungs-Programmierfehler + Bugs in MB großen Libraries/ Servern/ insbesondere Sandbox-Umbegungen für losgelassenen beliebigen Angreifer-Code dagegen,
das gibt es immer und überall, auch in der sichersten Akademiker-Sprache, genauso auch in Arbeitsabläufen in Firmen usw., hat wenig mit der Programmiersprache zu tun,
was konkret sollte diese dazu leisten?
die aktuelle Bewertung, dass Java-JVM unsicher ist, kann man natürlich stehen lassen, objektive Tatsache