FTPS

FTPS (anche noto come FTPES, FTP-SSL, S-FTP and FTP Secure) è un'estensione del protocollo File Transfer Protocol (FTP) a cui viene aggiunta la cifratura Transport Layer Security (TLS) o Secure Sockets Layer (SSL).

FTPS non deve essere confuso con SSH File Transfer Protocol (SFTP), un sottosistema di trasferimento di file sicuri per il Secure Shell (SSH) con cui non è compatibile.

Storia

Il protocollo di trasferimento file è stato implementato nel 1971 per essere utilizzato dalla rete scientifica e di ricerca, ARPANET. L'accesso a ARPANET, durante gli anni settanta, era limitato a un numero ristretto di siti militari, università ed a una ristretta comunità di utenti che potevano operare senza requisiti di sicurezza e privacy all'interno del protocollo.

Mentre ARPANET lasciava il posto a NSFnet e poi a Internet, una popolazione più ampia poteva potenzialmente accedere ai dati percorrendo percorsi sempre più lunghi da client a server.

Nel 1994, la società di browser Internet Netscape ha sviluppato e rilasciato il wrapper del livello di applicazione, il Secure Sockets Layer. Questo protocollo consentiva alle applicazioni di comunicare attraverso una rete in modo privato e sicuro, cercando di evitare intercettazioni, manomissioni e falsificazioni dei messaggi. Questo protocollo potrebbe aggiungere sicurezza a qualsiasi protocollo che utilizza connessioni affidabili, come TCP, ma è stato più comunemente utilizzato da Netscape con HTTP per implementare il protocollo HTTPS.

Il protocollo SSL è stato infine applicato a FTP con una bozza di Request for Comments (RFC) pubblicata alla fine del 1996 anche se l'RFC non è stato finalizzato fino al 2005.

Metodi per invocare la sicurezza

Sono stati sviluppati due metodi per richiamare la sicurezza del client che utilizza il protocollo FTP: impliciti ed espliciti. Mentre il metodo implicito richiede che venga stabilita una Transport Layer Security all'inizio della connessione, che a sua volta interrompe la compatibilità con client e server non compatibili con FTPS, il metodo esplicito utilizza i comandi e le risposte standard del protocollo FTP per aggiornare una connessione da testo normale a una crittografata, consentendo di utilizzare una singola porta di controllo per servire sia client FTPS-aware che FTPS-not-aware. Questo è molto simile al modo in cui HTTPS e STARTTLS implementano il TLS rispettivamente per il protocollo HTTP e SMTP.

Implicito

La negoziazione non è supportata per le configurazioni FTPS implicite. Ci si aspetta che un client comunichi con il server FTPS con un messaggio TLS ClientHello. Se tale messaggio non viene ricevuto dal server FTPS, il server abbandona la connessione.

Per mantenere la compatibilità con i client esistenti che non conoscono FTPS, era previsto che FTPS implicasse l'ascolto sulla porta 990 / TCP IANA per il canale di controllo FTPS e la porta 989 / TCP per il canale di dati FTPS. Ciò consentiva agli amministratori di conservare servizi compatibili con le versioni precedenti sul canale di controllo FTP 21 / TCP.

Si noti che la negoziazione implicita non è stata definita in RFC 4217. Come tale, è considerata un metodo obsoleto e deprecato di negoziazione TLS / SSL per FTP.

Esplicito

Nel metodo esplicito (nota anche come FTPES), un client FTPS deve "richiedere esplicitamente" la sicurezza da un server FTPS e quindi passare a un metodo di crittografia concordato di comune accordo. Se un client non richiede la sicurezza, il server FTPS può consentire al client di continuare in modalità non protetta o rifiutare la connessione.

Il meccanismo per la negoziazione dell'autenticazione e della sicurezza con FTP è stato aggiunto in RFC 2228, che includeva il nuovo comando FTP AUTH. Sebbene questa RFC non definisca esplicitamente alcun meccanismo di sicurezza richiesto, ad esempio SSL o TLS, richiede al client FTPS di contestare il server FTPS con un meccanismo noto. Se il client FTPS comunica con il server FTPS con un meccanismo di sicurezza sconosciuto, il server FTPS risponderà al comando AUTH con il codice di errore 504 (non supportato). I client possono determinare quali meccanismi sono supportati interrogando il server FTPS con il comando FEAT, sebbene i server non debbano necessariamente essere onesti nel rivelare quali livelli di sicurezza supportano. Metodi comuni per invocare la sicurezza FTPS includevano AUTH TLS e AUTH SSL.

Il metodo esplicito è definito in RFC 4217. Nelle versioni successive del documento la conformità FTPS richiedeva che i client negoziassero sempre utilizzando il metodo AUTH TLS.

Transport Layer Security (TLS) / Secure Socket Layer (SSL)

Supporto generale

FTPS include il supporto completo per i protocolli crittografici TLS e SSL, compreso l'uso di certificati di autenticazione della chiave pubblica lato server e certificati di autorizzazione lato client. Supporta anche cifrari compatibili, tra cui AES, RC4, RC2, Triple DES, e DES. Supporta ulteriormente le funzioni hash SHA, MD5, MD4, e MD2.

Scopi dell'utilizzo

In modalità implicita, l'intera sessione FTPS è crittografata. La modalità esplicita differisce dal fatto che il client ha il pieno controllo su quali aree della connessione devono essere crittografate. L'attivazione e la disattivazione della crittografia per il canale di controllo FTPS e il canale dati FTPS possono verificarsi in qualsiasi momento. L'unica restrizione proviene dal server FTPS, che ha la capacità di negare i comandi in base alla politica di crittografia del server.

Secure command channel

La modalità di canale di comando sicuro può essere immessa tramite il prompt dei comandi AUTH TLS o AUTH SSL. Dopo tale periodo, si presume che tutto il controllo di comando tra client e server FTPS sia crittografato. In generale, si consiglia di inserire tale stato prima dell'autenticazione e dell'autorizzazione dell'utente per evitare l'intercettazione di dati di nome utente e password da parte di terzi.

Secure data channel

Il canale dati sicuro può essere inserito attraverso il prompt del comando PROT ma non è abilitato per impostazioni predefinite quando viene emesso il comando AUTH TLS. Dopo tale periodo, si presume che tutte le comunicazioni dei canali di dati tra il client FTPS e il server siano crittografate.

Il client FTPS può uscire dalla modalità canale dati sicuro in qualsiasi momento emettendo un comando CDC (clear data channel).

Motivi per disabilitare la crittografia

Potrebbe non essere vantaggioso utilizzare la crittografia dei canali dati quando si eseguono trasferimenti nei seguenti scenari:

• I file trasferiti sono di natura non sensibile, rendendo inutile la crittografia
• I file trasferiti sono già crittografati a livello di file o stanno passando su una VPN crittografata , rendendo la crittografia ridondante
• Le modalità di crittografia TLS o SSL disponibili non soddisfano il livello di crittografia desiderato. Questo è comune con i client o server FTPS meno recenti che potrebbero essere stati limitati a SSL a 40 bit a causa delle precedenti leggi sull'esportazione con crittografia elevata negli Stati Uniti

Potrebbe non essere vantaggioso utilizzare la crittografia del canale di controllo nei seguenti scenari:

• Utilizzo di FTPS quando il client o il server risiedono dietro un firewall di rete o un dispositivo NAT network address translation
• Uso ripetuto dei comandi AUTH e CCC / CDC da parte di client FTP anonimi all'interno della stessa sessione. Tale comportamento può essere utilizzato come attacco Denial of Service poiché la sessione TLS / SSL deve essere rigenerata ogni volta, utilizzando il tempo del processore del server

Certificati SSL

Proprio come HTTPS, i server FTPS devono fornire un certificato di chiave pubblica. Questi certificati possono essere richiesti e creati utilizzando strumenti come OpenSSL.

Quando questi certificati sono firmati da un'autorità di certificazione attendibile, ciò garantisce che il client sia connesso al server richiesto, evitando un attacco man-in-the-middle. Se il certificato non è firmato da una CA attendibile, il client FTPS potrebbe generare un avviso che indica che il certificato non è valido e può scegliere di accettare quest'ultimo o rifiutare la connessione.

Ciò è in contrasto con il SSH File Transfer Protocol (SFTP), che non presenta certificati firmati ma si basa invece sull'autenticazione Out-of-band delle chiavi pubbliche.

I certificati TLS/SSL possono essere di due tipi: standard e Wildcard. Il primo protegge solo un dominio, mentre il secondo si applica anche ai relativi sottodomini e dà quindi una maggiore sicurezza.

Incompatibilità Firewall

Poiché FTP utilizza una porta secondaria dinamica (per i canali di dati), molti firewall sono stati progettati per interrogare i messaggi di controllo del protocollo FTP al fine di determinare quali connessioni dati secondarie devono consentire. Tuttavia, se la connessione di controllo FTP viene crittografata tramite TLS / SSL, il firewall non può determinare il numero di porta TCP di una connessione dati negoziata tra il client e il server FTP. Pertanto, in molte reti firewall, una distribuzione FTPS fallirà quando funzionerà una distribuzione FTP non crittografata. Questo problema può essere risolto con l'uso di un intervallo specifico di porte per i dati e la configurazione del firewall per l'apertura di queste porte.

Voci correlate

• Secure copy (SCP)
• SSH File Transfer Protocol (SFTP)
• SSH
• Lista di porte standard
• HTTP
• SMTP
• Sistema client/server
• Cifrario

Collegamenti esterni

• Overview of FTPS, and lists of clients, servers, and proxies supporting FTPS
• Curl-loader - an open-source FTPS loading/testing tool