¿SSLv3 usa SHA256 como algoritmo de hash?

TLS 1.0 (sucesor de SSLv3) se publicó en enero de 1999 ( RFC 2246 ). SHA-2 se publicó por primera vez en FIPS 180-2 en 2001. Por lo tanto, no hay forma de que una implementación siguiendo solo las especificaciones de SSL3 pudiera ser compatible con SHA-2.

La versión utilizada por SSLv3 habría sido SHA-1, al igual que TLS 1.0:

SHA
   The Secure Hash Algorithm is defined in FIPS PUB 180-1. It
   produces a 20-byte output. Note that all references to SHA
   actually use the modified SHA-1 algorithm. [SHA]

rfc2246 página 59

Aunque la respuesta de @ Angel es correcta en su mayoría, puede haber detalles ...

En la familia de protocolos SSL (una familia que incluye SSL 3.0 , así como TLS 1.0 , TLS 1.1 y TLS 1.2 ), hay aproximadamente cuatro lugares donde se puede usar una función hash:

• En el "PRF", que es la función utilizada para la derivación de clave durante el protocolo de enlace y otros usos similares. En SSL 3.0, TLS 1.0 y TLS 1.1, el PRF utiliza MD5 y SHA-1 exclusivamente (el PRF de SSL 3.0 es distinto del utilizado en TLS 1.0 y 1.1). En TLS 1.2, el PRF utiliza una función hash que depende del conjunto de cifrado, generalmente SHA-256.

• Para la protección de integridad de los registros, normalmente como parte de HMAC (en variantes TLS) o de tipo HMAC (en SSL 3.0). Esto está definido por la suite de cifrado. Los conjuntos de cifrado son, por definición, abiertos: los nuevos conjuntos de cifrado se pueden definir mucho después de que el protocolo base se haya estandarizado. Por ejemplo, RFC 5487 define algunos conjuntos de cifrado en un modelo de "clave precompartida", y que utilizan HMAC / SHA- 256 para la integridad; que RFC establece explícitamente que algunas de estas suites (las que se basan en AES en modo CBC para el cifrado) son aplicables a versiones anteriores de TLS (1.0 y 1.1). Técnicamente, estas suites de cifrado también se aplican a SSL 3.0.

  Tenga en cuenta que SSL 3.0 se define solo en un RFC "histórico", no en un "estándar", lo que hace que sea un poco difícil hablar de lo que se puede y no se puede hacer en SSL 3.0.

• Como parte de las firmas en los certificados. Las implementaciones implementadas de SSL 3.0 (por ejemplo, la de Windows / Internet Explorer) procesarán alegremente los certificados firmados con RSA + SHA-256, incluso como parte de un protocolo de enlace que se desarrolla a lo largo de la versión del protocolo SSL 3.0.

• En extensiones. SSL 3.0 correctamente dicho (con las advertencias explicadas anteriormente) no define ninguna extensión, pero deja espacio para ellos. Precisamente, RFC 6101 dice en la sección 5.6.1.2:

  Forward compatibility note: In the interests of forward
  compatibility, it is permitted for a client hello message to include
  extra data after the compression methods.  This data must be included
  in the handshake hashes, but must otherwise be ignored.
  

  Por lo tanto, aunque una implementación SSL 3.0 estaría "justificada" al ignorar cualquier extensión posterior a SSL-3.0 en ClientHello , esto no impide que aparezcan dichas extensiones y posiblemente se use SHA-256. Dado que SSL 3.0 no es realmente un "estándar", las implementaciones de SSL 3.0 también pueden optar por respetar dichas extensiones. Una extensión particular que puede usar SHA-256 es tickets de sesión , por lo que el servidor descarga el estado de una sesión en el cliente . Para protegerse contra clientes maliciosos, el ticket de la sesión normalmente estará cifrado y protegido de integridad; RFC 5077 incluye un método de construcción de boletos recomendados que, de hecho, se basa en HMAC / SHA-256 para la integridad.

Resumen: mientras SSL 3.0 se definió mucho antes de SHA-256, y por lo tanto no puede confiar en SHA-256, hay varias maneras en que algunos SHA-256 se abrieron paso hacia SSL 3.0. Quizás más relevante es el hecho de que no hay una forma estándar de eliminar MD5 o SHA-1 de SSL 3.0, ya que son parte de la PRF, pero nuevamente, SSL 3.0 no es un estándar de todos modos. SSL 3.0 es solo lo que Netscape estaba haciendo en ese momento .