Мне просто пришлось взглянуть на сервер 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 - и явно объявил его в постфиксе, который сработал:
tls_high_cipherlist =ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES256-GCM-SHA384: DHE-RSA-GCM-AES DHE-DSS-AES128-GCM-SHA256: EDH + CAMELLIA: EDH + aRSA: EECDH + aRSA + AESGCM: EECDH + aRSA + SHA384: EECDH + aRSA + SHA256: EECDH: + CAMELLIA256: + AES256: + CAMELLIA128: + AES128: + SSLv3!: ANULL! ! LOW:! 3DES:! MD5:! EXP:! PSK:! DSS:! RC4:! SEED:! ECDSA: CAMELLIA256-SHA: AES256-SHA: CAMELLIA128-SHA: 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, прежде чем исключить более старые. Однако с postfix 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
и это было принято postfix.
Я установил оппортунистический 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-инструменты.
Я знаю, что вы можете сопоставить исходящие соединения с помощью политик, но я ищу эквивалент, чтобы я мог выборочно отключить любые исключения для определенных MTA (как я их нахожу) и выяснить, какой шифр они согласовывают, а затем скорректировать список шифров, который я представляю .
Я не вижу каких-либо очевидных недостатков в текущей конфигурации postfix 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 -
В конечном счете, эта проблема, похоже, связана с тем, что некоторые отправители все еще могут согласовывать только 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. Все комментарии / предложения приветствуются.