FTPS

FTPS (también conocido como FTP-SSL y FTP Secure) es una extensión del protocolo de transferencia de archivos (FTP) de uso común que agrega soporte para los protocolos criptográficos Transport Layer Security (TLS) y, anteriormente, Secure Sockets Layer (SSL, que ahora está prohibido por RFC7568).

FTPS no debe confundirse con el Protocolo de transferencia de archivos SSH (SFTP), un subsistema seguro de transferencia de archivos para el protocolo Secure Shell (SSH) con el que no es compatible. También es diferente de FTP sobre SSH, que es la práctica de hacer un túnel FTP a través de una conexión SSH.

Fondo

El Protocolo de transferencia de archivos se redactó en 1971 para su uso con la red científica y de investigación ARPANET. El acceso a ARPANET durante este tiempo se limitó a una pequeña cantidad de sitios militares y universidades y a una estrecha comunidad de usuarios que podían operar sin requisitos de seguridad y privacidad de datos dentro del protocolo.

A medida que ARPANET dio paso a NSFNET y luego a Internet, una población más amplia tuvo potencialmente acceso a los datos a medida que atravesaban caminos cada vez más largos desde el cliente al servidor. La posibilidad de que terceros no autorizados espiaran las transmisiones de datos aumentó proporcionalmente.

En 1994, la empresa de navegadores de Internet Netscape desarrolló y lanzó el contenedor de capa de aplicación, Secure Sockets Layer. Este protocolo permitió que las aplicaciones se comunicaran a través de una red de forma privada y segura, desalentando las escuchas, la manipulación y la falsificación de mensajes. Si bien podría agregar seguridad a cualquier protocolo que use conexiones confiables, como TCP, Netscape lo usó más comúnmente con HTTP para formar HTTPS.

El protocolo SSL finalmente se aplicó a FTP, con un borrador de Solicitud de comentarios (RFC) publicado a finales de 1996. Poco después se registró un puerto oficial de la IANA. Sin embargo, el RFC no se finalizó hasta 2005.

Métodos para invocar la seguridad

Se desarrollaron dos métodos separados para invocar la seguridad del cliente para su uso con clientes FTP: Implicit y Explicit. Mientras que el método implícito requiere que se establezca una Seguridad de la capa de transporte desde el inicio de la conexión, lo que a su vez rompe la compatibilidad con clientes y servidores que no son compatibles con FTPS, el método explícito utiliza comandos y respuestas del protocolo FTP estándar para actualizar una conexión de texto sin formato a una cifrada, lo que permite utilizar un único puerto de control para atender a clientes compatibles y no compatibles con FTPS.

Implícito

La negociación no se admite con configuraciones FTPS implícitas. Se espera que un cliente inmediatamente desafíe al servidor FTPS con un mensaje TLS ClientHello. Si el servidor FTPS no recibe dicho mensaje, el servidor debería interrumpir la conexión.

Para mantener la compatibilidad con los clientes existentes que no son compatibles con FTPS, se esperaba que el FTPS implícito escuchara en el conocido puerto 990/TCP de la IANA para el canal de control FTPS y en el puerto 989/TCP para el canal de datos FTPS. Esto permitió a los administradores conservar servicios compatibles con el legado en el canal de control FTP 21/TCP original.

Tenga en cuenta que la negociación implícita no se definió en RFC 4217. Como tal, se considera un método anterior y obsoleto para negociar TLS/SSL para FTP.

Explícita

En modo explícito (también conocido como FTPES), un cliente FTPS debe "solicitar explícitamente" seguridad desde un servidor FTPS y luego pasar a un método de cifrado mutuamente acordado. Si un cliente no solicita seguridad, el servidor FTPS puede permitir que el cliente continúe en modo inseguro o rechazar la conexión.

El mecanismo de negociación de autenticación y seguridad con FTP fue añadido bajo RFC 2228, que incluyó el nuevo comando FTP AUTH. Si bien esta RFC no define explícitamente ningún mecanismo de seguridad requerido, por ejemplo SSL o TLS, requiere que el cliente de FTPS retar al servidor FTPS con un mecanismo mutuamente conocido. Si el cliente FTPS desafía al servidor FTPS con un mecanismo de seguridad desconocido, el servidor FTPS responderá al comando AUTH con código de error 504 (sin apoyo). Los clientes pueden determinar qué mecanismos son compatibles con la consulta del servidor FTPS con el comando FEAT, aunque los servidores no están obligados necesariamente a ser honestos al revelar qué niveles de seguridad soportan. Métodos comunes para invocar seguridad FTPS incluye TLS AUTH y SSL AUTH.

El método explícito se define en RFC 4217. En las versiones posteriores del documento, el cumplimiento de FTPS requería que los clientes siempre negociaran utilizando el método AUTH TLS.

Seguridad de la capa de transporte (TLS)/Capa de conexión segura (SSL)

Soporte general

FTPS incluye soporte completo para los protocolos criptográficos TLS y SSL, incluido el uso de certificados de autenticación de clave pública del lado del servidor y certificados de autorización del lado del cliente. También admite cifrados compatibles, incluidos AES, RC4, RC2, Triple DES y DES. Además, admite funciones hash SHA, MD5, MD4 y MD2.

Ámbito de uso

En modo implícito, toda la sesión FTPS está cifrada. El modo explícito se diferencia en que el cliente tiene control total sobre qué áreas de la conexión se cifrarán. La activación y desactivación del cifrado para el canal de control FTPS y el canal de datos FTPS se puede realizar en cualquier momento. La única restricción proviene del servidor FTPS, que tiene la capacidad de denegar comandos según la política de cifrado del servidor.

Canal de comando seguro

Se puede ingresar al modo de canal de comando seguro mediante la emisión de los comandos AUTH TLS o AUTH SSL. Después de ese tiempo, se supone que todo el control de comandos entre el cliente y el servidor FTPS está cifrado. En general, se recomienda ingresar a dicho estado antes de la autenticación y autorización del usuario para evitar la escucha de los datos de nombre de usuario y contraseña por parte de terceros.

Canal de datos seguro

Se puede ingresar al canal de datos seguro mediante la emisión del comando PROT. no está habilitado de forma predeterminada cuando se emite el comando AUTH TLS. Después de ese tiempo, se supone que toda la comunicación del canal de datos entre el cliente y el servidor FTPS está cifrada.

El cliente FTPS puede salir del modo de canal de datos seguro en cualquier momento emitiendo un comando CDC (borrar canal de datos).

Razones para desactivar el cifrado

Puede que no sea ventajoso utilizar el cifrado del canal de datos al realizar transferencias en los siguientes escenarios:

• Los archivos que se transfieren son de naturaleza no sensible, haciendo innecesaria la encriptación
• Los archivos que se transfieren ya están cifrados a nivel de archivo o están pasando por una VPN cifrada, haciendo redundante la encriptación,
• Los modos de encriptación TLS o SSL disponibles no cumplen el nivel deseado de encriptación. Esto es común con clientes o servidores FTPS mayores que pueden haberse limitado a 40 bits SSL debido a leyes anteriores de exportación de alta cifrado de los Estados Unidos.

Puede que no sea ventajoso utilizar el cifrado del canal de control en los siguientes escenarios:

• Uso de FTPS cuando el cliente o servidor reside detrás de un firewall de red o dispositivo de traducción de direcciones de red (NAT). (Ver Incompatibilidades de cortafuegos abajo.)
• Uso repetido de comandos AUTH y CCC/CDC por clientes FTP anónimos dentro de la misma sesión. Tal comportamiento se puede utilizar como una negación basada en los recursos del ataque al servicio, ya que la sesión TLS/SSL debe regenerarse cada vez, utilizando el tiempo del procesador del servidor.

Certificados SSL

Al igual que HTTPS, los servidores FTPS deben proporcionar un certificado de clave pública. Estos certificados se pueden solicitar y crear utilizando herramientas como OpenSSL.

Cuando estos certificados están firmados por una autoridad certificadora confiable, esto proporciona seguridad de que el cliente está conectado al servidor solicitado, evitando un ataque de intermediario. Si el certificado no está firmado por una CA confiable (un certificado autofirmado), el cliente FTPS puede generar una advertencia que indique que el certificado no es válido. El cliente puede optar por aceptar el certificado o rechazar la conexión.

Esto contrasta con el Protocolo de transferencia de archivos SSH (SFTP), que no presenta certificados firmados, sino que se basa en la autenticación fuera de banda de claves públicas.

Incompatibilidades de firewall

Debido a que FTP utiliza un puerto secundario dinámico (para canales de datos), muchos firewalls fueron diseñados para espiar los mensajes de control del protocolo FTP para determinar qué conexiones de datos secundarios deben permitir. Sin embargo, si la conexión de control FTP está cifrada mediante TLS/SSL, el firewall no puede determinar el número de puerto TCP de una conexión de datos negociada entre el cliente y el servidor FTP. Por lo tanto, en muchas redes con firewall, una implementación FTPS fallará cuando una implementación FTP no cifrada funcionará. Este problema se puede resolver con el uso de una gama limitada de puertos para datos y configurando el firewall para abrir estos puertos.