Tener extraño error de conexión con openssl SSLConnect con mi SSLCLIENT.

Estamos tratando de establecer una conexión ssl con el servidor. Nos damos cuenta de que SSL_CONNECT está fallando con el código de error «SSL_ERROR_SYSCALL».

Para más profundidad tratamos de impresión strerror(errno) que devolver «scuccess» «0».

Sin embargo, yo sólo estoy tratando de entender lo que podría ser la causa exacta de este problema

Añadido fragmento de código para SSL init y conectar::

solicitud de orientación:

int setupSSL(int server){ 
int retVal = 0; 
int errorStatus = 0; 
int retryMaxCount = 6; 
static int sslInitContext=0; 
if(sslInitContext == 0) 
{ 
if(InitCTX() != 0) 
{ 
return -1; 
} 
else 
{ 
sslInitContext=1; 
} 
} 
retVal = SSL_set_fd(ssl, server);    /* attach the socket descriptor */ 
if ( retVal != 1 ) 
{   
/* perform the connection */ 
sprintf(debugBuf,"SYSTEM:SOCKET:Could not set ssl FD: %d %s\n",retVal,strerror(retVal)); 
debug_log(debugBuf,TRACE_LOG); 
CloseSocket(server); 
return -1; 
} 
do 
{ 
retVal = SSL_connect(ssl); 
errorStatus = SSL_get_error (ssl, retVal); 
switch (errorStatus) 
{ 
case SSL_ERROR_NONE: 
retVal = 0;                         
break; 
case SSL_ERROR_WANT_READ: 
case SSL_ERROR_WANT_WRITE: 
retVal = 1; 
break; 
default: 
sprintf(debugBuf,"SYSTEM:SSL_SOCKET:Could not build SSL session(Other error): %d %s\n",errorStatus,strerror(errno)); 
debug_log(debugBuf,TRACE_LOG); 
CloseSocket(server); 
return -1;                             
} 
sprintf(debugBuf,"SYSTEM:SSL_SOCKET:SSL CONNECTION Under PROGRESS: %d with remaining retries %d\n",errorStatus,retryMaxCount); 
debug_log(debugBuf,TRACE_LOG); 
if (retVal) 
{ 
struct timeval tv;         
fd_set sockReadSet; 
tv.tv_sec = 2; 
tv.tv_usec = 0;          
FD_ZERO(&sockReadSet); 
FD_CLR(server, &sockReadSet); 
FD_SET(server,&sockReadSet); 
retVal = select(server+1, &sockReadSet, NULL, NULL, &tv); 
if (retVal >= 1) 
{ 
retVal = 1; 
} 
else 
{ 
retVal = -1; 
} 
retryMaxCount--; 
if (retryMaxCount <= 0 ) 
break;         
} 
}while(!SSL_is_init_finished (ssl) && retVal == 1); 
cert = SSL_get_peer_certificate(ssl); 
if(cert == NULL) 
{ 
debug_log("SYSTEM:SSL_SOCKET:Unable to retrive server certificate\n",TRACE_LOG); 
CloseSocket(server); 
return -1; 
} 
if(SSL_get_verify_result(ssl)!=X509_V_OK) 
{ 
debug_log("SYSTEM:SSL_SOCKET:Certificate doesn't verify\n",TRACE_LOG); 
CloseSocket(server); 
return -1; 
} 
/*X509_NAME_get_text_by_NID (X509_get_subject_name (cert),  NID_commonName,  peer_CN, 256); 
if(strcasecmp(peer_CN, cnName)){ 
debug_log("SYSTEM:SSL_SOCKET:Common name doesn't match host name\n",TRACE_LOG); 
return -1; 
}*/ 
return 0; 
//LoadCertificates(ctx, CertFile, KeyFile); 
} 
int InitCTX(void) 
{ 
int errorStatus = 0; 
static int isSslInit = 1; 
if(isSslInit) 
{ 
OpenSSL_add_all_algorithms();/* Load cryptos, et.al. */ 
SSL_load_error_strings();/* Bring in and register error messages */ 
if(SSL_library_init() < 0) 
{ 
debug_log("SYSTEM:SSL_SOCKET:Could not initialize the OpenSSL library\n",TRACE_LOG); 
return -1; 
} 
method = TLSv1_client_method(); 
isSslInit=0; 
} 
ctx = SSL_CTX_new(method);/* Create new context */ 
if ( ctx == NULL) 
{ 
debug_log("SYSTEM:SSL_SOCKET:Unable to create a new SSL context structure\n",TRACE_LOG); 
//sprintf(debugBuf,"SYSTEM:SSL_SOCKET:Unable to create a new SSL context structure: %d %s\n",errorStatus,strerror(retVal)); 
//debug_log(debugBuf,TRACE_LOG); 
return -1; 
} 
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2); 
if (SSL_CTX_use_certificate_file(ctx,CertFile, SSL_FILETYPE_PEM) <= 0) 
{ 
SSL_CTX_free(ctx); 
ctx = NULL; 
debug_log("SYSTEM:SSL_SOCKET:Error setting the certificate file.\n",TRACE_LOG); 
return -1; 
} 
/* Set the list of trusted CAs based on the file and/or directory provided*/ 
if(SSL_CTX_load_verify_locations(ctx,CertFile,NULL)<1) 
{ 
SSL_CTX_free(ctx); 
ctx = NULL; 
debug_log("SYSTEM:SSL_SOCKET:Error setting verify location.\n",TRACE_LOG); 
return -1; 
} 
SSL_CTX_set_verify(ctx,SSL_VERIFY_PEER,NULL); 
SSL_CTX_set_timeout (ctx, 300); 
ssl = SSL_new(ctx);      /* create new SSL connection state */ 
if(ssl == NULL) 
{ 
sprintf(debugBuf,"SYSTEM:SOCKET:SSL:Unable to create SSL_new context\n"); 
debug_log(debugBuf,DEBUG_LOG); 
if(ctx != NULL) 
SSL_CTX_free(ctx); 
return -1; 
} 
return 0; 
} 

También es recomendado para mantener SSL contexto para las nuevas conexiones o debemos destruir y volver a init ssl contexto??

Añadido PCAP info:

https://drive.google.com/file/d/0B60pejPe6yiSUk1MMmI1cERMaFU/view?usp=sharing

cliente: 198.168.51.10 (198.168.51.10), Servidor: 192.168.96.7 (192.168.96.7)

InformationsquelleAutor Ragav | 2015-07-02

1 Comentario

  1. 6

    Estamos tratando de establecer una conexión ssl con el servidor. Nos damos cuenta de que SSL_CONNECT está fallando con el código de error «SSL_ERROR_SYSCALL».

    Generalmente este es el caso si el otro lado es simplemente cerrar la conexión. Microsoft SChannel hace en muchos especie de apretón de manos de problemas en lugar de enviar un TLS de alerta de nuevo. Esto puede suceder por problemas como el protocolo no válido o no comunes, sistemas de cifrado, etc. También puede ocurrir si intenta hacer un enlace TLS con un servidor que no habla TLS a todos en este puerto. Buscar en los registros en el lado del servidor para los problemas.

    Por supuesto, también puede ser algo diferente, así que usted puede revisar el errno para obtener más detalles sobre el problema. También puede ayudar si usted hace una captura de paquetes para comprobar lo que está pasando en el cable. Mejor sería hacer esta captura en el cliente y en el servidor para asegurarse de que no middlebox como un firewall es la manipulación con la conexión.

    También es recomendado para mantener SSL contexto para las nuevas conexiones o debemos destruir y volver a init ssl contexto??

    El contexto es una colección de opciones de configuración, certificados, etc y no es afectado por la conexión SSL en sí. Se puede reutilizar para otra conexión después o al mismo tiempo.

    EDICIÓN, después de la captura de paquetes se adjunta:

    Hay varias conexión TCP en el archivo entre el cliente y el servidor y sólo dentro de una sola, el cliente intenta iniciar un apretón de manos, es decir, el ClientHello puede ser visto. El servidor cierra la conexión. Un par de cosas interesantes:

    • Enlace TCP toma mucho tiempo. El servidor responde solo después de 1.6 segundos después de recibir el SYN con el SYN+ACK. También el otro responde tomar 800ms que es muy largo, ya que ambas direcciones en una red privada (192.168.0.0). Esto podría indicar una conexión lenta o VPN (esto es acerca de la latencia de una conexión vía satélite), algunos middlebox (firewall) reduciendo todo abajo o en un servidor lento.
    • Cliente envía TLS 1.0 solicitud. Podría ser que el servidor va a hacer sólo TLS 1.1+. Algunos TLS pilas (ver arriba) simplemente cerrar la conexión en ese tipo de errores, en lugar de enviar compatible protocolo de alerta. Pero dado que el servidor es lento también podría ser viejo y solo admite SSL 3.0 o inferior.
    • Cliente no hace uso de la extensión SNI. Más y más servidores necesitan esto y simplemente puede cerrar si ellos no tienen la extensión.

    Es difícil saber lo que realmente está pasando, sin tener acceso al servidor. Te recomiendo buscar los mensajes de error en el lado del servidor y el uso de herramientas como SSLyze de comprobar los requisitos del servidor, es decir, apoyado TLS versiones, cifras etc.

    Aparte de que el cliente ofrece peligrosamente débil sistemas de cifrado, como varios de EXPORTACIÓN de sistemas de cifrado. Esto se ve para mí como los valores predeterminados de un considerablemente antigua versión de OpenSSL.

    • Es recomendado para agregar » SSL_set_mode(*ssl, SSL_MODE_AUTO_RETRY);» … También por ver a otro problema en mi conectarse témpano..Ami falta algo…
    • También he capturado algunos paquetes de wireshark para este error y aviso de que el interruptor se cierre la conexión. desde entonces, el fracaso es muy aleatorio & continua cuando se produce algún problema en la fijación de este. Sin embargo, hay algo en específico que debo buscar en con wiresharkdata??
    • SSL_MODE_AUTO_RETRY sólo afecta el bloqueo de transportes y parece que estás tratando de hacer no-bloqueo. También, tratar SSL_WANT_WRITE la misma como SSL_WANT_READ, es decir, esperar que el encaje puede legible. Este es, por supuesto, mal. En la captura de paquetes se debe tener una mirada en la que el punto en el TLS handshake se rompe, lo que puede indicar si el servidor tiene un problema con el protocolo o sistemas de cifrado o si hay un certificado de cliente que falta o algo así.
    • Sí faltó agregar «if (ret = WANTREAD) { seleccionar(fd+1, fd, NULL, NULL, &tv); } else { seleccionar(fd+1, NULL, fd, NULL, &tv); }» debe resolver la punta de la cuestión..gracias También por pinting el error..
    • Añadido cable de datos para la conexión. Solicitud de sus sugerencias
    • ver editar.
    • Gracias por dar una visión profunda sobre el tema. Estamos tratando de llegar a servidor de la gente sobre esto. Sin embargo, existen ciertas dudas todavía presist. 1. Con el mismo servidor somtimes sslconnect trabaja en el mismo día durante un par de horas se ve muy aleatorio. 2. estamos por defecto utilizando OPENSSL 0.9.8 de la biblioteca de nuestro final (¿será esto un problema) ..3. Respecto SNI : Se debe establecer SNI o es que los servidores de llamada
    • 4. «el servidor es lento también podría ser viejo» : Es que me estoy perdiendo cualquier opción de reserva disponible como (TLSV1 falla se debe tratar de SSLV3) ??
    • SNI se debe establecer en el lado del cliente, pero sólo es necesaria si hay varios nombres de host con diferentes certificados detrás de la misma dirección IP. Y si el retroceso a SSLv3 es posible depende de la configuración del servidor. Y si a veces funciona y a veces no sólo podría ser un problema de conexión o algunos middlebox en el medio. Como dije: no, es una inusual alta latencia que puede ser causado por algo lento y tal vez interceptar en el medio.
    • Los consejos que se apuntaba a la dirección fueron excelentes. Pero, aún así el problema no se ha resuelto todavía. Cuando contactamos con theh equipo de la red acerca de la latencia casi a la conclusión de que el problema no es de allí final. Dicen que la red VSAT y es lenta la conexión. Para la conectividad aleatoria que nos piden para comprobar el tema de nuestro fin. Ellos no fueron capaces de responder con ninguna razón específica para el cierre de la conexión.
    • Para una mayor depuración yo estaba tratando de ejecutar SSLYZE herramienta. Parece que la herramienta requiere SSL certificado y la clave Privada. Pero En nuestro caso no es pocess cualquier clave privada de la nuestra. Sólo tenemos certicado. Incluso para SSL_CONNECT la carga de la clave privada es opcional. ¿Cómo puedo manejar esto.
    • SSLYZE no requiere ninguna clave privada a menos que usted está utilizando certificados de cliente en el que caso de que necesite la clave privada en su aplicación demasiado. Tal vez usted debe buscar de nuevo en la documentación de la herramienta.

Dejar respuesta

Please enter your comment!
Please enter your name here