带有nginx反向代理的s_client自定义加密套件失败

Question

1. 我已经为一个研究项目用我的自定义openssl 1.0.1u (ECDHE-RSA-MYCIPHER-CBC-SHA)和openssl编译了ciphersuite (是的，我知道它是旧的)；它已经成功地编译和安装了。
2. 当我尝试运行命令："s_client -cipher'ECDHE-RSA-MYCIPHER-CBC-SHA' -connect localhost:443"和"s_client-cipher 'ECDHE-RSA-MYCIPHER-CBC-SHA' -connect localhost:465"时，它成功地执行了握手[wireshark capture shows]
3. 但是当我尝试运行命令"s_client -cipher'ECDHE-RSA-MYCIPHER-CBC-SHA' -connect localhost: 993"失败时，握手失败[Wireshark capture shows]
4. 在我的当前场景中，我使用的是开放源代码的zimbra服务器，它为HTTPS443、SMTPS465和IMAPS九九三的端口运行nginx反向代理。Ubuntu14.04LTS openssl没有被修改，但是电子邮件服务器的openssl二进制文件被修改了。
5. nginx.log文件显示SSL_do_handshake()失败的错误( SSL : error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no共享密码)
6. 奇怪的是，Nginx代理运行于上面提到的3个端口，但是只有同时它也失败了995端口993的握手失败？我错过了什么或者做错了什么？

更新01 - NGINX

的设置/Conf文件

文件01 - /opt/zimbra/conf/nginx/includes/nginx.conf.mail

mail
{
    # mail proxy connection timeout
    proxy_ctimeout              120000ms;

    # pass error messages from the backend server to the client
    # if true, the error messages are passed to the client verbatim, else
    # nginx logs the original error message in its log file and sends back
    # a generic error message to the client
    # 
    proxy_pass_error_message    on;

    # HTTP lookup handlers that will return the route information for a
    # pop3/imap login
    # 
    zm_auth_http;

    # Wether to use ssl to connect the upstream mail servers
    #
    proxy_ssl on;

    # IMAP/POP3 greeting messages
    # 
    imap_greeting            "";
    pop3_greeting            "";

    pop3_capabilities         "EXPIRE 31 USER" "TOP" "UIDL" "USER" "XOIP";
    imap_capabilities         "ACL" "BINARY" "CATENATE" "CHILDREN" "CONDSTORE" "ENABLE" "ESEARCH" "ESORT" "I18NLEVEL=1" "ID" "IDLE" "IMAP4rev1" "LIST-EXTENDED" "LIST-STATUS" "LITERAL+" "MULTIAPPEND" "NAMESPACE" "QRESYNC" "QUOTA" "RIGHTS=ektx" "SASL-IR" "SEARCHRES" "SORT" "THREAD=ORDEREDSUBJECT" "UIDPLUS" "UNSELECT" "WITHIN" "XLIST";

    # IMAP4 ID Extension support (RFC 2971)
    # Use the imap_id directive to specify the string that should be sent
    # back by the proxy server back to the client upon receipt of an 
    # IMAP ID command as described by RFC 2971
    # There MUST be an even number of strings specified against 
    # this directive, because RFC 2971 defines the server response to be 
    # a list of field-value pairs (refer Formal Syntax, RFC 2971 Section 4)
    # Each string in this list should be enclosed within double quotes
    # If not quoted, they will be automatically quoted by nginx, but the 
    # use of quotes allows the space character to be included within an 
    # ID field or a value
    # The odd numbered strings are treated as ID fields, with the following 
    # even-numbered string considered to be the ID value corresponding to 
    # the field name
    # If omitted, the response to the ID command will be nil, which
    # according to RFC 2971, is permissible in lieu of the field-value list
    # The imap_id directive may be overridden in a server block
    # 
    imap_id         "NAME" "Zimbra" ;

    # Default realm (kerberos)
    # For GSSAPI authentication, when the server's realm is the same as 
    # the default realm as defined in the default_realm variable in the 
    # [libdefaults] section of krb5.conf, then in this case, the SASL 
    # GSSAPI library strips off the realm portion from the authenticating
    # principal. Therefore, the default realm name must be specified here
    # so that NGINX can append it to the authenticating principal for GSSAPI
    # 
    default_realm           "";

    # Resolve IP address to SASL server name (kerberos)
    # For GSSAPI, in cases of multi-homed hosts, it may be that the proxy
    # server has multiple network interfaces, and we wish to reverse map 
    # the incoming interface IP address (via DNS) to a host name, which will
    # be used as the service principal
    # Set this to on if gssapi clients will connect to a proxy server using
    # different FQDNs. Otherwise, set it to off, and the fully qualified 
    # host name of the proxy (as returned by hostname), will be used as the
    # service principal
    # If not specified, this configuration defaults to off
    # 
    sasl_host_from_ip       off;

    # sasl_app_name
    # This is the application name which nginx will use when initializing
    # the SASL library using the call to sasl_server_init()
    # The SASL library is initialized once per process, the application name
    # provided here is used for where to find the default configuration file
    # If not specified, sasl_app_name defaults to "nginx"
    # 
    sasl_app_name           "nginx";

    # Login rate limiting directives
    # 

    # mail_login_ip_max 
    # 
    # Sets the maximum number of times that any user is allowed to log in from
    # a particular IP over POP or IMAP to this proxy server before the login is
    # rejected with an appropriate protocol specific bye response
    # This counter is cumulative for all users that appear to the proxy to be 
    # logging in from the same IP address
    # If multiple users appear to the proxy to be logging in from the same IP 
    # address (usual with NATing), then each of the different users' login will
    # contribute to increasing the hit counter for that IP address, and when the
    # counter eventually exceeds mail_login_ip_max, then the connections from 
    # that IP address will be throttled
    # Therefore, all users from the same IP will contribute to
    # (and be affected by) this counter
    # Logins using all protocols (POP3/POP3S/IMAP/IMAPS) will affect this 
    # counter, (the counter is aggregate for all protocols, *not* separate)
    # See notes accompanying the mail_login_ip_ttl for reasonable values for
    # this directive
    # If this value is set to 0, then no throttling will take place for any IP
    # 
    mail_login_ip_max               0;

    # mail_login_ip_ttl
    # 
    # Sets the time-to-live for the hit counter for IP login throttling
    # Used in conjunction with mail_login_ip_max, this defines the semantics
    # of the throttling for IP logins. Therfore, if this is set to 3600s, and
    # if mail_login_ip_max is set to 1000, then it means that NGINX should not
    # allow more than 1000 users to log in to the proxy from the same IP, 
    # within the time interval of an hour (=3600s)
    # The semantics for such a configuration would then be -
    # "allow maximum 1000 users per hour from any given IP address"
    #
    mail_login_ip_ttl               3600000ms;

    # Define a textual message that should be displayed to the user when
    # his/her connection is rejected based on IP overusage
    # This message will be encapsulated in the proper protocol specific 
    # response to the client ("* BYE" for IMAP, and "-ERR" for POP3)
    #
    mail_login_ip_rejectmsg         "Login rejected from this IP";

    # Similar semantics for Rate Limiting User Logins
    # Setting mail_login_user_max to 100 and mail_login_user_ttl to 3600s
    # implies "allow maximum 100 logins per hour for any user"
    # As with the ip counterparts, the user hit counter and timeout are 
    # cumulative for all protocols
    # Also, for a given user's login, both counters are checked in succession,
    # with the IP counter being checked first
    # A login may be rejected (throttled) because the IP is over-usage, or
    # because the login name itself is over-usage
    # A value of 0 indicates that no throttling will take place for any user
    # 
    mail_login_user_max             0;
    mail_login_user_ttl             3600000ms;
    mail_login_user_rejectmsg       "Login rejected for this user";

    # Issue POP3 XOIP before logging in to upstream (Audit purposes)
    # 
    proxy_issue_pop3_xoip   on;

    # Issue IMAP ID before logging in to upstream (Audit purposes)
    #
    proxy_issue_imap_id     on;

    # Supported SASL Authentication mechanisms
    # 
    # Use the pop3_auth and imap_auth to specify which SASL mechanisms are 
    # enabled for POP and IMAP respectively
    # These directives may be specified at mail{} level, or overridden at
    # server{} level
    # Even though an authentication mechanism may be listed against 
    # pop3_auth and/or imap_auth, it may or may not be available depending
    # on whether cleartext login is available (see description for starttls)
    # For example, if starttls is set to only, then SASL PLAIN is not 
    # available outside of TLS/SSL
    # SASL mechanisms may be specified all on one line (space separated)
    # against pop3_auth, or they may be specified on a separate line
    # Specifying the SASL mechanisms on a separate line has the advantage
    # that they can be enabled/disabled separately by zmmtaconfig using
    # different LDAP attributes
    # Currently, only PLAIN and GSSAPI mechanisms are supported
    # 

    imap_auth         plain;
    #imap_auth         gssapi;

    pop3_auth         plain;
    #pop3_auth         gssapi;

    # Specify whether to use literal strings while issuing the LOGIN command
    # to the upstream server. If set to on, then it means that NGINX will use
    # literal strings to log in to the upstream server, and so the upstream 
    # MUST support literal strings
    # If set to off, then NGINX uses quoted strings to log in to the upstream
    # server when using the LOGIN command
    # If not specified, imap_literalauth defaults to on
    # 
    imap_literalauth        on;

    # Auth Wait Interval
    # Specifies the time interval that NGINX will wait before rejecting an
    # authentication attempt to the upstream mail server with invalid credentials.
    # This value is not related to the wait time when Zimbra lookup handler replies
    # some login error, which is controled by the "Auth-Wait" header returned by the
    # lookup handler.
    # If not specified, this value defaults to 10 seconds.
    #
    zm_auth_wait               10000ms;

    # TLS configuration
    # 
    ssl_prefer_server_ciphers   on;
    ssl_certificate     /opt/zimbra/conf/nginx.crt;
    ssl_certificate_key /opt/zimbra/conf/nginx.key;

    # SSL Protocols & Ciphers configuration
    # Enabled protocols & Permitted ciphers. Ciphers are assigned in the formats supported by OpenSSL
    #
    ssl_protocols            TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers             ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;

    # SSL ECDH cipher curve configuration
    ssl_ecdh_curve          prime256v1;

     include /opt/zimbra/conf/nginx/includes/nginx.conf.mail.imap;
     include /opt/zimbra/conf/nginx/includes/nginx.conf.mail.imap.default;
     include /opt/zimbra/conf/nginx/includes/nginx.conf.mail.imaps;
     include /opt/zimbra/conf/nginx/includes/nginx.conf.mail.imaps.default;
     include /opt/zimbra/conf/nginx/includes/nginx.conf.mail.pop3;
     include /opt/zimbra/conf/nginx/includes/nginx.conf.mail.pop3.default;
     include /opt/zimbra/conf/nginx/includes/nginx.conf.mail.pop3s;
     include /opt/zimbra/conf/nginx/includes/nginx.conf.mail.pop3s.default;
}

文件02 - /opt/zimbra/conf/nginx/includes/nginx.conf.mail.imaps.default

# IMAPS proxy default configuration
# 
server
{
    #listen                  [::]:993;
    listen                993;
    #listen                [::]:993 ipv6only=on;
    protocol            imap;
    proxy               on;
    timeout             60;
    proxy_timeout       2100;
    ssl                 on;
    ssl_certificate     /opt/zimbra/conf/nginx.crt;
    ssl_certificate_key /opt/zimbra/conf/nginx.key;
    sasl_service_name   "imap";
}

更新02 -更新系统的(ubuntu14.04 lts x64 openssl二进制)

因此，我知道已经用我的openssl二进制(包含自定义密码)取代了Ubuntu的14.04LTS x64 openssl二进制。我将'/usr/bin/ openssl‘中的原始openssl二进制重新命名为opensslORIG，然后在'/usr/bin/openssl’中重新命名包含openssl二进制的“mv”自定义密码.但同样的问题/错误仍然存在。

更新03 -问题已重新解决

我更新了开源电子邮件服务器(更新版本)；它还更新了nginx和其他模块。然后，我应用了相同的步骤来集成openSSL中的自定义密码。现在，一切都正常工作(所有端口上都有自定义密码)。因此，问题在于电子邮件服务器，而不是nginx。

Answer 1

配置显示您已经将nginx配置为SSL端点，即它将终止与给定证书的SSL连接。nginx使用不包括您的密码的系统OpenSSL库。由于这是客户端提供的唯一密码，因此由于没有共享密码，连接将失败。