SSLv3 utilizza SHA256 come algoritmo di hashing?

TLS 1.0 (successore di SSLv3) è stato pubblicato nel gennaio 1999 ( RFC 2246 ). SHA-2 è stato pubblicato per la prima volta su FIPS 180-2 nel 2001. Pertanto, non è possibile che un'implementazione che segua le specifiche SSL3 abbia potuto supportare SHA-2.

La versione utilizzata da SSLv3 sarebbe stata SHA-1, proprio come 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 pagina 59

Sebbene la risposta di @ Angel sia per lo più corretta, ci possono essere dettagli ...

Nella famiglia di protocolli SSL (una famiglia che include SSL 3.0 , nonché TLS 1.0 , TLS 1.1 e TLS 1.2 ), ci sono circa quattro posti in cui può essere usata una funzione di hash:

• Nel "PRF", che è la funzione utilizzata per la derivazione della chiave durante l'handshake e altri usi simili. In SSL 3.0, TLS 1.0 e TLS 1.1, il PRF utilizza esclusivamente MD5 e SHA-1 (il PRF di SSL 3.0 è diverso da quello utilizzato in TLS 1.0 e 1.1). In TLS 1.2, il PRF utilizza una funzione di hash che dipende dalla suite di crittografia, in genere SHA-256.

• Per la protezione dell'integrità dei record, normalmente come parte di HMAC (nelle varianti TLS) o sort-of-HMAC (in SSL 3.0). Questo è definito dalla suite di crittografia. Le suite di crittografia sono, per definizione, aperte: le nuove suite di crittografia possono essere definite molto tempo dopo che il protocollo di base è stato standardizzato. Ad esempio, RFC 5487 definisce alcuni pacchetti di crittografia in un modello di "chiave pre-condivisa" e che utilizzano HMAC / SHA- 256 per integrità; che RFC afferma esplicitamente che alcune di queste suite (quelle che si basano su AES in modalità CBC per la crittografia) sono applicabili alle versioni precedenti di TLS (1.0 e 1.1). Tecnicamente, questi pacchetti di crittografia si applicano anche a SSL 3.0.

  Si noti che SSL 3.0 è definito solo in un RFC "storico", non in uno "standard", il che rende piuttosto difficile parlare di ciò che può e non può essere fatto in SSL 3.0.

• Come parte delle firme sui certificati. Le implementazioni implementate e implementate di SSL 3.0 (ad esempio quella in Windows / Internet Explorer) elaboreranno con gelo i certificati firmati con RSA + SHA-256, anche come parte di un handshake che procede lungo la versione del protocollo SSL 3.0.

• Nelle estensioni. SSL 3.0 correttamente detto (con le avvertenze spiegate sopra) non definisce alcuna estensione, ma lascia loro spazio. Precisamente, RFC 6101 dice nella sezione 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.
  

  Pertanto, mentre un'implementazione di SSL 3.0 sarebbe "giustificata" nell'ignorare qualsiasi estensione post-SSL-3.0 in ClientHello , ciò non impedisce a tali estensioni di apparire e possibilmente usare SHA-256. Poiché SSL 3.0 non è in realtà uno "standard", le implementazioni SSL 3.0 possono anche scegliere di onorare tali estensioni. Un'estensione particolare che può utilizzare SHA-256 è ticket di sessione , in base alla quale il server scarica lo stato di una sessione sul client . Al fine di proteggersi da client dannosi, il ticket di sessione sarà normalmente crittografato e protetto dall'integrità; RFC 5077 include un metodo costruzione ticket consigliato che, in effetti, si basa su HMAC / SHA-256 per l'integrità.

Riepilogo: mentre SSL 3.0 è stato definito molto prima di SHA-256 e quindi non può fare affidamento su SHA-256, ci sono diversi modi in cui alcuni SHA-256 si insinuano in SSL 3.0. Forse più rilevante è il fatto che non esiste un modo standard per rimuovere MD5 o SHA-1 da SSL 3.0, dato che fanno parte del PRF - ma anche in questo caso, SSL 3.0 non è comunque uno standard. SSL 3.0 è solo ciò che Netscape stava facendo in quel momento .