Keine https-Verbindung mehr unter DSM 5.1-5022 Update 1 möglich

Status
Für weitere Antworten geschlossen.

Frogman

Benutzer
Mitglied seit
01. Sep 2012
Beiträge
17.485
Punkte für Reaktionen
8
Punkte
414
... es würde nichts bringen! ...
Eben darum und weil weder Du noch ich zu entscheiden haben, ob der Einsatz von SSL für den TE als notwendig zu erachten ist, würde ich vorschlagen, jetzt wieder zum Thema zurückzukehren und zu versuchen, es zu lösen - wo Du Dich sehr gerne beteiligen kannst :)
 

g202e

Benutzer
Mitglied seit
07. Jun 2009
Beiträge
2.293
Punkte für Reaktionen
0
Punkte
82
Dazu müsste sich der TE erstmal äußern.
 

gnoovy

Benutzer
Mitglied seit
26. Mrz 2011
Beiträge
123
Punkte für Reaktionen
0
Punkte
0
Hi Zusammen,

also langweilig ist mir sicherlich nicht ;-) Prinzipiell gebe ich euch Recht, dass TLS im internen Netzwerk weniger kritisch ist, als über einen externen Zugriff. Dennoch will ich bei Passworteingaben, etc. auch intern eine Verschlüsselung. Klar hab ich ein anderes Problem wenn jemand unbefugtes in meinem Netz ist, aber Security besteht ja aus vielen Einzelprozessen...

Und wie Frogman schon sagt, ob Sinn oder Unsinn es hat ja vor dem Update funktioniert ;-)

Ich vermute die Aktualisierung der openssl-Komponente...
 

Frogman

Benutzer
Mitglied seit
01. Sep 2012
Beiträge
17.485
Punkte für Reaktionen
8
Punkte
414
Ich vermute die Aktualisierung der openssl-Komponente...
Hier sind mal die Änderungen der aktuellen Version 1.0.1k. Bei mir funktioniert die auch problemlos.
Code:
Changes between 1.0.1j and 1.0.1k [xx XXX xxxx]

  *) Abort handshake if server key exchange message is omitted for ephemeral
     ECDH ciphersuites.

     Thanks to Karthikeyan Bhargavan of the PROSECCO team at INRIA for
     reporting this issue.
     (CVE-2014-3572)
     [Steve Henson]
  *) Remove non-export ephemeral RSA code on client and server. This code
     violated the TLS standard by allowing the use of temporary RSA keys in
     non-export ciphersuites and could be used by a server to effectively
     downgrade the RSA key length used to a value smaller than the server
     certificate. Thanks for Karthikeyan Bhargavan of the PROSECCO team at
     INRIA or reporting this issue.
     (CVE-2015-0204)
     [Steve Henson]
  *) Ensure that the session ID context of an SSL is updated when its
     SSL_CTX is updated via SSL_set_SSL_CTX.
     The session ID context is typically set from the parent SSL_CTX,
     and can vary with the CTX.
     [Adam Langley]
  *) Fix various certificate fingerprint issues.
     By using non-DER or invalid encodings outside the signed portion of a
     certificate the fingerprint can be changed without breaking the signature.
     Although no details of the signed portion of the certificate can be changed
     this can cause problems with some applications: e.g. those using the
     certificate fingerprint for blacklists.
     1. Reject signatures with non zero unused bits.
     If the BIT STRING containing the signature has non zero unused bits reject
     the signature. All current signature algorithms require zero unused bits.
     2. Check certificate algorithm consistency.
     Check the AlgorithmIdentifier inside TBS matches the one in the
     certificate signature. NB: this will result in signature failure
     errors for some broken certificates.
     Thanks to Konrad Kraszewski from Google for reporting this issue.
     3. Check DSA/ECDSA signatures use DER.
     Reencode DSA/ECDSA signatures and compare with the original received
     signature. Return an error if there is a mismatch.
     This will reject various cases including garbage after signature
     (thanks to Antti Karjalainen and Tuomo Untinen from the Codenomicon CROSS
     program for discovering this case) and use of BER or invalid ASN.1 INTEGERs
     (negative or with leading zeroes).
     Further analysis was conducted and fixes were developed by Stephen Henson
     of the OpenSSL core team.
     (CVE-2014-8275)
     [Steve Henson]
   *) Do not resume sessions on the server if the negotiated protocol
      version does not match the session's version. Resuming with a different
      version, while not strictly forbidden by the RFC, is of questionable
      sanity and breaks all known clients.
      [David Benjamin, Emilia Käsper]
   *) Tighten handling of the ChangeCipherSpec (CCS) message: reject
      early CCS messages during renegotiation. (Note that because
      renegotiation is encrypted, this early CCS was not exploitable.)
      [Emilia Käsper]
   *) Tighten client-side session ticket handling during renegotiation:
      ensure that the client only accepts a session ticket if the server sends
      the extension anew in the ServerHello. Previously, a TLS client would
      reuse the old extension state and thus accept a session ticket if one was
      announced in the initial ServerHello.
      Similarly, ensure that the client requires a session ticket if one
      was advertised in the ServerHello. Previously, a TLS client would
      ignore a missing NewSessionTicket message.
      [Emilia Käsper]
Ich tippe einmal gleich auf den ersten Punkt - vielleicht kannst Du doch noch einmal die SSL-Konfig Deines Browser checken.
 

gnoovy

Benutzer
Mitglied seit
26. Mrz 2011
Beiträge
123
Punkte für Reaktionen
0
Punkte
0
Hi Zusammen,

sorry für meine späte Antwort, war geschäftlich unterwegs. Hmm.. was bedeutet der Punkt genau? Also ich hab nochmals an meinen Einstellungen für Firefox Änderungen vorgenommen, Internet Explorer versucht, andere Rechner versucht über Https-Zuzugreifen, inkl. iphone und Ipdat. Keine Chance. Auf der Clientseite hat sich auch nichts verändert. Nur das Synology-Update ist gemacht worden. Hmm... Würde eventuell ein Reset der Synology helfen?
 

g202e

Benutzer
Mitglied seit
07. Jun 2009
Beiträge
2.293
Punkte für Reaktionen
0
Punkte
82
Windoof8(punkt1) könnte natürlich genauso Schuld sein. Hast du mal geschaut, ob die FW blockt? Irgendwelche "tolle" Sicherheitssoftware auf PC am Start(KIS)? Wie heißt die Sicherheitssoftware?
 

gnoovy

Benutzer
Mitglied seit
26. Mrz 2011
Beiträge
123
Punkte für Reaktionen
0
Punkte
0
Ich habe kaspersky Internet Security 2015 drauf und als proxyserver meine linuxfirewall ipfire. Aber da hat sich seit dem nichts geändert. Ich kann natürlich nachher mal beides deaktivieren und nochmals prüfen.
 

g202e

Benutzer
Mitglied seit
07. Jun 2009
Beiträge
2.293
Punkte für Reaktionen
0
Punkte
82
Deaktivieren bringt (systembedingt!) NICHTS. Sonst könnte ja jede Schadsoftware das Ding auch deaktivieren. Deinstallieren geht auch NUR mit dem Tool vom Hersteller!

KIS ist bekannt dafür, das es(wie andere "eierlegende Wollmilchsau"-Suiten auch), selbst entscheidet, was gut und was böse ist.
Mit dem DSM-Update hat sich etwas geändert und KIS hat beschlossen, dass das böse ist; und zwar OHNE dich darüber zu unterrichten!
Such bitte mal hier im Forum, das hatten wir bereits...
 

stefan_lx

Benutzer
Mitglied seit
09. Okt 2009
Beiträge
2.766
Punkte für Reaktionen
73
Punkte
88
und was hat Kaspersky mit iphone und ipad zu tun?
....
Also ich hab nochmals an meinen Einstellungen für Firefox Änderungen vorgenommen, Internet Explorer versucht, andere Rechner versucht über Https-Zuzugreifen, inkl. iphone und Ipdat. Keine Chance.
...

Stefan
 

g202e

Benutzer
Mitglied seit
07. Jun 2009
Beiträge
2.293
Punkte für Reaktionen
0
Punkte
82
Eher wenig bis nichts!
Ich sage auch nirgends, dass KIS der alleinige Verursacher ist und der TE hat auch nicht geschrieben, dass es ihm hauptsächlich um EI-phone und EI-pad geht...

Aber meine Aussagen zu KIS sind zutreffend, wie du sicher weißt. Und da der Fehler ja z. B. bei mir und anderen NICHT auftritt, ist es klar, dass es am System des TE liegt und da gehören nunmal sowohl Windoof8(punkt1) als auch KIS zu den möglichen Verursachern und es macht mMn durchaus Sinn, bekannte "Verdächtige" zu eliminieren.
Und wenn es am PC dann wieder klappt, kann man sich immer noch um die EI-Geräte kümmern...
 

gnoovy

Benutzer
Mitglied seit
26. Mrz 2011
Beiträge
123
Punkte für Reaktionen
0
Punkte
0
also ich habe jetzt auf meinem Rechner mittels Oracle Virtual Box ein jungfreuliches Win7 ohne Virenscanner, etc. installiert. Dort über den IE klappt es ebenfalls nicht.

Win7 64BIt SP1
IE 11 (Aktiver / inaktiver Proxy)

Habs auch gerade mit nem Android Handy probiert. Gleiches Problem. Ist ja nicht so, dass ich nicht alles da hätte ;-)

Soll ich mal ein neues Zertifikat auf der Syno erstellen?
 

gnoovy

Benutzer
Mitglied seit
26. Mrz 2011
Beiträge
123
Punkte für Reaktionen
0
Punkte
0
Nachtrag:
Also ich habe unter Systemsteuerung - Zertifikat ein selbst erstelltes Zertifikat erstellt. Vorher stand da Fremdzertifikat drinne. Jetzt geht die https-Verbindung wieder. Also lag es devinitiv an der Syno. Seht ihr da jetzt noch ein Problem?
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat