Archivos Seguridad: Septiembre 2008
Durante el gobierno de Ronald Reagan, como parte de la investigación del famoso escándalo Irán Contras/Irán-Contra, se exhibieron un par de emails entre John Poindexter y Oliver North como pruebas de su conspiración. Estos emails fueron obtenidos de los respaldos de los servidores de email, porque los autores los habían eliminado de sus computadores cuando se vieron sorprendidos.
Ahora se ha destapado un escandalillo que involucra la filtración de email, en este caso los de la ex gobernadora de Alaska, Sarah Palin, compañera de fórmula de John McCain en las elecciones presidenciales norteamericanas (esta es una nota para los despistados, que nunca faltan).
Pero resulta que los norteamericanos tienen normas sobre el uso de email por parte de funcionarios públicos, existen leyes federales que obligan a tener un registro histórico de los correos electrónicos. Esa es la razón por lo que el comportamiento de Palin es cuestionable (aunque no es la primera vez que los funcionarios de gobierno republicanos evaden estas normas).
Ahora, yo me pregunto ¿qué pasará por estos lados?
¿Habrá siquiera una política que norme el uso de correos electrónicos por parte de los funcionarios de nuestro gobierno?
Al menos siempre me he topado en la empresa privada que existen políticas, más o menos claras, que definen que el correo corporativo no puede ser usado para otras cosas que no sean los negocios de la empresa, y por lo tanto estos son auditables.
Al menos, yo creo que los correos entregados las instituciones públicas a sus funcionarios deben ser auditables, y esto significa que debe haber un registro histórico de estas comunicaciones para su posterior análisis en proceso forenses o investigativos. Pero incluso, estos registros deberían ser asequibles al público después de un tiempo (por su valor historiográfico).
La transparencia pasa por medidas como esta, ¿no creen ustedes?
En 1981 se publica uno de los documentos más importantes de la internet, el famoso RFC 793, que define el protocolo TCP, que es el principal protocolo de internet, y que es la base de la mayoría de los protocolos usados en la red.
En este documento Jon Postel escribe, lo que ha llegado a conocerse como el Principio de Robustez, o la Ley de Postel:
Las implementaciones TCP deben seguir un principio genera del robustez: ser conservador en lo que haces, ser liberal en lo que aceptas de otros.
TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
Dependiendo de tu sistema valórico, encontrarás el consejo de Postel como algo bueno, e incluso recomendable para otros aspectos de la vida, no sólo en los protocolos de transmisión de datos.
Este principio ha sido criticado por cierto, porque aparentemenente promueve una tolerancia pasiva, o por ser demasiado liberal, y eventualmente permite aplicaciones inseguras.
La verdad es que no era la intención de Postel ser demasiado permisivo con los protocolos, y decir que las validaciones no eran necesarias. Pero, efectivamente, el principio de robustez ha sido mal interpretado, y eso nos ha generado muchos problemas, principalmente con la seguridad de las aplicaciones.
Pero no hay que olvidar que el principio de robustez tiene una mirada puesta en las necesidades de los usuarios finales.
En la actualidad esto tiende a olvidarse, y muchos desarrolladores, sobre todo los más rígidos (y sobre todo los más jóvenes), exigen que se cumplan los estándares, sin ninguna excepción, aunque eso atente contra las necesidades de los usuarios.
Consideren el caso de HTML. ¡Un verdadero caos! hay cientos de implementaciones de HTML, con miles de bugs, parches y soluciones ad-hoc incrustadas en la web y en los navegadores de internet.
En algún momento se optó por establecer estándares basados en XML como la solución definitiva del problema, y con esto se quiebró la Ley de Postel.
XML es un protocolo estricto. En teoría un documento XML inválido no debe ser aceptado. Pero habrán documentos inválidos, eso es casi inevitable.
Un ejemplo clásico es lo que pasa con la sigla "AT&T", de acuerdo a la especificación XML se debe escribir: "AT&T", pero eventualmente alguien escribirá "AT&T". Las aplicaciones que privilegien los deseos de los usuarios y acepten documentos XML escritos en forma no tan estricta (piensen en los varios tipos de browsers disponibles), terminarán imponiéndose (porque son aplicaciones más robustas).
XML nos pide que rompamos el principio de Postel, XML exige que seamos intolerantes con lo que recibimos. Esto puede atentar contra las necesidades del usuario.
Ese es un problema que aparece también en protocolos como SOAP, y en general casi todas las recomendaciones de interoperatividad basados en estándares rígidos, como XML. "La ley de Postel no acepta excepciones", cuando vamos contra este principio el que lo paga eventualmente es el usuario.
¿Qué opinan ustedes? ¿conocen otras situaciones donde al tratar de romper este principio perjudicamos la experiencia del usuario?
