Antworten per E-Mail

Zurzeit (seit dem letzen Update / aktivieren des Events Plugin) kann nicht auf Beiträge per E-Mail geantwortet werden.
Hatte einer von euch diesen Fall schon einmal oder kann mit den Hinweisen aus den Logs etwas anfangen?

https://forum.makerspace-gt.de/logs/

 Job exception: SSL_connect returned=1 errno=0 state=error: dh key too small 

/usr/local/lib/ruby/2.6.0/net/protocol.rb:44:in `connect_nonblock'
/usr/local/lib/ruby/2.6.0/net/protocol.rb:44:in `ssl_socket_connect'
/usr/local/lib/ruby/2.6.0/net/pop.rb:553:in `do_start'
/usr/local/lib/ruby/2.6.0/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:43:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:18:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
/var/www/discourse/app/jobs/base.rb:279:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_scheduler-0.12.2/lib/mini_scheduler/manager.rb:86:in `process_queue'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/mini_scheduler-0.12.2/lib/mini_scheduler/manager.rb:36:in `block (2 levels) in initialize'

… klingt für mich nach einem guten Ausgangspunkt zu gucken, was da klemmt?

Ggf. hat der Mailanbieter ja auch die Mindestwerte angepaßt?

Scheint am update zu liegen:

Wie kommen wir aus dem beta Kanal raus?

Edit: schon gefunden

Nix updaten, bis eine non-Beta mit höherer Versionsnummer existiert.

gucke ich mir eine Mail an forum@makerspace-gt.de genauer an kann ich folgendes finden:

(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))

Lese ich etwas auf https://weakdh.org/ findet ich folgendes:

If you’re a sysadmin or developer …

Make sure any TLS libraries you use are up-to-date, that servers you maintain use 2048-bit or larger primes, and that clients you maintain reject Diffie-Hellman primes smaller than 1024-bit.

Also benutzt lima-city schwache Krypto. Ich habe mal eine Mail an support@lima-city.de geschrieben.

Hmm.

From: Michael via Forum Makerspace Gütersloh <noreply@discourse-mksp.4830.org>

… ich glaube, ich kann mit die Antwort per Mail sparen, daher gleich hier:

Uh-oh … TLS bei Mail ist noch ein ganz anderes „Problem“ als im Web; Mail ist oft selfsigned, da es eh’ nicht verifiziert wird (jahrelang wurde), und auch eher selten angefaßt wird (außer bei Mail-Providern, die haben ja keine anderen Hobbies ;)). Ich mußte bislang 2(!) Mailserver auf no-tls forcen, weil sie zu schwache Krypto, die mein uralter sendmail halt nur hat, ablehnen …

… aber sag’ gerne mal Bescheid, was zurückkam als Antwort :wink:
-kai

Wo kann ich denn no-tls im discourse einstellen?

Habe die Option vorübergehend deaktiviert.

Hallo Michael,
danke für die Rückmeldung. Der Postfix unter mail.lima-city.de hat - laut dem git für die Konfig - seit 2015 einen DH-Key spezifiziert.

openssl dhparam -in /etc/ssl/dhparams.pem -check -text

Zeigt mit für den Key „PKCS#3 DH Parameters: (2048 bit)“ an. Das scheint mir also soweit korrekt zu sein und stimmt genau mit dem weak-dh Deployment Guide überein (bis auf ein paar Ciphers, die wir noch nicht abgelehnt haben).

Die von Dir genannten 256 Bit sind übrigens für AES - wo 256 Bit vollkommen ausreichen, da geht es um symmetrische Krypto, das Problem sollen aber die Diffie-Hellman-Parameter sein.

Irgendwas scheint mir da noch nicht ganz richtig zu sein. Oder haben die Ciphers das Problem schon gelöst?

Mit freundlichen Grüßen

Dann muss das Problem noch an einer anderen Stelle liegen. @wusel kannst du noch ein Postfach bei 4830.org einrichten das wir vorübergehend nutzen können?

Hallo Michael,
danke für die Geduld. Ich habe mich noch etwas eingehender mit der Sache beschäftigt, und leider ist das gar nicht so simpel zu lösen. Die OpenSSL-Version, die euer Discourse benutzt, erlaubt keine kleineren DH-Keys mehr. Der Dovecot (nicht der Postfix, danach hatte ich geguckt, ich dachte es ginge um Versand) den wir einsetzen (aus Ubuntu 12.04 mit ESM) kann aber keine eigenen DH-Keys. Das ist doof, sehr doof.

Mir fallen da aber zum jetzigen Zeitpunkt aber nur zwei Lösungen ein, eine davon ist möglicherweise nichts betreibbar und beide können wir nicht mal so eben ausrollen, sondern müssen sie erst ausreichend testen, bevor wir sie auf dem Live-System ausrollen. Da die Mail-Infrastruktur das wichtigste System ist können wir da nicht so schnell eine Lösung bereitstellen, wie ich es gerne hätte sondern müssen gründlich testen.

Dass die DH-Keys so nicht bleiben können ist denke ich auch klar. Es geht also weder warten noch überstürzen. Ich melde mich, sobald es dazu Fortschritte gibt. Bis dahin habe ich leider keinen Lösungsvorschlag, der nicht das Verbiegen vom Client beinhaltet, tut mir leid.

Ich wünsche Dir noch einen schönen Abend!

Und nun? @CommanderRiker ein eigener Mailserver?

Hier hat noch jemand das gleiche Problem:

Als Workaround wird vorgeschlagen:

I’d say that’s so mething for Rackspace to fix. As a workaround, you should be able to edit /etc/ssl/openssl.cnf and remove the CipherString = DEFAULT@SECLEVEL=2 at the end of the file. Sidekiq should pick up the new OpenSSL settings after restarting the container.

Habe die besagte Zeile auskommentiert und nginx neu geladen, leider kein Effekt. Muss noch etwas gemacht werden?

Gibt’s schon, discourse-mksp@4830.org, Password siehe Telegram.

Da steht „after restarting the container“, ggf. mal genau das machen?

:man_facepalming: Geht vorerst wieder…

1 Like