I "codici di esportazione" sono stati definiti in SSL 3.0 e TLS 1.0 , ma implicavano che la crittografia simmetrica si basava su un Solo chiave a 40 bit; questo è altamente fragile in pratica. In particolare, la riduzione era diretta (la chiave ha esattamente 40 bit di lunghezza esatta), invece di un trucco di riduzione con uno spazio per la chiave a 40 bit (come può essere fatto in RC2), quindi le tabelle precalcolate possono essere utilizzate per rompere questa crittografia istantaneamente . Usare una "suite di cifratura di esportazione" non è molto meglio che non usare affatto SSL, almeno contro l'intercettazione passiva (per gli attacchi attivi , potremmo obiettare).
Questa è una ragione sufficiente per non usare affatto questi pacchetti di crittografia. Infatti TLS 1.1 e TLS 1.2 dichiararli come non supportati. Infatti, nell'allegato A.5 di TLS 1.1, troviamo questo testo:
When SSLv3 and TLS 1.0 were designed, the United States restricted
the export of cryptographic software containing certain strong
encryption algorithms. A series of cipher suites were designed to
operate at reduced key lengths in order to comply with those
regulations. Due to advances in computer performance, these
algorithms are now unacceptably weak, and export restrictions have
since been loosened. TLS 1.1 implementations MUST NOT negotiate
these cipher suites in TLS 1.1 mode. However, for backward
compatibility they may be offered in the ClientHello for use with TLS
1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the
server did not choose one of these cipher suites during the
handshake. These ciphersuites are listed below for informational
purposes and to reserve the numbers.
Si noti inoltre che le normative sull'esportazione degli Stati Uniti sono state alleggerite intorno al 2000, quindi queste suite di crittografia non hanno molto senso al giorno d'oggi.
Se non esiste una suite di crittografia supportata da client e server, non sarà in grado di "eseguire SSL".
Dubito, tuttavia, che ci siano persone su Internet con browser che possono utilizzare solo suite di crittografia "export" e queste persone sono ancora in grado di connettersi a Internet e provare a utilizzarlo. Anche Netscape Navigator supporta suite di crittografia non di esportazione ed era legalmente esportabile (la versione 4.8 era del 2002 e le versioni precedenti alla 4.8 si bloccavano sul testo UTF-8, quindi non possono essere considerate come "utilizzabili" ...).
Inoltre, tieni presente che i regolamenti sulle esportazioni sono proprio questo: regolamenti sulle esportazioni. Ciò significa che potrebbe essere illegale per un'azienda con sede negli Stati Uniti inviare un prodotto con crittografia strong oltre confine, ad esempio nella Corea del Nord. Questo non significa che non è mai successo . Solo che se in Corea del Nord esiste un browser con crittografia SSL avanzata, allora, a un certo punto, è probabile che un regolamento di esportazione di un paese sia stato trasgredito. O forse no: un determinato software può saltare da un paese all'altro, in ogni caso con la piena conformità con le regole locali di esportazione e importazione, e quindi raggiungere la Corea del Nord, anche se un'esportazione diretta tra Stati Uniti e Corea del Nord sarebbe stata disapprovata dalle autorità statunitensi. Non vi è alcuna garanzia che i regolamenti di esportazione siano transitivi (in senso matematico).
In effetti, si può supporre che se qualcuno dalla Corea del Nord può accedere a ebay.com (significa che in pratica questo è Kim Jong-Un), probabilmente usa un browser che può fare SSL strong crittografia.
Riepilogo: le conseguenze di non supportare le suite di crittografia "di esportazione" sono, in pratica, nul.