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 de Seguridad de la capa de transporte (TLS) y, anteriormente, de Capa de sockets seguros (SSL, que ahora está prohibido por RFC7568).
No debe confundirse FTPS con el Protocolo de transferencia de archivos SSH (SFTP), un subsistema de transferencia segura 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 tunelizar FTP a través de una conexión SSH.
El Protocolo de Transferencia de Archivos fue redactado en 1971 para su uso con la red científica y de investigación ARPANET . [1] El acceso a ARPANET durante ese tiempo estaba limitado a un pequeño número de sitios militares y universidades y a una comunidad estrecha 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, ya que estos recorrían 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 . [2] Este protocolo permitía a las aplicaciones comunicarse a través de una red de forma privada y segura, lo que desalentaba las escuchas, la manipulación y la falsificación de mensajes. Si bien podía agregar seguridad a cualquier protocolo que usara conexiones confiables, como TCP , Netscape lo usaba más comúnmente con HTTP para formar HTTPS.
El protocolo SSL se aplicó finalmente al FTP, con un borrador de Solicitud de comentarios (RFC) publicado a fines de 1996. [3] Poco después se registró un puerto oficial de la IANA . Sin embargo, la RFC no se finalizó hasta 2005. [4]
Se desarrollaron dos métodos independientes para invocar la seguridad del cliente para su uso con clientes FTP: implícito y explícito . Mientras que el método implícito requiere que se establezca una seguridad de la capa de transporte desde el principio 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 encriptada, lo que permite utilizar un único puerto de control para brindar servicio tanto a clientes compatibles con FTPS como a clientes que no lo son.
La negociación no es compatible con configuraciones FTPS implícitas. Se espera que un cliente envíe inmediatamente un mensaje ClientHello de TLS al servidor FTPS . Si el servidor FTPS no recibe dicho mensaje, debe 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 puerto 990/TCP conocido por la IANA para el canal de control FTPS y en el puerto 989/TCP para el canal de datos FTPS. [5] Esto permitió a los administradores conservar los 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 de negociación de TLS/SSL para FTP. [6]
En el modo explícito (también conocido como FTPES), un cliente FTPS debe "solicitar explícitamente" seguridad a un servidor FTPS y luego pasar a un método de cifrado acordado mutuamente. 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 para negociar la autenticación y la seguridad con FTP se agregó en la RFC 2228, que incluía el nuevo comando FTP AUTH. Si bien esta RFC no define explícitamente ningún mecanismo de seguridad requerido, por ejemplo, SSL o TLS, sí requiere que el cliente FTPS desafíe 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 el código de error 504 (no compatible) . Los clientes pueden determinar qué mecanismos son compatibles consultando al servidor FTPS con el comando FEAT, aunque no se requiere necesariamente que los servidores sean honestos al revelar qué niveles de seguridad admiten. Los métodos comunes para invocar la seguridad FTPS incluyen AUTH TLS y AUTH SSL.
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.
FTPS incluye compatibilidad total con 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 las funciones hash SHA , MD5 , MD4 y MD2 .
En el modo implícito, se cifra toda la sesión FTPS. El modo explícito se diferencia en que el cliente tiene control total sobre qué áreas de la conexión se cifrarán. La habilitación y deshabilitació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 rechazar comandos según la política de cifrado del servidor.
Se puede ingresar al modo de canal de comandos seguro mediante la emisión de los comandos AUTH TLS o AUTH SSL. Después de ese tiempo, se asume que todo el control de comandos entre el cliente y el servidor FTPS está cifrado. Por lo general, se recomienda ingresar a dicho estado antes de la autenticación y autorización del usuario para evitar que terceros puedan espiar los datos de nombre de usuario y contraseña.
Se puede ingresar al canal de datos seguro mediante la emisión del comando PROT. No está habilitado de manera predeterminada cuando se emite el comando AUTH TLS. Después de ese tiempo, se asume 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).
Puede que no resulte ventajoso utilizar el cifrado del canal de datos al realizar transferencias en los siguientes escenarios:
Puede que no resulte ventajoso utilizar el cifrado del canal de control en los siguientes escenarios:
Al igual que HTTPS , los servidores FTPS deben proporcionar un certificado de clave pública . Estos certificados se pueden solicitar y crear mediante herramientas como OpenSSL .
Cuando estos certificados están firmados por una autoridad de certificación de confianza , se garantiza que el cliente está conectado al servidor solicitado, lo que evita un ataque de intermediario . Si el certificado no está firmado por una CA de confianza (un certificado autofirmado ), el cliente FTPS puede generar una advertencia que indique que el certificado no es válido. El cliente puede elegir 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.
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 a fin de determinar qué conexiones de datos secundarias necesitan 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 de FTPS fallará cuando una implementación de FTP sin cifrar sí lo hará. Este problema se puede resolver con el uso de un rango limitado de puertos para datos y configurando el firewall para abrir estos puertos.