Danke! Ach hierfür Fehlermeldung "Unbekanntes ZA-Zertifikat" seit 1 Stunde
Schönen Tag noch.
ciao, Stefan
Danke! Ach hierfür Fehlermeldung "Unbekanntes ZA-Zertifikat" seit 1 Stunde
Schönen Tag noch.
ciao, Stefan
Hallo Thomas,
ich kann Dir bestätigen, dass thebat selbständig die Fensteraufteilung ändert. Mir ist auch schon mal aufgefallen, dass beim Anschluss eines größeren Monitors die Fensteraufteilung automatisch auf die "2" gesetzt wurde und beim wechseln auf einen kleineren Monitor wieder auf die "3". Aus Sicht von thebat ist es wohl ein Feature. Vielleicht gibt es eine Einstellung dazu oder man macht ritlabs darauf Aufmerksam, dass ein entsprechender Schalter sinnvoll wäre.
ciao, Stefan
Ich fahre hier mal mit 8.5.4 protocol error BuildClientKeyExchange fort.
Deine Interpretation trifft es besser. Das leuchtet ein.
Zitat von IABCJedenfalls verschickt TheBat die Emails mit dieser Beta wieder (getestet mit 32Bit).
Davon geht ich aus. Nur, wieso wird eine schwächere Verschlüsselung genutzt, wenn doch beide Stellen die starken Verschlüsselungen unterstützen. Irgenwie treibt mich das um, andererseits habe ich viel zu wenig Ahnung um die richtigen Fragen zu stellen … mmmh eine Konfliktsituation Die trage ich jetzt aber im Stillen aus.
Vielen Dank für die Hilfe.
Schönen Tag noch.
ciao, Stefan
Zitat von ritlabsWhen the server presents a Diffie-Hellman ephemeral key which on the consideration that The Bat! considers "unsafe", now The Bat! just continues with that weak key. However, The Bat! checks the digital signature of this ephemeral key. So, an attacker cannot inject a bad key. It is the server that generated this bad key. So The Bat! will just continue, because it is the server in the end that set ups his key.
Der Mailserver liefert einen schwachen Schlüssel weil er davon ausgeht, dass TheBat eine unsichere Anwendung sei und theBat wiederum lässt sich (nun ohne Ausnahmefehler anzuzeigen) auf diesen schwächeren Schlüssel ein. [TheBat prüft aber dennoch "irgendwas" um das Einschleusen eines Abhörerschlüssels? zu verhindern?]
Es liegt letztlich am Mailserver, der mit einem schwachen Schlüssel einsteigt während TheBat sein Bestes gibt um das auszugleichen?
Interpretiere ich das richtig bzw. was genau schreibt der da?
Zwei Fragen:
1. Ich würde jetzt gerne die Beta ausprobieren. Kann ich die über die stable installieren und dann wenn die stable erschienen ist die wiederum drüberinstallieren?
2. Bedeutet "The Bat! no longer terminates the connection", dass halt auf den Abbruch verzichtet wird, aber die gewünschte Verschlüsselung wegen der "unsicheren Primzahl" eben nicht etabliert werden konnte?
Ach … Doppelklick! Yo, ist erledigt
Das Kästchen finde ich schon intuitiv. Das impliziert schon sowas wie "hier anhaken". Da fehlt halt eindeutig ein "pointer" bei mausüber.
Schönen Sonntag noch.
> bin auf zu vielen Foren als Moderatorin
Vor diesem Einsatz und Engagement kann man nur den Hut ziehen. Was ich hiermit tue. Danke dafür.
Also ich hab da nur zwei: "Neues Thema" und "Antworten". Siehe Anhang
Man könnte den Thread auch erst mit dem Erscheinen einer Version die das Problem behebt als gelöst markieren. Du hast freie Hand.
hasta luego, Stefan
> Ganz oben "Thema bearbeiten"
Das würde ich gerne tun, aber ich glaube ich verDAUe so langsam. Ich kann den Knopf nicht finden …
[modedit] Post gekürzt kopiert nach Vivaldi-Thread
ZitatHello Stefan,
we are aware of the problem "protocol error BuildClientKeyExchange" and will fix it in a couple of days, we hope.
"… we hope"
OK, was macht man den jetzt mit dem Thread, als gelöst markieren? Wie geht das?
Mensch Lilo Du Tier … ähm Drachin Vielen Dank für Deine Hilfe.
Ich denke jetzt muss ich mich tatsächlich an Ritlabs wenden. Denn zwischenzeitlich habe ich auch von Hetzner eine Aussage diesbezüglich erhalten. Ich erstatte Report wenn ich was Neues weiß.
Zitat von HetznerAlles anzeigen> unser Mailserver unterstützt definitiv die genannte Chiffre, dies lässt sich auch recht einfach verifizieren:
> -----------8<-----------8<---------
> $ openssl s_client -connect mail.your-server.de:465 -cipher ECDHE-RSA-AES256-SHA
> CONNECTED(00000003)
> depth=2 C = US, O = DigiCert Inc, OU = https://www.batboard.net/www.digicert.com, CN = DigiCert Global Root G2
> verify return:1
> depth=1 C = US, O = DigiCert Inc, OU = https://www.batboard.net/www.digicert.com, CN = RapidSSL TLS RSA CA G1
> verify return:1
> depth=0 CN = *.your-server.de
> verify return:1
> ---
> Certificate chain
> 0 s:/CN=*.your-server.de
> i:/C=US/O=DigiCert Inc/OU=http://www.digicert.com/CN=RapidSSL TLS RSA CA G1
> 1 s:/C=US/O=DigiCert Inc/OU=http://www.digicert.com/CN=RapidSSL TLS RSA CA G1
> i:/C=US/O=DigiCert Inc/OU=http://www.digicert.com/CN=DigiCert Global Root G2
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
> MIIFwjCCBKqgAwIBAgIQBM2igJQIEXq/kuPCfjfE1zANBgkqhkiG9w0BAQsFADBg
> [...]
> SSL handshake has read 3345 bytes and written 245 bytes
> Verification: OK
> ---
> New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDHE-RSA-AES256-SHA
> [...]
> Verify return code: 0 (ok)
> Extended master secret: yes
> ---
> 220 sslproxy05.your-server.de ESMTP Exim 4.89 Wed, 11 Jul 2018 17:17:19 +0200
Cool, Vielen Dank.
Die Adressbücher von der 8.5.2 und der 8.5.4 bzw. 8.5.6, enthalten jeweils das "DigiCert Global Root G2" bereits.
Über den Tab "Zertifikate", Doppelklick auf den Eintrag erscheint ein Dialog mit wiederum drei Tabs. Im Ersten ("Allgemein") steht.
ZitatThe Bat! kann dieses Zertifikat nutzen für: Nachrichten-Verschlüsselung - nein, Prüfe digitale Signatur einer Nachricht - nein, TLS-Verbindungen - nein.
Also "TLS-Verbindungen - nein" erschien mir immerhin auffällig, also habe ich doch das Zertifikat von Hetzner importiert. Über das Adressbuch, es ist genau das gleiche wie das bereits vorhandene. Wie kann es anders sein… planloses rumgestochere… Alles in Allem also wenig weitergekommen.
Bis eben. Noch mal alle Schalter angeschaut und festgestellt, dass ich einen noch nicht probiert hatte. /TLS_DISABLE_PERFECT_FORWARD_SECRECY hat bei mir jetzt geholfen.
ZitatNew command-line parameter "/TLS_DISABLE_PERFECT_FORWARD_SECRECY" to disable perfect forward secrecy
Mal davon abgesehen, dass sich immer noch einige Fragezeichen (z.B. "TLS-Verbindungen - nein"?) im Orbit um mein Haupt befinden, verstehe ich das nun auch wieder nicht.
Bei Heise (https://www.heise.de/security/artik…cy-1923800.html) kann man da was finden.
Dort ist sind die Chiffren
erwähnt, die von Hetzner ebenfalls unterstützt und als Deckungsgleich mit den Sammlungen von TheBat! identifiziert hat.
OK. Also bleibt jetzt die Frage, wieso muss man PFS abschalten wenn es doch beide unterstützen.
Vielleicht weil die Sammlungen von oben nach unten abgearbeitet werden und das erste das trifft wird benutzt und das ist eben eine ohne PFS?
Oh Mann, ich check das alles nicht.
Schönen Abend noch.
ciao, Stefan
mmh, also Hetzner meint:
Zitateinige sehr alte Betriebssysteme enthalten noch nicht das Wurzel-Zertifikat, welches bei unserem *.your-server.de Zertifikat eingesetzt wird.
Dieses Wurzel-Zertifikat lässt sich meistens manuell im entsprechenden System importieren und dort im Trust-Store ablegen.
Diese Zertifikat ist auch auf https://hetzner-status.de/#9207 einsehbar/kopierbar, im Eintrag "Update des Mailsystems".
Bitte prüfen Sie, ob Sie das entsprechene Zertifikat im Betriebssystem oder Ihrem eMail-Client hinterlegen können.
Das würde ja bedeuten, dass Ritlabs diese Zertifkat entfernt hat, oder?
Kann man den die Stammzertifikate in thebat bearbeiten?
Ja, und ich habe geantwortet mit der Auskunft, dass es nur beim Senden zu dem Problem kommt.
Seine Vermutung mit dem nicht verifizierbaren Zertifikat könnte passen. Die Zeile TLS-Protokollfehler: Interner Fehler BuildClientKeyExchange ersetzt im Protokoll die Zeile TLS-Handshake vollständig
Ich warte aber noch auf eine Antwort und würde mich dann damit bei Ritlabs vorstellen.
> folgende TLS-Chiffren werden von mail.your-server.de zum Versenden von Mails unterstützt:
> DHE-RSA-AES256-GCM-SHA384 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
> ECDHE-RSA-AES256-GCM-SHA384 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
> DHE-RSA-AES128-GCM-SHA256 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
> ECDHE-RSA-AES128-GCM-SHA256 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
> DHE-RSA-AES256-SHA256 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
> DHE-RSA-AES256-SHA Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
> DHE-RSA-CAMELLIA256-SHA Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
> ECDHE-RSA-AES256-SHA384 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
> ECDHE-RSA-AES256-SHA Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
> DHE-RSA-AES128-SHA256 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
> DHE-RSA-AES128-SHA Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
> DHE-RSA-CAMELLIA128-SHA Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
> ECDHE-RSA-AES128-SHA256 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
> ECDHE-RSA-AES128-SHA Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
> AES256-SHA Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
> AES128-SHA Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
> TLS wird in den Versionen 1.0 - 1.2 unterstützt.
> Gemeinsam unterstützte Chiffren aus Ihrer Liste wäre demnach z.B.:
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> D.h. gemeinsame Chiffren sind auf jedenfall vorhanden - daher könnte es sein,
> dass das Problem eine andere Ursache hat.
> Denkbar wäre z.B., dass das Server-Zertifikat nicht verifiziert werden kann -
> allerdings wäre dann die Fehlermeldung "TLS-Protokollfehler: Interner Fehler
> BuildClientKeyExchange" etwas seltsam und irreführend.
> Tritt das Problem NUR beim Senden auf, oder auch beim Abrufen der Mails?
Alles anzeigen
to be continued…
ZitatDie Schalter sind teilweise hier drin beschrieben:
https://www.ritlabs.com/de/products/th…n-history/7122/
OK. Danke, da muss ich bisschen probieren.
ZitatTheBat! 8.5.4
Wo kommt den dieses changlog her, auf der Website steht das so nicht.
ZitatHast du auch mal beim Ritlabs-Support auf http://www.ritlabs.com/en/support/ticket_list.php angefragt?
Nee, noch nicht, ich bin im Moment noch viel zu planlos. Ich könnte höchstens ein "funzt net" abgeben
Der Support von Hetzner frägt nach, ob ich den im Client Einstellungen dazu hätte.
In den Einstellungen konnte ich jetzt nix finden. Aber es gibt ja offensichtlich Kommandozeilen Parameter, von denen ich bisher auch nichts wusste.
Wo gibt es den eine Übersicht über die verfügbaren Parameter und gibt es dort vielleicht Schalter die das Verhalten bezüglich TLS beeinflussen?
/DISABLE_TLS12 hat bei mir keinen Auswirkung die ich erkennen könnte.
Oder Hetzner implementiert …
Vielen Dank.
Hat aber scheinbar funktioniert. Mails kann ich wieder verschicken.
Unter http://ritlabs.com/de/products/thebat/archive-versions.php findet man nur bis 7.x.
Das macht aber nichts, ich habe den letzten Download noch gefunden v8.5.2. Die thebat64.exe habe ich entfernt und den Installer laufen lassen. Eine "Reparatur" hat er mir nicht angeboten.
Wenn ich das changelog für die 8.5.4er anschaue, geht es ja hauptsächlich um TLS.
TLS 1.2. Folgende Verschlüsselungssammlungen werden unterstützt:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHA SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHASSL_RSA_WITH_RC4_128_MD5
Kann man den aus dem Protokollauszug mit dem Hetznerserver rauslesen, welche Methode verwendet wurde?
hasta luego, Stefan
Danke für den Tipp. Das möchte ich auch, weiß aber nicht wie ich es anstellen soll.
Wie hast Du das gemacht? Einfach den Installer mit der 8.5.2 benutzen und drüberbügeln? Weißt Du wo ich den Download herbekomme?
hasta luego, Stefan