s_client ciphersuite personalizado con el proxy inverso nginx falla

1. He compilado openssl 1.0.1u (sí, sé que es antiguo) con mi personalizado ciphersuite (ECDHE-RSA-MYCIPHER-CBC-SHA) con openssl para un proyecto de investigación; se ha compilado e instalado correctamente.

2. Cuando intento ejecutar el comando:

   "s_client -cipher'ECDHE-RSA-MYCIPHER-CBC-SHA' -connect localhost:443"

   y

   "s_client-cipher 'ECDHE-RSA-MYCIPHER-CBC-SHA' -connect localhost:465"

   realiza correctamente el handshake [wireshark capture shows]

3. Pero cuando intento ejecutar el comando

   "s_client -cipher'ECDHE-RSA-MYCIPHER-CBC-SHA' -connect localhost: 993"

   falla, fallo de apretón de manos [Wireshark capture shows]

4. En mi situación actual, estoy usando el servidor de correo electrónico de código abierto zimbra     que ejecuta nginx reverse proxy para los puertos de HTTPS [443],     SMTPS [465] e IMAPS [993] . El Ubuntu 14.04 lts openssl no se modifica, pero el binario openssl del servidor de correo electrónico se modifica.

5. El archivo nginx.log muestra que el error es

     

   SSL_do_handshake () falló (SSL: error: 1408A0C1: SSL   rutinas: SSL3_GET_CLIENT_HELLO: sin cifrado compartido) mientras se trata de un protocolo SSL

6. Lo que es extraño es que el proxy Nginx se está ejecutando para los 3 puertos mencionado anteriormente, pero el protocolo de enlace falla para el puerto 993 solo [también falla para 995 ]? Qué soy yo falta o haciendo mal?

Actualización 01 - Configuraciones / Conf archivo de NGINX

Archivo 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;
}

Archivo 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";
}

Actualización 02 - Sistema actualizado (binario de ubuntu14.04 lts x64 openssl)

Por lo tanto, sé que he reemplazado el binario openssl de 14.04 LTS x64 de Ubuntu con mi binario openssl (que contiene el cifrado personalizado). Cambié el nombre del binario openssl original en '/ usr / bin / openssl' a opensslORIG y luego 'mv' cifrado personalizado que contiene el binario openssl en '/ usr / bin / openssl' ... pero el mismo problema / error sigue siendo allí.

Actualización 03: el problema se resuelve

Actualicé el servidor de correo electrónico de código abierto (versión más reciente); También se actualizó el nginx y otros módulos. Luego apliqué los mismos pasos para la integración de cifrado personalizado en el openSSL. Ahora, todo funciona correctamente (cifrado personalizado en todos los puertos). Entonces, el problema fue del SERVIDOR DE CORREO ELECTRÓNICO no de nginx.