Transport Layer Security, cuando no todo son ventajas
En busca de conexiones seguras de correo electrónico
Desplegar correo electrónico seguro utilizando el protocolo TLS (Transport Layer Security) puede resultar más problemático de lo que parece. Y es que la falta de autentificación del cliente, la disparidad a la hora de decidirse a implementar el protocolo TLS en los servidores de correo web o incluso el riesgo que supone la transmisión de información crítica que puede ser interceptada son algunos factores a tener en cuenta a la hora de garantizar la seguridad de los datos de una compañía.
Cualquier compañía de servicios financieros establece conexiones de correo electrónico seguras con sus clientes con el fin de proteger mensajes que contienen datos financieros críticos. Hasta ahora, el método tradicional para alcanzar un nivel considerable de seguridad en la transmisión de correo electrónico consistía en utilizar un producto de encriptación para ordenadores, que cumpliera con uno de los dos estándares habituales, S/MIME u OpenPGP. Estos estándares son ideales, en caso de contar con una base de usuarios reducida y con alta capacidad tecnológica, sin embargo al aumentar el tamaño de la misma, comienzan a aparecer problemas relativos a la facilidad de uso, la gestión de certificados o los costes de licencia por usuario.
TLS, ventajas a medias
Es en este caso cuando las empresas están optando por adoptar un método distinto. Hablamos de TLS (Transport Layer Security), un estándar de transmisión de correo electrónico, que no es sino la versión más avanzada del protocolo SSL (Secure Socket Layer).
Uno de los beneficios de TLS es su capacidad para abrir canales seguros entre servidores de correo electrónico. Así, una vez que dos servidores de correo electrónico comienzan a comunicarse entre sí en lenguaje TLS, pueden transmitir todo el flujo de e-mails habitual a través de ese canal seguro. Y es que cada mensaje transmitido entre esas dos compañías es encriptado y desencriptado automáticamente sin necesidad de esfuerzo alguno por parte del usuario final.
A estas ventajas hay que añadir el valor añadido de que, en la mayoría de los casos, el software incluido en las pasarelas de correo electrónico lleva incorporado el protocolo TLS, con lo que su uso no requiere un coste adicional.
¿Qué pasa cuando la información sale de las fronteras?
Sin embargo, al igual que sucede con cualquier producto de encriptación, “el problema está en los detalles”, y son esos pormenores los que, en realidad, están preocupando a los usuarios desde hace algún tiempo.
Uno de los inconvenientes es que TLS sólo hace segura la conexión entre los dos servidores de e-mail. Sin embargo, no ofrece protección una vez que el mensaje ha llegado al servidor de destino, por lo que los mensajes de correo electrónico confidenciales siguen sin estar protegidos en el servidor de la compañía receptora.
De esta manera, en el caso de que una compañía financiera, por ejemplo, establezca conexiones seguras con sus propios clientes, tan sólo deberá incluir notas de advertencia en los contratos o en la información confidencial que transmite para mitigar el posible riesgo. Sin embargo, en el caso de transmitir datos de cariz crítico fuera de los muros de una corporación y sus delegaciones, empiezan los problemas. Y es que algunos clientes ya se han empezado a plantear en qué medida sus mensajes seguirán siendo seguros una vez que hayan salido de sus “fronteras corporativas”.
No pocas compañías han invertido buena parte de su presupuesto en tecnología, en auditorias y revisiones de seguridad, con el fin de encontrar respuesta a esta pregunta y convencerse de que sus sistemas de seguridad son los adecuados.
Autentificación del cliente
A ello hay que sumarle el inconveniente de los certificados digitales. Como en cualquier buen protocolo de encriptación, TLS utiliza este tipo de certificados para comprobar la identidad del remitente y del receptor. En nuestro caso, cada servidor de correo electrónico utiliza un certificado digital para autentificarse a sí mismo ante el otro servidor de correo electrónico. El problema estriba en que la mayoría de los certificados están diseñados para conexiones SSL en servidores web, que constituyen la mayor parte del mercado. Los servidores web tienden a utilizar sólo autentificación de servidores.
Así, cuando uno se conecta con el servidor, éste envía un certificado para demostrar que se ha accedido al servidor web correcto. Sin embargo, pocos servidores solicitan a los usuarios o clientes que demuestren su identidad presentando su propio certificado digital, ya que la mayoría de los usuarios no se han preocupado nunca por obtenerlo. Por lo tanto, pese a que la autentificación de cliente es una opción posible en SSL, lo cierto es que rara vez se utiliza.
No sucede así con TLS. La autentificación del cliente es una parte importante de la seguridad en el envío y recepción de correos electrónicos. De esta manera, cuando se están adquiriendo certificados para nuevos servidores e-mail con capacidad TLS, es preciso comprobar que la autoridad que emite el certificado ofrece certificados que soportan autentificación de clientes. La mayoría parece no hacerlo así, al menos no por defecto.
Utilización obligatoria
Surge entonces la cuestión de la utilización obligatoria. Los servidores de correo electrónico pueden establecerse de dos formas diferentes: TLS ocasional, en la que los servidores intentan negociar una conexión TLS con otros servidores pero recurren al correo electrónico no encriptado si no pueden hacerlo; y la modalidad de TLS obligatorio, donde los servidores de e-mail utilizan sólo TLS y rechazan comunicarse con los servidores e-mail de otra compañía si no soportan este protocolo.
Aunque la primera modalidad es más simple de realizar, si un cliente re-configura repentinamente sus servidores de e-mail, como sucede con frecuencia, y la conexión TLS deja de funcionar, entonces todos los mensajes de e-mail confidenciales serán enviados sin encriptar a través de Internet. Y además, a menos que se haya establecido algún sistema de generación de informes, nunca se sabrá que ha sucedido así.
Por otra parte, si uno opta por la obligatoriedad del protocolo TLS, significa que el correo electrónico deja repentinamente de fluir a y desde el cliente en cuestión.
Por otro lado, también hay que tener en cuenta los problemas de routing de correo electrónico. El routing se basa en la utilización de registros de intercambio de correo o “mail exchange” (MX), que especifican los servidores e-mail que deben ser utilizados para un dominio específico. Por ejemplo, cuando uno envía un mensaje de correo electrónico a president@whitehouse.org. su servidor busca el registro MX para whitehouse.gov. y envía el mensaje al servidor mailhub-wh2.whitehouse-gov. Como TLS utiliza los mismos mecanismos, no deberá haber problemas.
También es posible encontrar antiguos servidores e-mail que no soportan TLS y en su lugar, las compañías han establecido un servidor dedicado y no listado para conexiones TLS o servidores de backup que no soportaban TLS.
En esos casos hay que dejar de realizar búsquedas MX y comenzar a especificar qué servidores utilizar y para qué dominio. Aunque esta tarea es bastante fácil, gestionarla re
Cualquier compañía de servicios financieros establece conexiones de correo electrónico seguras con sus clientes con el fin de proteger mensajes que contienen datos financieros críticos. Hasta ahora, el método tradicional para alcanzar un nivel considerable de seguridad en la transmisión de correo electrónico consistía en utilizar un producto de encriptación para ordenadores, que cumpliera con uno de los dos estándares habituales, S/MIME u OpenPGP. Estos estándares son ideales, en caso de contar con una base de usuarios reducida y con alta capacidad tecnológica, sin embargo al aumentar el tamaño de la misma, comienzan a aparecer problemas relativos a la facilidad de uso, la gestión de certificados o los costes de licencia por usuario.
TLS, ventajas a medias
Es en este caso cuando las empresas están optando por adoptar un método distinto. Hablamos de TLS (Transport Layer Security), un estándar de transmisión de correo electrónico, que no es sino la versión más avanzada del protocolo SSL (Secure Socket Layer).
Uno de los beneficios de TLS es su capacidad para abrir canales seguros entre servidores de correo electrónico. Así, una vez que dos servidores de correo electrónico comienzan a comunicarse entre sí en lenguaje TLS, pueden transmitir todo el flujo de e-mails habitual a través de ese canal seguro. Y es que cada mensaje transmitido entre esas dos compañías es encriptado y desencriptado automáticamente sin necesidad de esfuerzo alguno por parte del usuario final.
A estas ventajas hay que añadir el valor añadido de que, en la mayoría de los casos, el software incluido en las pasarelas de correo electrónico lleva incorporado el protocolo TLS, con lo que su uso no requiere un coste adicional.
¿Qué pasa cuando la información sale de las fronteras?
Sin embargo, al igual que sucede con cualquier producto de encriptación, “el problema está en los detalles”, y son esos pormenores los que, en realidad, están preocupando a los usuarios desde hace algún tiempo.
Uno de los inconvenientes es que TLS sólo hace segura la conexión entre los dos servidores de e-mail. Sin embargo, no ofrece protección una vez que el mensaje ha llegado al servidor de destino, por lo que los mensajes de correo electrónico confidenciales siguen sin estar protegidos en el servidor de la compañía receptora.
De esta manera, en el caso de que una compañía financiera, por ejemplo, establezca conexiones seguras con sus propios clientes, tan sólo deberá incluir notas de advertencia en los contratos o en la información confidencial que transmite para mitigar el posible riesgo. Sin embargo, en el caso de transmitir datos de cariz crítico fuera de los muros de una corporación y sus delegaciones, empiezan los problemas. Y es que algunos clientes ya se han empezado a plantear en qué medida sus mensajes seguirán siendo seguros una vez que hayan salido de sus “fronteras corporativas”.
No pocas compañías han invertido buena parte de su presupuesto en tecnología, en auditorias y revisiones de seguridad, con el fin de encontrar respuesta a esta pregunta y convencerse de que sus sistemas de seguridad son los adecuados.
Autentificación del cliente
A ello hay que sumarle el inconveniente de los certificados digitales. Como en cualquier buen protocolo de encriptación, TLS utiliza este tipo de certificados para comprobar la identidad del remitente y del receptor. En nuestro caso, cada servidor de correo electrónico utiliza un certificado digital para autentificarse a sí mismo ante el otro servidor de correo electrónico. El problema estriba en que la mayoría de los certificados están diseñados para conexiones SSL en servidores web, que constituyen la mayor parte del mercado. Los servidores web tienden a utilizar sólo autentificación de servidores.
Así, cuando uno se conecta con el servidor, éste envía un certificado para demostrar que se ha accedido al servidor web correcto. Sin embargo, pocos servidores solicitan a los usuarios o clientes que demuestren su identidad presentando su propio certificado digital, ya que la mayoría de los usuarios no se han preocupado nunca por obtenerlo. Por lo tanto, pese a que la autentificación de cliente es una opción posible en SSL, lo cierto es que rara vez se utiliza.
No sucede así con TLS. La autentificación del cliente es una parte importante de la seguridad en el envío y recepción de correos electrónicos. De esta manera, cuando se están adquiriendo certificados para nuevos servidores e-mail con capacidad TLS, es preciso comprobar que la autoridad que emite el certificado ofrece certificados que soportan autentificación de clientes. La mayoría parece no hacerlo así, al menos no por defecto.
Utilización obligatoria
Surge entonces la cuestión de la utilización obligatoria. Los servidores de correo electrónico pueden establecerse de dos formas diferentes: TLS ocasional, en la que los servidores intentan negociar una conexión TLS con otros servidores pero recurren al correo electrónico no encriptado si no pueden hacerlo; y la modalidad de TLS obligatorio, donde los servidores de e-mail utilizan sólo TLS y rechazan comunicarse con los servidores e-mail de otra compañía si no soportan este protocolo.
Aunque la primera modalidad es más simple de realizar, si un cliente re-configura repentinamente sus servidores de e-mail, como sucede con frecuencia, y la conexión TLS deja de funcionar, entonces todos los mensajes de e-mail confidenciales serán enviados sin encriptar a través de Internet. Y además, a menos que se haya establecido algún sistema de generación de informes, nunca se sabrá que ha sucedido así.
Por otra parte, si uno opta por la obligatoriedad del protocolo TLS, significa que el correo electrónico deja repentinamente de fluir a y desde el cliente en cuestión.
Por otro lado, también hay que tener en cuenta los problemas de routing de correo electrónico. El routing se basa en la utilización de registros de intercambio de correo o “mail exchange” (MX), que especifican los servidores e-mail que deben ser utilizados para un dominio específico. Por ejemplo, cuando uno envía un mensaje de correo electrónico a president@whitehouse.org. su servidor busca el registro MX para whitehouse.gov. y envía el mensaje al servidor mailhub-wh2.whitehouse-gov. Como TLS utiliza los mismos mecanismos, no deberá haber problemas.
También es posible encontrar antiguos servidores e-mail que no soportan TLS y en su lugar, las compañías han establecido un servidor dedicado y no listado para conexiones TLS o servidores de backup que no soportaban TLS.
En esos casos hay que dejar de realizar búsquedas MX y comenzar a especificar qué servidores utilizar y para qué dominio. Aunque esta tarea es bastante fácil, gestionarla re
