[CENGOiSM]

Hi,

musste letztens meinen JD neu aufsetzen. Hab mir dazu dass neueste Java kompiliert (1.8.0_65 wenn ich mich richtig erinnere) und klappt alles auch wieder wunderbar.

Nur wollte Captcha9kw am Anfang nicht, hab mir dann die Logs ein wenig durchgeschaut - es ging darum dass keine https Verbindung aufgebaut werden konnte, weil der DH-Key oder ähnliches nur bis max. 1024bit gehen darf und deswegen Java dort aussteigt (?).

Frage: Ich habe auch hier irgendwo im Forum eine Möglichkeit gefunden gehabt, wie man dass umgehen kann. Man muss irgendwas zu Java hinzufügen und paar Sachen anpassen, dann klappt das. Aber ist das hier immernoch notwendig? Es ging um Java 6 oder älter meine ich...
Und wie "unsicher" ist es 9kw ohne https zu verwenden? Was könnten potenzielle Angreifer dort ergaunern, wie sehen dass die Entwickler von JD?

Ich bin prinzipiell für https, aber wenn nichts gegen http 9kw spricht, dann spare ich mir die Mühe. :D

[thecoder2012]

Originally Posted by CENGOiSM

Nur wollte Captcha9kw am Anfang nicht, hab mir dann die Logs ein wenig durchgeschaut - es ging darum dass keine https Verbindung aufgebaut werden konnte, weil der DH-Key oder ähnliches nur bis max. 1024bit gehen darf und deswegen Java dort aussteigt (?).

Im Test von JDownloader 2 mit aktueller Java Edition unter Windows 8.1 (ipv4) konnte ein solches Problem nicht reproduziert werden.

Originally Posted by CENGOiSM

Und wie "unsicher" ist es 9kw ohne https zu verwenden? Was könnten potenzielle Angreifer dort ergaunern, wie sehen dass die Entwickler von JD?

Der Zugang könnte entwendet werden und man könnte das Guthaben dadurch bei 9kw verlieren.

Originally Posted by CENGOiSM

Ich bin prinzipiell für https, aber wenn nichts gegen http 9kw spricht, dann spare ich mir die Mühe. :D

Empfehlung ist aktiviertes https weil sonst keine verschlüsselte Verbindung genutzt wird.

[CENGOiSM]

Hey thecoder2012,

vielen Dank mit dem Vergleich auf Windows. Ich wusste zwar schon, dass es an meinem Java liegt, aber jetzt kann man sich wenigstens sicher sein. ^^
Das mit dem Guthaben leuchtet ein, hatte ja bis jetzt auch https im Einsatz - hab mich nur gesträubt den Fehler zu beheben.

Hab https mal wieder aktiviert um den Log hier einfügen zu können, folgendes:

------------------------Thread: 10866:GlobalBrowser.log-----------------------
--ID:10866TS:1449176947508-12/3/15 9:09:07 PM - [] -> javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.SSLSocketImpl.handleException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at org.appwork.utils.net.httpconnection.JavaSSLSocketStreamFactory.create(JavaSSLSocketStreamFactory.ja va:224)
at org.appwork.utils.net.httpconnection.HTTPConnectionImpl.connect(HTTPConnectionImpl.java:675)
at jd.http.requests.PostRequest.postRequest(PostRequest.java:177)
at jd.http.Request.connect(Request.java:271)
at jd.http.Browser.openRequestConnection(Browser.java:1531)
at jd.http.Browser.openRequestConnection(Browser.java:1506)
at jd.http.Browser.openPostConnection(Browser.java:1466)
at jd.http.Browser.postPage(Browser.java:1612)
at jd.http.Browser.postPage(Browser.java:1619)
at org.jdownloader.captcha.v2.solver.solver9kw.Captcha9kwSolver.solveCES(Captcha9kwSolver.java:379)
at org.jdownloader.captcha.v2.solver.CESChallengeSolver.solve(CESChallengeSolver.java:45)
at org.jdownloader.captcha.v2.JobRunnable.run(JobRunnable.java:140)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at sun.security.ssl.DHCrypt.<init>(Unknown Source)
at sun.security.ssl.DHCrypt.<init>(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverKeyExchange(Unknown Source)
at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker.process_record(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
... 17 more
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120)
at java.security.KeyPairGenerator$Delegate.initialize(Unknown Source)
... 25 more

Bei Java8 muss man ja für ARM jetzt seine Version selber kompilieren :/ Hat hier jemand vielleicht den passenden Befehl, damit der DHKeyPairGenerator miteingefügt wird.
Hab nur "jrecreate.sh --dest path --vm client" verwendet gehabt. Ist sicher nützlich für alle die auch auf Java8 updaten wollen. ^^

LG CENGOiSM

[Jiaz]

Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)
Der DHKeyPairGenerator ist dabei, jedoch erlaubt er nur 512 bis 2048 Keysizes
Um das zu Umgehen musst du die Java High Security Policy von Hand installieren
Ich kann mir das gerne mal via Teamviewer anschauen. Oder sonst wie versuchen zu helfen, einfach via support@jdownloader.org melden

[CENGOiSM]

Hey Jiaz,
hab mich nach "Java High Security Policy" umgeschaut und auf der Oracle Seite "JCE Unlimited Strength" gefunden. Hab mir diese Erweiterung für Java8 geladen, unter /lib/security die alten Daten ersetzt, NAS und JD neugestartet.
Jedoch erhalte ich immernoch den selben Fehler :/.

[Jiaz]

Schicke mir mal bitte den gezippten Logs Ordner an support@jdownloader.org
Dann schau ich mir das an

[CENGOiSM]

Originally Posted by Jiaz

Schicke mir mal bitte den gezippten Logs Ordner an support@jdownloader.org
Dann schau ich mir das an

Log-Ordner ist zugestellt. Hab in der Zwischenzeit leider immernoch keine Lösung. :/

[Jiaz]

Bei Java8 muss man ja für ARM jetzt seine Version selber kompilieren
Warum das? Gibts doch ganz normal zum Download? Warum selbst compilen?
oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Ich werd nächste Woche mal BouncyCastle in den Advanced Settings aktivierbar machen

[CENGOiSM]

Originally Posted by Jiaz

Bei Java8 muss man ja für ARM jetzt seine Version selber kompilieren
Warum das? Gibts doch ganz normal zum Download? Warum selbst compilen?
oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Ich werd nächste Woche mal BouncyCastle in den Advanced Settings aktivierbar machen

Hab für ARMv5 leider nur das hier gefunden: oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html

Bei JRECreate dann "Client" JVM ausgewählt. Alles funktioniert auch soweit, nur eben SSL nicht.. Wieso auch immer die Java Installation verkompliziert wird ^^

[Jiaz]

Mit dem nächsten Core Update in den Advanced Settings nach Bouncy suchen und 'Prefer Bouncy Castle for TLS' aktivieren und JD neustarten

[CENGOiSM]

Alles klar, ich dank dir Jiaz! Kommt BouncyCastle dann zusammen mit JD oder sollte ich diese Erweiterung schon mal meinem Java hinzufügen?

[Jiaz]

Einfach Updaten, und aktivieren. BouncyCastle ist default dabei, wird ja auch an anderer Stelle verwendet.

Update ist schon live

[CENGOiSM]

Grad geupdatet und ausprobiert, läuft. Hab vielen Dank, Jiaz

[Jiaz]

Danke fürs Feedback!

[Jiaz]

Danke für die Logs.
Wäre es möglich das du mir deine compilierte JRE zur Verfügung stellst? zb irgendwo hochlädst? Würde gerne herausfinden was genau da *nicht korrekt* funktioniert.

Du solltest noch dein Locale korrigieren (sun.jnu.encoding: ANSI_X3.4-1968) ansonsten wird es Probleme mit Umlauten in Dateinamen geben.

[CENGOiSM]

Gerne gerne, ich lad dir die gezippte JRE dann in dem einen Support Ticket wo ich die Logs gesendet hatte hoch.

Umlaute sind nur am stressen, wie genau kann ich das auf UTF-8 ändern? Hab eigentlich hier und da überall export iwas de_DE.UTF-8 - bei FileBot hats dann geklappt, JD hatte da eigentlich noch nie Probleme geschoben aber ich nehm deinen Tipp zu Herzen wenn du mir vielleicht sagen könntest wie ich das anstelle. :D

[Jiaz]

zb ein StartScript

#!/bin/bash
export LC_CTYPE="en_US.UTF-8"
export LANG="en_US.UTF-8"
export LC_COLLATE="C"
/ffp/opt/java/jre/bin/java -- -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8 -jar /ffp/opt/jd2/JDownloader.jar

Pfade natürlich anpassen

[CENGOiSM]

Hab mal die encoding Optionen dem JD-Script hinzugefügt, in welcher Log kann ich sehen ob es auch geklappt hat?

[Jiaz]

Wenn du ein Archiv herunterlädst, welches auch Sonderzeichen im Dateinamen haben und diese dann stimmen
Anhand des Logs lässt sich das nicht erkennen, da es hierbei um Interna in Linux geht

[CENGOiSM]

Hmm und woher hast du dann gewusst, dass bei mir nicht UTF-8 eingestellt war? :D
Ich erinnere mich nämlich nicht an ein Archiv mit Umlauten oder Sonderzeichen (zB '), die im Log ein "ASCII ist aktiv und nicht UTF-8, Umlaute/Sonderzeichen gehen grad nicht" hinterlassen hätten.

[Jiaz]

An dem System.property sun.jnu.encoding
das war *falsch* bzw *komisch*. Aber das ist nur ein Indiz und kein eindeutiges

[CENGOiSM]

[jd.SecondLevelLaunch(mainStart)] -> file.encoding=UTF-8
[jd.SecondLevelLaunch(mainStart)] -> sun.jnu.encoding=UTF-8
&
[jd.SecondLevelLaunch$9(run)] -> Use 'BouncyCastle' for default SSLSocketStreamFactory!

Das sagen die Logs, sieht soweit ganz gut aus. ^^

[Jiaz]

Nunja, das wichtige sind die export LOCAL Sachen und die sieht man leider nicht im Log :( Daher wird es erst das nächste Archiv/Download zeigen ob Umlaute korrekt gehen

[CENGOiSM]

Die hab ich eigentlich schon drin. ^^
Zwar nicht direkt in dem JD-Script, aber die Sachen werden für admin automatisch gesetzt.

Hab die JRE grad gezippt und hochgeladen, sende dir den Link via Support.

[Jiaz]

Danke für den Link, ich geb per Email bescheid wenn ich es mir gezogen hab (morgen früh)