Hispanopedia WikiFTPS (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 añade compatibilidad con 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 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 consiste en tunelizar 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 . [ 1 ] El acceso a ARPANET durante este tiempo estaba limitado a un pequeño número de sitios militares y universidades y a una reducida comunidad de usuarios que podían operar sin los requisitos de seguridad y privacidad de datos dentro del protocolo.
A medida que ARPANET dio paso a NSFNET y posteriormente a Internet , una población más amplia tuvo acceso potencial a los datos, ya que estos recorrían rutas cada vez más largas desde el cliente hasta el servidor. La oportunidad para que terceros no autorizados interceptaran las transmisiones de datos aumentó proporcionalmente.
En 1994, la empresa de navegadores de Internet Netscape desarrolló y lanzó el protocolo Secure Sockets Layer ( SSL) . [ 2 ] Este protocolo permitía que las aplicaciones se comunicaran a través de una red de forma privada y segura, lo que dificultaba la interceptación, la manipulación y la falsificación de mensajes. Si bien podía añadir seguridad a cualquier protocolo que utilizara conexiones fiables, como TCP , Netscape lo utilizó con mayor frecuencia junto con HTTP para formar HTTPS.
El protocolo SSL se aplicó finalmente a FTP, y a finales de 1996 se publicó un borrador de Solicitud de Comentarios (RFC). [ 3 ] Poco después se registró un puerto oficial de IANA . Sin embargo, la RFC no se finalizó hasta 2005. [ 4 ]
Métodos para invocar la seguridad
Se desarrollaron dos métodos distintos para activar 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 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 convertir una conexión de texto plano en una cifrada, lo que permite utilizar un único puerto de control para atender tanto a clientes compatibles con FTPS como a clientes que no lo son.
Implícito
La negociación no es compatible con configuraciones FTPS implícitas. Se espera que el cliente envíe inmediatamente un mensaje TLS ClientHello al servidor FTPS . Si el servidor FTPS no recibe dicho mensaje, deberá cerrar la conexión.
Para mantener la compatibilidad con los clientes existentes que no admiten FTPS, se esperaba que FTPS implícito escuchara en el puerto 990/TCP, conocido por la IANA, para el canal de control de FTPS, y en el puerto 989/TCP para el canal de datos de FTPS. [ 5 ] Esto permitió a los administradores conservar los servicios compatibles con versiones anteriores en el canal de control FTP original 21/TCP.
Cabe señalar que la negociación implícita no se definió en el RFC 4217. Por lo tanto, se considera un método anterior y obsoleto de negociación de TLS/SSL para FTP. [ 6 ]
Explícito
En el modo explícito (también conocido como FTPES), un cliente FTPS debe solicitar explícitamente seguridad a un servidor FTPS y, a continuación, utilizar un método de cifrado acordado mutuamente. Si un cliente no solicita seguridad, el servidor FTPS puede permitirle continuar en modo inseguro o rechazar la conexión.
El mecanismo para negociar la autenticación y la seguridad con FTP se añadió 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 obligatorio, como SSL o TLS, sí exige que el cliente FTPS desafíe al servidor FTPS con un mecanismo conocido por ambas partes. 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 los servidores no están obligados a revelar con exactitud los niveles de seguridad que admiten. Los métodos comunes para invocar la seguridad FTPS incluían AUTH TLS y AUTH SSL.
El método explícito se define en la RFC 4217. En las versiones posteriores del documento, el cumplimiento de FTPS requería que los clientes siempre negociaran utilizando el método TLS AUTH.
Seguridad de la capa de transporte (TLS)/Capa de sockets seguros (SSL)
Soporte general
FTPS incluye compatibilidad total con los protocolos criptográficos TLS y SSL, incluyendo el uso de certificados de autenticación de clave pública del servidor y certificados de autorización del cliente. También admite cifrados compatibles, como AES , RC4 , RC2 , Triple DES y DES . Además, admite las funciones hash SHA , MD5 , MD4 y MD2 .
Ámbito de uso
En el 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 cifran. El cifrado para el canal de control FTPS y el canal de datos FTPS se puede activar y desactivar en cualquier momento. La única restricción proviene del servidor FTPS, que tiene la capacidad de denegar comandos según su política de cifrado.
Canal de comando seguro
Se puede acceder al modo de canal de comandos seguro mediante los comandos AUTH TLS o AUTH SSL. A partir de ese momento, se asume que todo el control de comandos entre el cliente y el servidor FTPS está cifrado. Generalmente, se recomienda activar este modo antes de la autenticación y autorización del usuario para evitar que terceros intercepten los datos de nombre de usuario y contraseña.
Canal de datos seguro
Se puede acceder al canal de datos seguro mediante el comando PROT. Este no está habilitado por defecto al ejecutar el comando AUTH TLS. A partir de ese momento, 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 mediante la emisión de un comando CDC (clear data channel).
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 no son confidenciales, por lo que el cifrado no es necesario.
- Los archivos que se transfieren ya están cifrados a nivel de archivo o pasan a través de una VPN cifrada , lo que hace que el cifrado sea redundante.
- Los modos de cifrado TLS o SSL disponibles no cumplen con el nivel de cifrado deseado. Esto es común en clientes o servidores FTPS antiguos que pueden haber estado limitados a SSL de 40 bits debido a las leyes de exportación de alto cifrado de 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 el servidor se encuentran detrás de un cortafuegos o un dispositivo de traducción de direcciones de red (NAT). (Consulte la sección Incompatibilidades con cortafuegos a continuación).
- El uso repetido de los comandos AUTH y CCC/CDC por parte de clientes FTP anónimos dentro de la misma sesión puede utilizarse como un ataque de denegación de servicio basado en recursos, ya que la sesión TLS/SSL debe regenerarse cada vez, consumiendo 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 de certificación de confianza , se garantiza que el cliente se conecte al servidor solicitado, evitando así 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 indicando 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 del firewall
Dado que FTP utiliza un puerto secundario dinámico (para canales de datos), muchos cortafuegos se diseñaron para interceptar los mensajes de control del protocolo FTP y determinar qué conexiones de datos secundarias deben permitir. Sin embargo, si la conexión de control FTP está cifrada mediante TLS/SSL, el cortafuegos no puede determinar el número de puerto TCP de la conexión de datos negociada entre el cliente y el servidor FTP. Por lo tanto, en muchas redes protegidas por cortafuegos, una implementación de FTPS fallará, mientras que una implementación de FTP sin cifrar funcionará. Este problema se puede solucionar utilizando un rango limitado de puertos para los datos y configurando el cortafuegos para que abra dichos puertos.
Véase también
- FTP a través de SSH
- Comparación de protocolos de transferencia de archivos
- Copia segura (SCP), un protocolo para transferir archivos utilizando el protocolo Secure Shell (SSH).
- Protocolo de transferencia de archivos SSH (SFTP)
- Transferencia de archivos mediante protocolo de shell (FISH)
Notas
- ↑ Abbay Bhushan; Bob Braden ; Will Crowther; Eric Narslem; John Heafner; Alex McKenzie; John Melvin; Bob Sundberg; Dick Watson; Jim White (17 de noviembre de 1971). EL PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS . Grupo de Trabajo de Redes. doi : 10.17487/RFC0265 . RFC 265 .Estado desconocido. NIC 781. Obsoleto según RFC 354. Actualizado por RFC 281 , 294 , 310. Obsoleto según RFC 172 .
- ↑ "El protocolo SSL 0.2" . mozilla.org . 9 de febrero de 1995. Archivado del original el 14 de junio de 2001.
- ↑ Paul Ford-Hutchinson; Tim Hudson; Eric Murray (26 de noviembre de 1996). FTP seguro sobre SSL . IETF . ID draft-murray-auth-ftp-ssl-00.
- ↑ P. Ford-Hutchinson (octubre de 2005). Asegurando FTP con TLS . Grupo de trabajo de redes. doi : 10.17487/RFC4217 . RFC 4217 .Estándar propuesto. Actualizado por RFC 8996 .
- ↑ "Registro de nombres de servicio y números de puerto de protocolo de transporte" . Autoridad de números asignados de Internet . Consultado el 9 de octubre de 2015 .
- ↑ "Mecanismos de negociación SSL obsoletos" . Protección de FTP con TLS . IETF . 5 de abril de 2001. Sec. A. ID draft-murray-auth-ftp-ssl-07 . Consultado el 9 de octubre de 2015 .
Enlaces externos
- Descripción general de FTPS y listas de clientes y servidores.
- Curl-loader : una herramienta de código abierto para cargar y probar servidores FTPS.
- Protocolo de transferencia de archivos
- Estándares de Internet
- Seguridad de la capa de transporte
