insecure example error curlopt_ssl_verifypeer cacert php ssl curl

php - example - curlopt_ssl_verifypeer



Si CURLOPT_SSL_VERIFYPEER es falso, ¿la transferencia de datos ya no es segura? (3)

Recientemente me encontré con un problema al publicar datos en un servidor cuyo certificado SSL se actualizó. Investigué un poco y descubrí que cuando CURLOPT_SSL_VERIFYPEER se configura como falso, la fecha de publicación se procesa correctamente. ¿Alguien puede explicar la relación entre CURLOPT_SSL_VERIFYPEER y _VERIFYHOST? Además, si configuro VERIFYPEER en falso, ¿ya no estoy transmitiendo los datos a través de una conexión segura?

Muchas gracias por cualquier ayuda que alguien pueda dar.


La conexión seguirá siendo SSL cifrada. Simplemente no lo hará en un enlace que utiliza certificados validados como correctos. Cualquiera puede crearse un certificado SSL que hará un cifrado perfectamente aceptable en cualquier nivel compatible con su navegador y el servidor web.

Sin embargo, lo que obtendrá son muchas quejas sobre no poder verificar la autenticidad del certificado. Esto es para evitar que Joe M. Alicious se cree un certificado que dice ser "microsoft.com" y configura su propio host Windows Update. El certificado dirá que es microsoft.com, pero no se puede autenticar como microsoft.com, ya que Verisign (o quien sea) no emitió ese certificado y puso su propio sello de autenticidad (firmando el certificado) en él.

_VERIFYHOST está ahí para verificar que el nombre de host de la URL a la que se está conectando (por ejemplo, "microsoft.com") figure en la lista dentro del certificado SSL. Con esta opción configurada como falsa, las discrepancias entre url / cert hostname se ignorarán (por ejemplo, tienes un cuadro de desarrollo en testbox.develhost.com, pero estás usando el certificado válido de ''ejemplo.com'' de tu cliente).

_VERIFYPEER deshabilita la validación de todo el certificado. Esto permite que los certificados autofirmados funcionen. De lo contrario, la biblioteca SSL descartará diciendo que el emisor del certificado no es válido.

Pero independientemente de cualquiera de los ajustes, si fuerza a través de una conexión, SERÁ encriptado ssl.


Me gustaría aclarar la relación entre _VERIFYHOST y _VERIFYPEER de mis pruebas.

_VERIFYHOST verifique el nombre común (CN) como se indica en el manual que depende de la opción 1 o 2. Esta verificación solo verifica y genera error en el caso del mensaje. La verificación en sí no tiene ningún efecto en la conexión, incluso se produce un error de verificación. Es resultado utilizado por _VERIFYPEER para reducir o continuar la conexión.

_VERIFYPEER (1) verifica 2 cosas. Primero, verifica el certificado con CAINFO. si CAINFO especifica en la opción curl, entonces verifica con ese valor; de lo contrario, verifica con el valor especificado en php.ini. En segundo lugar, verifica el resultado de _VERIFYHOST (conjunto de casos _VERIFYHOST en 1 o 2). Si la verificación pasa ambas condiciones, la conexión continuará. De lo contrario, la conexión se reducirá.


Si deshabilita CURLOPT_SSL_VERIFYPEER, no se realiza ninguna verificación del certificado (y se ignora el valor de CURLOPT_SSL_VERIFYHOST). Como resultado, esto te deja inseguro contra los ataques de hombre en el medio. Esto significa que ya no está transmitiendo los datos a través de una conexión segura.

Sí, los datos están encriptados, pero aún no son seguros. Sabes que le estás enviando a alguien , pero no tienes idea de quién; podrías estar enviándolo al archienemigo del usuario (cifrándolo cuidadosamente para que nadie más que el atacante pueda leer los datos). Esto es malo. Toda la encriptación del mundo no es muy buena si la encriptas usando la clave pública del atacante.

En pocas palabras: no desactive CURLOPT_SSL_VERIFYPEER. Te deja inseguro.

Consulte las consecuencias de seguridad al deshabilitar CURLOPT_SSL_VERIFYHOST (libcurl / openssl) para obtener más información sobre lo que debe hacer para usar el soporte SSL de cURL de forma segura.