-SSLv3 aktuell empfohlene master.cf für TLS ???
Ich würde ja auch gerne SSLv3 abschalten, aber leider bin ich mir nicht sicher was ich in meiner master.cf raus nehmen muss so dass TLS noch funktioniert. Oder passt das alles so noch? Kann mir einer helfen bitte?
---Postfix master.cf------------------------------------------------------------ smtp inet n - - - - smtpd submission inet n - - - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_local_domain=$myhostname -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_login_maps=mysql:/etc/postfix/mysql-virtual_sender.cf -o smtpd_sender_restrictions=reject_sender_login_mismatch -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject smtps inet n - - - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o broken_sasl_auth_clients=yes
pickup fifo n - - 60 1 pickup -o content_filter= -o receive_override_options=no_header_body_checks cleanup unix n - - - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgr unix - - - 1000? 1 tlsmgr rewrite unix - - - - - trivial-rewrite bounce unix - - - - 0 bounce defer unix - - - - 0 bounce trace unix - - - - 0 bounce verify unix - - - - 1 verify flush unix n - - 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - - - - smtp relay unix - - - - - smtp showq unix n - - - - showq error unix - - - - - error retry unix - - - - - error discard unix - - - - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - - - - lmtp anvil unix - - - - 1 anvil scache unix - - - - 1 scache maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/bin/maildrop -d vmail ${extension} ${recipient} ${user} ${nexthop} ${sender} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient scalemail-backend unix - n n - 2 pipe flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension} mailman unix - n n - - pipe flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user}
dovecot unix - n n - - pipe flags=DROhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${nexthop}
# zusätzlicher transport ohne Filter für newsletter z.B. newssmtp unix - - n - 50 smtp -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
amavis unix - - - - 4 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes
127.0.0.1:10025 inet n - - - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
policy-spf unix - n n - - spawn user=nobody argv=/usr/sbin/postfix-policyd-spf-perl
--------------------------------------------------------------------------------------------------------------------------------------------------- M.f.G JO!
Am 27.10.2014 um 13:43 schrieb Joachim Burbach:
Ich würde ja auch gerne SSLv3 abschalten, aber leider bin ich mir nicht sicher was ich in meiner master.cf raus nehmen muss so dass TLS noch funktioniert. Oder passt das alles so noch? Kann mir einer helfen bitte?
---Postfix master.cf------------------------------------------------------------ smtp inet n - - - - smtpd submission inet n - - - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_local_domain=$myhostname -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_login_maps=mysql:/etc/postfix/mysql-virtual_sender.cf -o smtpd_sender_restrictions=reject_sender_login_mismatch -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject smtps inet n - - - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o broken_sasl_auth_clients=yes
pickup fifo n - - 60 1 pickup -o content_filter= -o receive_override_options=no_header_body_checks cleanup unix n - - - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgr unix - - - 1000? 1 tlsmgr rewrite unix - - - - - trivial-rewrite bounce unix - - - - 0 bounce defer unix - - - - 0 bounce trace unix - - - - 0 bounce verify unix - - - - 1 verify flush unix n - - 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - - - - smtp relay unix - - - - - smtp showq unix n - - - - showq error unix - - - - - error retry unix - - - - - error discard unix - - - - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - - - - lmtp anvil unix - - - - 1 anvil scache unix - - - - 1 scache maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/bin/maildrop -d vmail ${extension} ${recipient} ${user} ${nexthop} ${sender} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient scalemail-backend unix - n n - 2 pipe flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension} mailman unix - n n - - pipe flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user}
dovecot unix - n n - - pipe flags=DROhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${nexthop}
# zusätzlicher transport ohne Filter für newsletter z.B. newssmtp unix - - n - 50 smtp -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
amavis unix - - - - 4 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes
127.0.0.1:10025 inet n - - - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
policy-spf unix - n n - - spawn user=nobody argv=/usr/sbin/postfix-policyd-spf-perl
M.f.G JO!
evtl hilft das
https://sys4.de/de/blog/2014/10/21/poodle-bug-postfix-sslv3-deaktivieren/
Best Regards MfG Robert Schetterer
Am Montag, den 27.10.2014, 14:03 +0100 schrieb Robert Schetterer:
evtl hilft das
https://sys4.de/de/blog/2014/10/21/poodle-bug-postfix-sslv3-deaktivieren/
Mich würde mal interessieren wie denn so ein Angriff überhaupt aussehen soll. Meine eigene Verbindung knacken macht wenig Sinn. Jemand der einfach nur mitlauscht kann den Handshake auch nicht manipulieren, dazu müsste er schon "man-in-the-middle" werden, das kann er aber nur indem er das DNS manipuliert. Es müssten also 2 Sicherheitslücken zusammentreffen, das halte ich für unrealistisch.
Am 27.10.2014 um 16:44 schrieb Joachim Fahrner:
Am Montag, den 27.10.2014, 14:03 +0100 schrieb Robert Schetterer:
evtl hilft das
https://sys4.de/de/blog/2014/10/21/poodle-bug-postfix-sslv3-deaktivieren/
Mich würde mal interessieren wie denn so ein Angriff überhaupt aussehen soll. Meine eigene Verbindung knacken macht wenig Sinn. Jemand der einfach nur mitlauscht kann den Handshake auch nicht manipulieren, dazu müsste er schon "man-in-the-middle" werden, das kann er aber nur indem er das DNS manipuliert. Es müssten also 2 Sicherheitslücken zusammentreffen, das halte ich für unrealistisch.
Im Grunde will man einfach nicht darauf warten das die Dinge schlimmer werden und einfach vorbeugen, seit Heartbleed ist Vorsicht die Mutter der Porz...kiste
Best Regards MfG Robert Schetterer
Am 2014-10-27 16:44, schrieb Joachim Fahrner:
Am Montag, den 27.10.2014, 14:03 +0100 schrieb Robert Schetterer:
evtl hilft das
https://sys4.de/de/blog/2014/10/21/poodle-bug-postfix-sslv3-deaktivieren/
Mich würde mal interessieren wie denn so ein Angriff überhaupt aussehen soll. Meine eigene Verbindung knacken macht wenig Sinn. Jemand der einfach nur mitlauscht kann den Handshake auch nicht manipulieren, dazu müsste er schon "man-in-the-middle" werden, das kann er aber nur indem er das DNS manipuliert. Es müssten also 2 Sicherheitslücken zusammentreffen, das halte ich für unrealistisch.
..vorallem stellt sich mir zusätzlich die Frage:
gegen was genau will ich mich denn hier überhaupt genau schützen..? POODLE ist doch quasi als Man-in-the-Middle bei der Aushandlung der Verschlüsselung so lange die Antworten kaputt zu machen bis sich die beiden Systeme sich so weit runtergehangelt haben, dass nur noch SSLv3 als gemeinsame Basis übrig bleibt - was ich als Angreifer erreichen wollte, weil ich dann einfach(er) mitlauschen kann... Wenn ich jetzt einer Seite (<- also eben als Admin des Servers) SSLv3 ganz verbiete, dann werden sich doch beide Seiten auf *gar keine* Verschlüsselung mehr einigen (können) und fallen auf gänzlich unverschlüsselte Verbindung zurück... Was ist jetzt daran genau besser als eine "unsichere Verschlüsselung"..?
(natürlich ist die Frage bezogen auf rein opportunistisches TLS und nicht "enforce", "dane", etc. Und ja! natürlich ist das jetzt genau die damals verpasste Gelegenheit SSLv3 endlich mit PoC in Rente zu schicken.. ;-))
Grüsse Christian
Am Montag, den 27.10.2014, 17:28 +0100 schrieb Christian Bricart:
Wenn ich jetzt einer Seite (<- also eben als Admin des Servers) SSLv3 ganz verbiete, dann werden sich doch beide Seiten auf *gar keine* Verschlüsselung mehr einigen (können) und fallen auf gänzlich unverschlüsselte Verbindung zurück... Was ist jetzt daran genau besser als eine "unsichere Verschlüsselung"..?
Richtig! In letzter Zeit beschleicht mich zunehmend das Gefühl dass die Sicherheitsapostel aus jeder Mücke einen Elefanten machen. Wozu? Um Aufmerksamkeit zu erhaschen? Um Linux schlecht zu reden?
Am 27.10.2014 um 19:00 schrieb Joachim Fahrner:
Am Montag, den 27.10.2014, 17:28 +0100 schrieb Christian Bricart:
Wenn ich jetzt einer Seite (<- also eben als Admin des Servers) SSLv3 ganz verbiete, dann werden sich doch beide Seiten auf *gar keine* Verschlüsselung mehr einigen (können) und fallen auf gänzlich unverschlüsselte Verbindung zurück... Was ist jetzt daran genau besser als eine "unsichere Verschlüsselung"..?
das muss am Ende jeder selbst entscheiden, Ziel ist am Ende wohl SSLv3 zu verbannen
Richtig! In letzter Zeit beschleicht mich zunehmend das Gefühl dass die Sicherheitsapostel aus jeder Mücke einen Elefanten machen. Wozu? Um Aufmerksamkeit zu erhaschen? Um Linux schlecht zu reden?
Na na, nicht uebertreiben, es ist schon allerhand passiert Snowden, Heartbleed, Shellshock, Poodle...da ist schon viel herausgekommen mit dem man zumindest in diesem Umfang nicht gerechnet hat.
Best Regards MfG Robert Schetterer
Mich würde mal interessieren wie denn so ein Angriff überhaupt aussehen soll. Meine eigene Verbindung knacken macht wenig Sinn. Jemand der einfach nur mitlauscht kann den Handshake auch nicht manipulieren, dazu müsste er schon "man-in-the-middle" werden, das kann er aber nur indem er das DNS manipuliert. Es müssten also 2 Sicherheitslücken zusammentreffen, das halte ich für unrealistisch.
Nein, er muss nicht unbedingt den DNS manipulieren. Wenn er zwischen Dir und dem Partner sitzt (Provider & Co), reicht auch ARP Spoofing. Ketzerisch: Wenn Du davon ausgehst, dass das nicht passieren kann, musst Du eigentlich gar nicht verschlüsseln ;)
In der Sache bin ich aber bei Euch. SSLv3 ist immer noch bei weitem besser als Plain.
participants (5)
-
Christian Bricart
-
Jan P. Kessler
-
Joachim Burbach
-
Joachim Fahrner
-
Robert Schetterer