Expertos proponen cifrar todo el tráfico mundial de Internet

Según una nueva propuesta, un gran porcentaje del tráfico Web mundial podría ser cifrado, dicha propuesta busca reestructurar el protocolo de transferencia de hipertexto (HTTP), que sirve de base para todas las comunicaciones entre los sitios web y los usuarios finales.

La propuesta se conoció en una carta publicada el miércoles por un funcionario de la Internet Engineering Task Force (IETF), y está basada en el escándalo de los documentos filtrados por el ex contratista de la NSA Edward Snowden, hecho que sin duda aumentó significativamente las preocupaciones acerca de la vigilancia gubernamental en internet.

HTTP 2.0

El nuevo grupo de trabajo conocido como HTTPbis (algo cómo: Regreso de HTTP), conformado por expertos de la IETF, serán los encargados de diseñar la especificación de próxima generación HTTP 2.0, en la cual se propone que  el cifrado sea la forma predeterminada en la que los datos se transfieren a través de «Internet abierto».

Parece que hay un fuerte consenso para aumentar el uso de la codificación en la red, pero hay menos consenso acerca de cómo enfrentar esto,» Mark Nottingham, presidente del grupo de trabajo HTTPbis

Ésta es la nueva propuesta oficial:

A. Opportunistic encryption for http:// URIs without server authentication—aka «TLS Relaxed» as per draft-nottingham-http2-encryption.

B. Opportunistic encryption for http:// URIs with server authentication—the same mechanism, but not «relaxed,» along with some form of downgrade protection.

C. HTTP/2 to only be used with https:// URIs on the «open» Internet. http:// URIs would continue to use HTTP/1 (and of course it would still be possible for older HTTP/1 clients to still interoperate with https:// URIs).

In subsequent discussion, there seems to be agreement that (C) is preferable to (B), since it is more straightforward; no new mechanism needs to be specified, and HSTS can be used for downgrade protection.

(C) also has this advantage over (A) and furthermore provides stronger protection against active attacks.

The strongest objections against (A) seemed to be about creating confusion about security and discouraging use of «full» TLS, whereas those against (C) were about limiting deployment of better security.

Keen observers have noted that we can deploy (C) and judge adoption of the new protocol, later adding (A) if necessary. The reverse is not necessarily true.

Furthermore, in discussions with browser vendors (who have been among those most strongly advocating more use of encryption), there seems to be good support for (C), whereas there’s still a fair amount of doubt/disagreement regarding (A).