Los "cifrados de exportación" se definieron en SSL 3.0 y TLS 1.0 , pero implicaban que el cifrado simétrico se basaba en un Clave de 40 bits solamente; Esto es altamente rompible en la práctica. En particular, la reducción fue directa (la clave tiene una longitud de 40 bits exactamente), en lugar de un truco de reducción con un espacio de clave de 40 bits (como se puede hacer en RC2), por lo que se pueden usar tablas precomputadas para romper este cifrado al instante . Usar un "paquete de cifrado de exportación" no es mucho mejor que no usar SSL en absoluto, al menos contra ataques pasivos (para los ataques activos , podríamos argumentar).
Esta es razón suficiente para no usar estas suites de cifrado. De hecho, TLS 1.1 y TLS 1.2 declararlos como no soportados. De hecho, en el anexo A.5 de TLS 1.1, encontramos este texto:
Cuando se diseñaron SSLv3 y TLS 1.0, los Estados Unidos restringieron
La exportación de software criptográfico que contiene ciertos fuertes.
algoritmos de encriptación. Una serie de suites de cifrado fueron diseñadas para
operar a longitudes de llave reducidas para cumplir con esas
regulaciones Debido a los avances en el rendimiento del ordenador, estos
los algoritmos ahora son inaceptablemente débiles, y las restricciones de exportación tienen
ya se ha aflojado. Las implementaciones de TLS 1.1 NO DEBEN negociar
estos conjuntos de cifrado en modo TLS 1.1. Sin embargo, para atrás
compatibilidad que pueden ofrecerse en ClientHello para su uso con TLS
1.0 o servidores solo SSLv3. Los clientes de TLS 1.1 DEBEN comprobar que
El servidor no eligió una de estas suites de cifrado durante el
apretón de manos. Estos conjuntos de claves se enumeran a continuación para información
Propósitos y reservar los números.
Tenga en cuenta también que las regulaciones de exportación de los EE. UU. se han suavizado alrededor del año 2000, por lo que estas suites de cifrado no tienen mucho sentido en la actualidad.
Si no hay un conjunto de cifrado que sean compatibles tanto con el cliente como con el servidor, no podrán "hacer SSL".
Sin embargo, dudo mucho que haya personas en Internet con navegadores que solo pueden usar "exportar" suites de cifrado, y estas personas todavía pueden conectarse a Internet e intentar usarla. Incluso Netscape Navigator admitía suites de cifrado sin exportación, y era legalmente exportable (la versión 4.8 era de 2002 y las versiones anteriores a 4.8 se bloquean en el texto UTF-8, por lo que no pueden considerarse "utilizables" en absoluto ...).
Además, tenga en cuenta que las regulaciones de exportación son solo eso: regulaciones de exportación. Esto significa que podría ser ilegal que una empresa con sede en EE. UU. Envíe un producto con un cifrado sólido a través de la frontera, por ejemplo, a Corea del Norte. Esto no significa que nunca sucedió . Solo que si hay un navegador con cifrado SSL fuerte en este momento en Corea del Norte, entonces, en algún momento, es probable que se haya transgredido una regulación de exportación de un país. O incluso tal vez no: un software determinado puede saltar de un país a otro, en cada caso con el pleno cumplimiento de las normas locales de exportación e importación, y luego llegar a Corea del Norte, incluso si una exportación directa de Estados Unidos a Corea del Norte hubiera sido mal vista. por las autoridades estadounidenses. No hay garantía de que las regulaciones de exportación sean transitivas (en el sentido matemático).
De hecho, se puede suponer que si alguien de Corea del Norte puede acceder a ebay.com (lo que significa en la práctica que este tipo es el mismo Kim Jong-Un), lo más probable es que use un navegador que pueda hacer SSL fuerte. cifrado.
Resumen: las consecuencias de no admitir los conjuntos de cifrado de "exportación" son, en la práctica, nulas.