FTPS - FTPS

FTPS (även känd FTP-SSL och FTP Secure ) är ett tillägg till det vanliga File Transfer Protocol (FTP) som lägger till stöd för Transport Layer Security (TLS) och tidigare Secure Sockets Layer (SSL, som nu är förbjudet enligt RFC7568 ) kryptografiska protokoll.

FTPS bör inte förväxlas med SSH File Transfer Protocol (SFTP), ett säkert filöverföringsundersystem för Secure Shell (SSH) -protokollet som det inte är kompatibelt med. Det skiljer sig också från FTP över SSH , vilket är praxis för att tunnla FTP genom en SSH -anslutning.

Bakgrund

File Transfer Protocol utarbetades 1971 för användning med det vetenskapliga och forskningsnätverket ARPANET . Tillgången till ARPANET under denna tid var begränsad till ett litet antal militära platser och universitet och en smal grupp användare som kunde fungera utan datasäkerhet och sekretesskrav inom protokollet.

När ARPANET gav vika för NSFnet och sedan Internet , hade en bredare befolkning potentiellt tillgång till data eftersom den gick igenom allt längre vägar från klient till server. Möjligheten för obehöriga tredje parter att avlyssna dataöverföringar ökade proportionellt.

År 1994 webbläsaren företaget Netscape utvecklat och släppt applikationslagret omslag, Secure Sockets Layer . Detta protokoll gjorde det möjligt för applikationer att kommunicera över ett nätverk på ett privat och säkert sätt, vilket avskräcker avlyssning, manipulering och förfalskning av meddelanden. Även om det kan lägga till säkerhet för alla protokoll som använder tillförlitliga anslutningar, till exempel TCP , användes det oftast av Netscape med HTTP för att bilda HTTPS.

SSL -protokollet tillämpades så småningom på FTP, med ett utkast till Request for Comments (RFC) publicerat i slutet av 1996. En officiell IANA -port registrerades kort därefter. RFC slutfördes dock inte förrän 2005.

Metoder för att åberopa säkerhet

Två separata metoder utvecklades för att åberopa klientsäkerhet för användning med FTP -klienter: Implicit och Explicit . Även om den implicita metoden kräver att en transportlagersäkerhet upprättas från början av anslutningen, vilket i sin tur bryter kompatibiliteten med icke-FTPS-medvetna klienter och servrar, använder den uttryckliga metoden vanliga FTP-protokollkommandon och svar för att uppgradera en vanlig textanslutning till en krypterad, så att en enda kontrollport kan användas för att betjäna både FTPS-medvetna och icke-FTPS-medvetna klienter.

Implicit

Förhandling stöds inte med implicita FTPS -konfigurationer. En klient förväntas omedelbart utmana FTPS -servern med ett TLS ClientHello -meddelande. Om ett sådant meddelande inte tas emot av FTPS -servern bör servern avbryta anslutningen.

För att upprätthålla kompatibilitet med befintliga icke-FTPS-medvetna klienter förväntades implicit FTPS att lyssna på IANA: s välkända port 990/TCP för FTPS-kontrollkanalen och port 989/TCP för FTPS-datakanalen. Detta gjorde det möjligt för administratörer att behålla äldre kompatibla tjänster på den ursprungliga 21/TCP FTP-kontrollkanalen.

Observera att implicit förhandling inte definierades i RFC 4217. Som sådan anses det vara en tidigare, utfasad metod att förhandla om TLS/SSL för FTP.

Explicit

I explicit läge (även känt som FTPES) måste en FTPS -klient "uttryckligen begära" säkerhet från en FTPS -server och sedan gå vidare till en ömsesidigt överenskommen krypteringsmetod. Om en klient inte begär säkerhet kan FTPS -servern antingen tillåta klienten att fortsätta i osäkert läge eller vägra anslutningen.

Mekanismen för att förhandla om autentisering och säkerhet med FTP lades till under RFC 2228, som inkluderade det nya FTP -kommandot AUTH. Även om denna RFC inte uttryckligen definierar några nödvändiga säkerhetsmekanismer, t.ex. SSL eller TLS, krävs det att FTPS -klienten utmanar FTPS -servern med en ömsesidigt känd mekanism. Om FTPS -klienten utmanar FTPS -servern med en okänd säkerhetsmekanism svarar FTPS -servern på AUTH -kommandot med felkod 504 (stöds inte) . Kunder kan bestämma vilka mekanismer som stöds genom att fråga FTPS -servern med FEAT -kommandot, även om servrar inte nödvändigtvis krävs för att vara ärliga för att avslöja vilka säkerhetsnivåer de stöder. Vanliga metoder för att åberopa FTPS -säkerhet inkluderar AUTH TLS och AUTH SSL.

Den uttryckliga metoden definieras i RFC 4217. I de senare versionerna av dokumentet krävde FTPS -efterlevnad att klienter alltid förhandlar med AUTH TLS -metoden.

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

Allmänt stöd

FTPS inkluderar fullt stöd för TLS- och SSL-kryptografiska protokoll, inklusive användning av autentiseringscertifikat på serversidan och autentiseringscertifikat på klientsidan. Den stöder också kompatibla chiffer, inklusive AES , RC4 , RC2 , Triple DES och DES . Den stöder vidare hashfunktionerna SHA , MD5 , MD4 och MD2 .

Användningsområde

I implicit läge är hela FTPS -sessionen krypterad. Explicit läge skiljer sig genom att klienten har full kontroll över vilka delar av anslutningen som ska krypteras. Aktivering och inaktivering av kryptering för FTPS -kontrollkanalen och FTPS -datakanalen kan ske när som helst. Den enda begränsningen kommer från FTPS -servern, som har förmågan att neka kommandon baserat på serverkrypteringspolicy.

Säker kommandokanal

Det säkra kommandokanalläget kan anges genom antingen AUTH TLS- eller AUTH SSL -kommandon. Efter en sådan tid antas all kommandokontroll mellan FTPS -klienten och servern vara krypterad. Det rekommenderas generellt att ange ett sådant tillstånd före användarautentisering och auktorisering för att undvika avlyssning av användarnamn och lösenordsdata från tredje part.

Säker datakanal

Den säkra datakanalen kan anges genom kommandot PROT. Det är inte aktiverat som standard när AUTH TLS -kommandot utfärdas. Efter en sådan tid antas all datakanalkommunikation mellan FTPS -klienten och servern vara krypterad.

FTPS -klienten kan när som helst lämna det säkra datakanalläget genom att utfärda ett CDC -kommando (clear data channel).

Anledningar att inaktivera kryptering

Det kanske inte är fördelaktigt att använda datakanalskryptering när överföringar utförs i följande scenarier:

• Filer som överförs är av icke-känslig karaktär, vilket gör kryptering onödig,
• Filer som överförs är redan krypterade på filnivå eller passerar över en krypterad VPN , vilket gör kryptering överflödig,
• Tillgängliga TLS- eller SSL -krypteringslägen uppfyller inte önskad krypteringsnivå. Detta är vanligt med äldre FTPS-klienter eller servrar som kan ha begränsats till 40-bitars SSL på grund av tidigare USA: s högkrypteringsexportlagar.

Det kanske inte är fördelaktigt att använda kontrollkanalkryptering under följande scenarier:

• Användning av FTPS när klienten eller servern ligger bakom en nätverksbrandvägg eller nätverksadressöversättning (NAT). (Se brandväggens inkompatibilitet nedan.)
• Upprepad användning av AUTH- och CCC/CDC -kommandon av anonyma FTP -klienter inom samma session. Sådant beteende kan användas som en resursbaserad denial of service-attack eftersom TLS/SSL-sessionen måste återskapas varje gång med hjälp av serverprocessortid.

SSL -certifikat

Ungefär som HTTPS måste FTPS -servrar tillhandahålla ett offentligt nyckelcertifikat . Dessa certifikat kan begäras och skapas med hjälp av verktyg som OpenSSL .

När dessa certifikat är signerade av en pålitlig certifikatutfärdare ger detta försäkran om att klienten är ansluten till den begärda servern, vilket undviker en man-in-the-middle-attack . Om certifikatet inte är signerat av en betrodd CA (ett självsignerat certifikat ) kan FTPS-klienten generera en varning om att certifikatet inte är giltigt. Klienten kan välja att acceptera certifikatet eller avvisa anslutningen.

Detta står i kontrast till SSH File Transfer Protocol (SFTP), som inte presenterar signerade certifikat, utan istället förlitar sig på out-of-band-autentisering av offentliga nycklar.

Brandväggens inkompatibilitet

Eftersom FTP använder en dynamisk sekundärport (för datakanaler) har många brandväggar utformats för att snoka FTP -protokollets kontrollmeddelanden för att avgöra vilka sekundära dataförbindelser de behöver tillåta. Men om FTP -kontrollanslutningen är krypterad med TLS/SSL kan brandväggen inte bestämma TCP -portnumret för en dataanslutning som förhandlas fram mellan klienten och FTP -servern. Därför misslyckas en FTPS -distribution i många brandväggsnätverk när en okrypterad FTP -distribution fungerar. Detta problem kan lösas med hjälp av ett begränsat antal portar för data och konfigurering av brandväggen för att öppna dessa portar.

Se även

Anteckningar

externa länkar

• Översikt över FTPS och listor över klienter, servrar
• Curl-loader- ett FTPS-lastnings-/testverktyg med öppen källkod