SSL-Verschlüsselung für Imap, Pop3, smtp

  • Moin,


    anbei drei Run-Skripte, mit denen Imap, Pop3 und Smtp über SSL verschlüsselt betrieben werden können. Ich hoffe jedenfalls, dass diese Lösung wirklich sicher ist....


    Zum Betrieb erforderlich ist stunnel. apt-get stunnel reicht. In der /usr/local/pd-admin2/etc/imapd-ssl muss das Zertifikat entsprechend konfiguriert werden.


    Weiss jemand, welche Rechte das Zertifikat von stunnel haben muss, damit dieser nicht meckert? Wenn ich das Zertifit read-only für root mache (chmod 400), so funktioniert pop3s einwandfrei. ssmtp aber nicht. Warum?


    Für Imaps :



    Für pop3s:


    Für Secure SMTP


    mz

  • Update: Bei einer erforderlichen Systemänderung wurde der verschlüsselte Zugriff gleich so eingerichtet, dass für pop3s, imaps und smpts 3 verschiedene Zertifikate zum Einsatz kommen. Dies löst auch eventuell auftretende Probleme mit Rechten.
    - Imaps und pop3s wurde unverändert gelassen.
    - Für smtps wurde das Script mkpop3cert kopiert & angepasst und damit das Zertifikat generiert. /service/qmail-smptds/run ändert sich dementsprechend zu:


    Wichtig:
    Eigentümer von smtpd.pem ist qmaild. Ist dies nicht der Fall, so sind entsprechende Fehlermeldungen (Permission denied) in /var/log/daemon.log zu verzeichnen.

  • Ich habe auch ungefähr nach diesem hier vorgestellen Schema POP3s/sSMTP am Laufen.


    Kennt ihr das Problem, dass man sporadisch beim Versand einer Mail wieder aufgefordert wird das PW einzugeben?


    Der Server Antwortete dann mit
    454 oops, unable to write pipe and I can't auth


    Bei mir kam das in ca. 10% der Fälle vor. Und zwar nur über die stunnel Verbindung (SMTP und MSA waren nicht betroffen).


    Nachdem ich softlimit ausschliessen konnte, habe ich diverse strace Sessions gestartet, um der Sache auf den Grund zu gehen.


    Der Unterschied zwischen dem normalen Versenden und dem Versenden per SSMTP im strace ist:

    Code
    msa:
    execve("/var/qmail/bin/qmail-smtpd", ["/var/qmail/bin/qmail-smtpd", "example.org", "/usr/local/pd-admin2/bin/checksm"..., "/bin/true"], [/* 12 vars */]) = 0
    stunnel:
    execve("/var/qmail/bin/qmail-smtpd", ["example.org", "/usr/local/pd-admin2/bin/checksm"..., "/bin/true"], [/* 13 vars */]) = 0


    Die bei mir eingesetzte Version von stunnel 4.22 nutzt einen Perl Wrapper um das eigentliche stunnel4 aufzurufen (ftp://ftp.stunnel.org/stunnel/stunnel3). Dieser soll lediglich dazu dienen, dass man stunnel4 auch mit der alten stunnel3 Syntax aufrufen kann.


    Diesen benutze ich auch in meinem run Script:


    Und genau dieser Wrapper sorgt dafür, dass in der stunnel Variante das $0 auf den Hostname und nicht auf qmail-smtp gesetzt wird!


    So sieht es aus:
    ...
    print("exec = $opt_l\n") if defined $opt_l;
    print("execargs = " . join(' ', @ARGV) . "\n") if @ARGV;


    So sollte es aussehen:
    ...
    print("exec = $opt_l\n") if defined $opt_l;
    print("execargs = $opt_l " . join(' ', @ARGV) . "\n") if @ARGV;



    Das ganze bewirkt, dass der $HOSTNAME verschluckt wird (, da dieser als $0 gesehen wird) UND dass qmail-smtp die Daten nicht an checksmtppasswd piped sondern an /bin/true!!


    In 10% der Fälle kommt der /bin/true Aufruf schneller zurück als dass qmail-smtps die Daten pipen kann.


    Das tollste daran ist, dass Username/Passwort so _nie_ geprüft werden und man ein schönes, SSL verschlüsseltes Open Relay hat!


    Ich weiss bis heute nicht, wie lange das bei mir offen war bzw. wann ich stunnel auf eine Version >= 4.05 geupdated habe. Bei der Erstinbetriebnahme meine ich hatte ich diverse Tests unternommen.
    Vom stunnel Author kommt bisher keine Reaktion, daher würde ich an eurer Stelle die o.g. Zeile ändern, sofern Ihr das in gleicher Konstellation betreibt.

  • Sehr merkwürdig, dass es keine Reaktion gibt.
    Eigentlich jeder der o.g. Anleitung SMTPS in Betrieb hat und stunnel4 dafür nutzt müsste sich so ein Open Relay gebaut haben.


    Hat wirklich keiner ein Problem damit?

  • Moin!


    damals hatte ich sehr ausführlich nach potentiellen Relay Schwachstellen gesucht. Das ist aber lange, lange her. Daher:
    - Magst du erklären wie du auf ein SSL Open Relay testest?
    - Und kann es sein, dass eben dieses open relay durch das /var/qmail/bin/tcp-env relaylock statement in meinem Skript unterbunden wird?


    Michael

  • Meine Güte hab ich eine Reaktionszeit. Ich muss wohl mal wieder das Notify aktivieren ;-)


    Die Tests hatte ich mit strace gemacht und den STMP Dialog mit dem openssl client per Hand durchgetestet. Als Nagativtest hab ich dann einfach einen falschen User / Passwort genutzt. Ging trotzdem -> Panik


    Relaylock nutze ich bei mir nicht, das ist ja nur für SMTP after POP und dass macht nur sinn für die User die immer noch per Port 25 versenden.


    Inzwischen ist das in stunnel übrigens gefixed. Siehe Changenotes http://www.stunnel.org/?page=sdf_ChangeLog 4.45


    so sollte es dann ganz richtig aussehen:

    Code
    print("exec = $opt_l\nexecargs = " . join(' ', $opt_l, @ARGV) . "\n") if defined $opt_l;
  • Also ich habe dies jetzt mit mehreren Konfigurationen versucht nachzuvollziehen. Nur bekomme ich beim besten Willen keinen Mailversand mit falschen Passwort etc. hin. Grübel.


    Kann es sein, dass dieser Fall wirklich nur bei z. B. besonders hoher Load etc. auftritt? Oder wieso hast du das Problem, ich aber nicht?

  • Nein bei mir war das immer reproduzierbar, nicht nur unter Last.


    Durch den Bug in dem stunnel Wrapper wird das zweite Argument nach der -l Option gefressen.


    Bei mir war das der $HOSTNAME bei dir ist es relaylock.


    Ich nehme also an, dass bei dir der Mechanismus des relaylocks nicht funktioniert,
    oder kannst du SMTPS ohne user/pw nutzen wenn du vorher POP Zugriff hattests?

  • Zitat

    Original von kai
    Ich nehme also an, dass bei dir der Mechanismus des relaylocks nicht funktioniert,
    oder kannst du SMTPS ohne user/pw nutzen wenn du vorher POP Zugriff hattests?


    SMTPS ohne /PW funktioniert nur nach vorherigem Pop-Abruf. Reproduzierbar. Ansonsten natürlich auch ohne vorhergehendem Pop-Abruf mittels Authentifizierung.

  • OK, wenn du ganz sicher sein willst was da passiert, dann musste da mal ein strace mitlaufen lassen und dir dort die Aufrufkette ansehen.


    Kann ja durchaus sein, dass das mit deiner Config kein Problem ist.


    Ich hätte aber vermutet, dass nicht alle Leute dort das relaylock mit drin haben und zumidnest die müssten das gleiche Problem haben wie ich hatte.


    Ich habe die alte Krücke Relaylock wirklich nur bei Port 25 mit drin.
    Bei den anderen Ports macht das eigentlich keinen Sinn, weil die User dort ja eh gezwungen werden User/PW zu nutzen.
    Relaylock erlaubt der IP zu Senden wenn vorher per POP gezogen wurde.
    Der Zugriff ist hier also nicht zwangsläufig usergebunden, da sich hinter einer IP durchaus eine ganze Menge User verbergen können.


    Was mir noch einfällt. Welche Version von stunnel hast du denn überhaupt im Einsatz?
    Das Problem tritt nur auf bei Versionen zwischen 4.0 und 4.45.
    Wenn man also noch eine gaaaanz alte 3er Verion hat, dann gibts auch kein Problem.

  • Zitat


    OK, wenn du ganz sicher sein willst was da passiert, dann musste da mal ein strace mitlaufen lassen und dir dort die Aufrufkette ansehen. Kann ja durchaus sein, dass das mit deiner Config kein Problem ist.


    Mag wirklich so sein... auch mit strace komm ich hier nicht wirklich dahin, dein Problem nachzuvollziehen. Ich werde dem bei Gelegenheit mal weiter nachgehen.



    Zitat


    Ich habe die alte Krücke Relaylock wirklich nur bei Port 25 mit drin.
    Bei den anderen Ports macht das eigentlich keinen Sinn, weil die User dort ja eh gezwungen werden User/PW zu nutzen.


    Relaylock macht an für sich bei SMPTS wirklich keinen Sinn, wo ich ja sowieso schon verschlüsselt und authentifiziert versenden kann. Insofern ist dies bei uns wirklich aus historischen Gründen drin wie auch aus dem Grund, dass SMPTS bei unserem Server - aus welchen Gründen immer - nicht nachgefragt wird. Das mag man aber auch daran festmachen, dass die entsprechende Maschine keine kommerziellen Kunden sieht.


    Zitat


    Was mir noch einfällt. Welche Version von stunnel hast du denn überhaupt im Einsatz?
    Das Problem tritt nur auf bei Versionen zwischen 4.0 und 4.45.


    Wir setzen Debian ein. Insofern ist die Version durchaus betroffen.
    Wenn man also noch eine gaaaanz alte 3er Verion hat, dann gibts auch kein Problem.[/quote]

  • Tag zusammen,


    nachdem ich nun (endlich) SSL Verschlüsselung für IMAP, POP & SMTP einführen möchte wollte ich mich erkundigen, ob man diesen Thread mit den aktuellen Versionen der SE und pdAdmin auch noch als Anleitung nehmen kann, oder eher nicht mehr?


    Wenn jemand noch Ergänzungen zu diesem How-To hat wäre ich dankbar.

  • Danke!
    die konfiguration hat geklappt - zumindest sehe ich keine fehler in den Logs... - was ich hatte war:

    Code
    /etc/stunnel/stunnel.pem: No such file or directory


    Was ich aber mit einem eintrag in der "stunnel.conf" auf die mail.pem gesetzt habe...


    könnt ihr mir sagen, ob das so in ordnung ist? sind im prinzip die configs...


    netstat -tulpe:

    Code
    tcp6 0 0 [::]:ssmtp [::]:* LISTEN root 4908 1366/tcpserver
    tcp6 0 0 [::]:ftp [::]:* LISTEN nobody 5144 1351/proftpd: (acce
    tcp6 0 0 [::]:ssh [::]:* LISTEN root 4444 1251/sshd
    tcp6 0 0 [::]:imaps [::]:* LISTEN root 4983 1343/tcpserver
    tcp6 0 0 [::]:pop3s [::]:* LISTEN root 4897 1338/tcpserver


    Das Problem ist aber, dass die ports nicht erreichbar sind von extern...!


    smtps:


    imaps:


    Änderungen in imapd-ssl: Anpassung Pfad der PEM-Datei - müsste doch reichen, oder?


    Problem mit SSL: im daemon.log steht: Enter pem passphrase ... ist das normal? grundsätzlich sollte da keine abgefragt werden...!


    Zur Sicherheitsfrage:
    jetzt aber eine Frage - Debian sagt mir, dass 4.29 von STUNNEL installiert ist..
    Wenn der Fehler bis 4.45 existierte - wäre es da nich Sinnvoll manuell ein Update von stunnel einzuspielen? ODer gibt es hoffnung, dass debian das Paket aufnimmt?


    Ich hätte mal die aktuellste Version kompiliert - würde es reichen die "alte" stunnel mit der neu kompilierten stunnel zu ersetzen?
    Wie könnte man sich sonst helfen, damit man kein "ssmtp relay" ist?


    Ich tu mir mit diesen run-scripten ein bisschen schwer - und hoffe mal wieder auf Hilfe..! Danke!

  • In Debian lenny und squeeze in /usr/bin/stunnel folgendes fixen:


    Das hier auskommentieren

    Code
    #print("exec = $opt_l\n") if defined $opt_l;#print("execargs = " . join(' ', @ARGV) . "\n") if @ARGV;


    Und stattdessen das hier rein

    Code
    print("exec = $opt_l\nexecargs = " . join(' ', $opt_l, @ARGV) . "\n") if defined $opt_l;


    Dann frisst der Wrapper nicht das zweite Argument hinter -l

  • Wenn Sie die von uns empfohlene Variante nutzen (also nicht die hier beschriebene mit stunnel) koennen Sie die Einstellung in /usr/local/pd-admin2/etc/imapd-ssl vornehmen:


    ##NAME: TLS_PROTOCOL:0
    #
    # TLS_PROTOCOL sets the protocol version. The possible versions are:
    #
    # OpenSSL:
    #
    # SSL3 - SSLv3
    # SSL23 - all protocols (including TLS 1.x protocols)
    # TLS1 - TLS1
    # TLSv1.1 - TLS1.1
    # TLSv1.2 - TLS1.2
    #
    # Leave it unset to use any protocol except SSL 2.


    Die Dienste muessen anschliessend neu gestartet werden.