Postfix 2.6.6 с TLS - не может получать электронные письма от GMail (и нескольких других MTA), но другие в порядке, почему?
Мне просто нужно было посмотреть на сервер CentOS 6, работающий на Postfix 2.6.6, который мог отправлять электронные письма всем, но не мог получать их от GMail (и нескольких других MTA) из-за проблем с согласованием входящих TLS.
Соединение от .google.com
SMTP-сервер (то есть GMail) привел к этому:
Aug 23 19:34:29 server1 postfix/smtpd[7659]: connect from mail-lf1-f44.google.com[209.85.167.44]
Aug 23 19:34:29 server1 postfix/smtpd[7659]: setting up TLS connection from mail-lf1-f44.google.com[209.85.167.44]
Aug 23 19:34:29 server1 postfix/smtpd[7659]: SSL_accept error from mail-lf1-f44.google.com[209.85.167.44]: -1
Aug 23 19:34:29 server1 postfix/smtpd[7659]: warning: TLS library problem: 7659:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1387:
Aug 23 19:34:29 server1 postfix/smtpd[7659]: lost connection after STARTTLS from mail-lf1-f44.google.com[209.85.167.44]
Aug 23 19:34:29 server1 postfix/smtpd[7659]: disconnect from mail-lf1-f44.google.com[209.85.167.44]
Увеличение детализации регистрации TLS:
Aug 23 21:56:15 server1 postfix/smtpd[18103]: initializing the server-side TLS engine
Aug 23 21:56:15 server1 postfix/smtpd[18103]: connect from mail-lf1-f47.google.com[209.85.167.47]
Aug 23 21:56:15 server1 postfix/smtpd[18103]: setting up TLS connection from mail-lf1-f47.google.com[209.85.167.47]
Aug 23 21:56:15 server1 postfix/smtpd[18103]: mail-lf1-f47.google.com[209.85.167.47]: TLS cipher list "ALL:+RC4:@STRENGTH:!aNULL:!LOW:!EXP:!MEDIUM:!ADH:!AECDH:!MD5:!DSS:!ECDSA:!CAMELLIA128:!3DES:!CAMELLIA256:!RSA+AES:!eNULL"
Aug 23 21:56:15 server1 postfix/smtpd[18103]: SSL_accept:before/accept initialization
Aug 23 21:56:15 server1 postfix/smtpd[18103]: SSL3 alert write:fatal:handshake failure
Aug 23 21:56:15 server1 postfix/smtpd[18103]: SSL_accept:error in SSLv3 read client hello C
Aug 23 21:56:15 server1 postfix/smtpd[18103]: SSL_accept error from mail-lf1-f47.google.com[209.85.167.47]: -1
Aug 23 21:56:15 server1 postfix/smtpd[18103]: warning: TLS library problem: 18103:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1387:
Aug 23 21:56:15 server1 postfix/smtpd[18103]: lost connection after STARTTLS from mail-lf1-f47.google.com[209.85.167.47]
Aug 23 21:56:15 server1 postfix/smtpd[18103]: disconnect from mail-lf1-f47.google.com[209.85.167.47]
Нет общего шифра?!
TLS уже был включен с (хотя и самоподписанным) сертификатом сервера; клиенты успешно подключались для отправки и получения почты через IMAP / POP с SASL.
Я читал об общих причинах 1408A0C1
ошибка postfix, но, похоже, ни одна из них не относится к этому сценарию Некоторые из проверок, которые я проводил, дали результаты, которые, казалось, противоречили тому, что я ожидал;
postconf -d | grep cipherlist
имел этот довольно короткий список исключений:
tls_export_cipherlist = ALL:+RC4:@STRENGTH
tls_high_cipherlist = ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
tls_low_cipherlist = ALL:!EXPORT:+RC4:@STRENGTH
tls_medium_cipherlist = ALL:!EXPORT:!LOW:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL
и протоколы TLS были довольно снисходительными:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
Так почему же он не смог договориться о шифре?
Я впервые приступил к обновлению OpenSSL (который был OpenSSL 1.0.1e-fips 11 Feb 2013
, последние доступны через yum
); Я сделал, как указано в этой статье, и в результате коробка работает OpenSSL 1.0.2p 14 Aug 2018
,
Но все же проблема с приемом GMail продолжалась...
Я оставил их как есть, чтобы дать всем возможным вариантам TLS шанс на успех, и изучил шифры более подробно.
Отключив все исключения шифров, я отправил тестовое электронное письмо из своего gmail, и неудивительно, что оно пришло:
Aug 23 23:39:52 server1 postfix/smtpd[6036]: connect from mail-lj1-f171.google.com[209.85.208.171]
Aug 23 23:39:52 server1 postfix/smtpd[6036]: setting up TLS connection from mail-lj1-f171.google.com[209.85.208.171]
Aug 23 23:39:52 server1 postfix/smtpd[6036]: mail-lj1-f171.google.com[209.85.208.171]: TLS cipher list "ALL:+RC4:@STRENGTH"
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:before/accept initialization
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 read client hello B
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write server hello A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write certificate A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write server done A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 flush data
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 read client key exchange A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 read finished A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write session ticket A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write change cipher spec A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write finished A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 flush data
Aug 23 23:39:52 server1 postfix/smtpd[6036]: Anonymous TLS connection established from mail-lj1-f171.google.com[209.85.208.171]: TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
Aug 23 23:39:52 server1 postfix/smtpd[6036]: 66BB15DC6: client=mail-lj1-f171.google.com[209.85.208.171]
Aug 23 23:39:52 server1 postfix/cleanup[6424]: 66BB15DC6: message-id=<CAK9Gk9r+6gt7g_U987A0XaGdKJGY=80n0rK595mqrmfGaL5LKQ@mail.gmail.com>
Aug 23 23:39:52 server1 opendkim[6890]: 66BB15DC6: mail-lj1-f171.google.com [209.85.208.171] not internal
Aug 23 23:39:52 server1 opendkim[6890]: 66BB15DC6: not authenticated
Aug 23 23:39:52 server1 opendkim[6890]: 66BB15DC6: DKIM verification successful
Aug 23 23:39:52 server1 postfix/qmgr[6032]: 66BB15DC6: from=<gmailaddress>, size=3988, nrcpt=1 (queue active)
Aug 23 23:39:52 server1 postfix/smtpd[6036]: disconnect from mail-lj1-f171.google.com[209.85.208.171]
Aug 23 23:39:52 server1 postfix/pipe[6425]: 66BB15DC6: to=<myinbox>, relay=dovecot, delay=0.48, delays=0.29/0.01/0/0.18, dsn=2.0.0, status=sent (delivered via dovecot service)
Так что если GMail договорился AES128-GCM-SHA256
через TLSv1.2 - почему он не работал раньше? В частности, поскольку их шифр-лист, кажется, содержит любые возможные совпадения, с RC4 в конце, упорядоченные в порядке силы?
Чтобы проверить, я взял специальный список шифров, добавил значения глубины хэша AES128 (курсив) - методы ECDHE и DHE - и явно объявил его в postfix, который работал:
tls_high_cipherlist = ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES25E-AES256-G-GC-38-G-38 SHA256: DHE-DSS-AES128-GCM-SHA256: EDH + КАМЕЛИЯ: EDH + ARSA: EECDH + ARSA+ AESGCM: EECDH + ARSA+ SHA384: EECDH + ARSA+ SHA256: EECDH: + CAMELLIA256: + AES128: + SSLv3: aNULL: eNULL: LOW: 3DES: MD5: EXP: PSK: DSS: RC4: SEED: ECDSA: CAMELLIA256-ША: AES256-SHA: CAMELLIA128-ША: AES128-SHA
Я не хотел постоянно обновлять рецепты шифровальщиков, поэтому прокомментировал tls_high_cipherlist
декларация.
Затем я сделал несколько вещей.
В постфиксе master.cf
я добавил -o smtp_tls_mandatory_protocols=TLSv1
в разделе smtpd, как рекомендуется.
Я хотел улучшить протоколы TLS, используя объявления из https://blog.kruyt.org/postfix-and-tls-encryption/, которые явно исключают TLSv1.2 и TLSv1.1 перед исключением старых. Однако с постфиксом 2.6.6 это не работает; Я видел это в журнале вскоре после перезагрузки / перезапуска:
warning: Invalid TLS protocol list "TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3": disabling TLS support
Это произошло, если я смешал правила исключения! С правилами включения, поэтому я вернулся к явному формату исключения:
smtpd_tls_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_ciphers = high
smtpd_tls_mandatory_ciphers = high
и это было принято постфиксом.
Я установил оппортунистический TLS с
smtp_tls_security_level = may
smtpd_tls_security_level = may
Я заметил, что даже после решения проблемы доставки GMail, несколько других MTA по-прежнему не работали:
server1 postfix/smtpd[28167]: connect from mta3.email.secretescapes.com[198.245.84.110]
server1 postfix/smtpd[28167]: setting up TLS connection from mta3.email.secretescapes.com[198.245.84.110]
server1 postfix/smtpd[28167]: mta3.email.secretescapes.com[198.245.84.110]: TLS cipher list "ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!MD5:!DES:!ADH:!RC4:!PSD:!SRP:!3DES:!eNULL:!aNULL"
server1 postfix/smtpd[28167]: SSL_accept:before/accept initialization
server1 postfix/smtpd[28167]: SSL_accept:error in SSLv2/v3 read client hello A
server1 postfix/smtpd[28167]: SSL_accept error from mta3.email.secretescapes.com[198.245.84.110]: -1
server1 postfix/smtpd[28167]: warning: TLS library problem: 28167:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
server1 postfix/smtpd[28167]: lost connection after STARTTLS from mta3.email.secretescapes.com[198.245.84.110]
server1 postfix/smtpd[28167]: disconnect from mta3.email.secretescapes.com[198.245.84.110]
-
server1 postfix/smtpd[1451]: initializing the server-side TLS engine
server1 postfix/smtpd[1451]: connect from mta.email.bbc.com[198.245.84.99]
server1 postfix/smtpd[1451]: setting up TLS connection from mta.email.bbc.com[198.245.84.99]
server1 postfix/smtpd[1451]: mta.email.bbc.com[198.245.84.99]: TLS cipher list "ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!MD5:!aDSS:!kECDH:!kDH:!SEED:!IDEA:!DES:!ADH:!RC2:!RC4:!RC5:!PSD:!SRP:!3DES:!eNULL:!aNULL"
server1 postfix/smtpd[1451]: SSL_accept:before/accept initialization
server1 postfix/smtpd[1451]: SSL_accept:error in SSLv2/v3 read client hello A
server1 postfix/smtpd[1451]: SSL_accept error from mta.email.bbc.com[198.245.84.99]: -1
server1 postfix/smtpd[1451]: warning: TLS library problem: 1451:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
server1 postfix/smtpd[1451]: lost connection after STARTTLS from mta.email.bbc.com[198.245.84.99]
server1 postfix/smtpd[1451]: disconnect from mta.email.bbc.com[198.245.84.99]
server1 postfix/smtpd[1451]: connect from unknown[107.174.30.57]
server1 postfix/smtpd[1451]: 4F6D0629C: client=unknown[107.174.30.57]
Затем я попробовал несколько перестановок в списке tls_high_cipherlist, прежде чем использовать список рекомендованных bettercrypto.org:
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
Сервер был протестирован с различными тестерами SSL, включая CheckTLS (результат 100%), Luxsci (результат A+), тестер SSL htbridge (хороший класс) и SSL-Tools.
Я знаю, что вы можете сопоставить политику исходящих соединений, но я ищу эквивалент, чтобы я мог выборочно отключить любые исключения для определенных MTA (как я их нахожу) и определить, какой шифр они согласовывают, а затем настроить список шифров, который я представляю,
Я не вижу никаких явных недостатков в текущей конфигурации постфикса TLS. Я в недоумении, почему некоторые MTA не могут договориться о шифре TLS, когда другие справляются нормально. Даже привередливый, GMail, теперь в порядке.
Есть идеи?:-)
Я отметил этот вопрос SE о том, почему Google предпочитает шифр, который он делает, что сделано для интересного чтения.
Благодаря этой ветке форума пользователей Postfix, я нашел полезный рецепт, чтобы быстро увидеть, сколько соединений TLS было успешно установлено во всех доступных шифрах:
egrep "TLS connection established from.*with cipher" /var/log/maillog* | awk '{printf("%s %s %s %s\n", $12, $13, $14, $15)}' | sort | uniq -c | sort -
1 ответ
В конечном счете, эта проблема, по-видимому, связана с тем, что некоторые отправители все еще могут согласовывать SSLv3. Это плохо, но не получать электронные письма тоже не здорово.
Это так просто, как на самом деле. Я не доволен этим, но если отправляющие MTA отказываются пересматривать TLS и просто вечно повторяют попытку с SSLv3, мы пока ничего не можем сделать.
Итак, в настоящее время я прибегаю к разрешению шифрования входящих писем с помощью SSLv3, но требую, чтобы все клиенты на сервере все еще должны были проходить аутентификацию через TLS.
Я достиг этого, ослабив протоколирующие отрицатели в main.cf
:
smtpd_tls_mandatory_protocols = !TLSv1, !SSLv2
smtpd_tls_protocols = !TLSv1, !SSLv2
NB, что smtp_tls_
Определения относятся к почте, отправляемой с этого сервера, поэтому относитесь к клиентским соединениям, чтобы вы могли сделать их настолько строгими, насколько захотите (если вы готовы объяснить всем, как настроить свои почтовые клиенты):
smtp_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = !TLSv1, !SSLv2, !SSLv3
Если отправляющие MTA не могут согласовать TLS, ожидая SSLv3, это то, что вы обычно видите в почтовом журнале:
warning: TLS library problem: 364:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
Если вы наберете уровень ведения журнала, вы увидите сбой согласования TLS с большим количеством сообщений, таких как
postfix/smtpd[26234]: SSL_accept:before/accept initialization
postfix/smtpd[26234]: SSL_accept:error in SSLv2/v3 read client hello A
postfix/smtpd[26234]: SSL_accept error from 201-62-89-201.life.com.br[201.62.89.201]: -1
Я периодически тестировал запрещающие соединения SSLv3 (неизбежно повторные попытки MTA в течение многих дней), поэтому вы можете позволить нескольким сбоям накапливаться в журналах, а затем анализировать их.
Этот скрипт bash помогает мне проанализировать, какие серверы пытаются использовать SSLv3:
#!/bin/sh
egrep "SSL_accept error" /var/log/maillog | awk '{printf("%s %s %s\n", $9, $10, $11)}' | sort | uniq -c | sort -`
И этот вариант показывает согласованные шифры - поэтому после повторного включения SSLv3 вы можете оставить его на некоторое время, а затем подтвердить, что адаптеры MTA используют SSLv3:
#!/bin/sh
egrep "TLS connection established from.*with cipher" /var/log/maillog | awk '{printf("%s %s %s %s\n", $12, $13, $14, $15)}' | sort | uniq -c | sort -
Я еще не нашел лучшего ответа; Я хотел бы использовать более нюансированный подход и иметь возможность выборочно разрешать SSLv3 для определенных адаптеров MTA в зависимости от того, не удаются ли их попытки подключения с определенными ошибками в maillog
, Все комментарии / предложения приветствуются.