اف‌تی‌پی‌اس

اف‌تی‌پی‌اسبسط یافتهٔ پروتکل انتقال پرونده (FTP)است که امکان پشتیبانی از پروتکل‌های رمزی امنیت لایه انتقال (Tls) ولایه سوکت ایمن (SSL) را نیز فراهم می‌کند.FTPS با FTP ی امن یل عمل تونل زدن FTP از طریق یک اتصال SSH متفاوت است.

پیش زمینه

پروتکل انتفال پرونده در سال ۱۹۷۱ و به منظور استفاده با شبکهٔ عملی و تحقیقی AKPANET طرح شد. که دسترسی به آن از طریق تعداد اندکی از سایت‌های نظامی و دانشگاهها و جامعهٔ کوچکی از از کاربرانی که قادر به عملکرد بدون امنیت اطلاعاتی در داخل پروتکل بودند می‌شد. در سال ۱۹۹۴، کمپانی مرورگر اینترنتی (netscape) یک پوشهٔ لایه کاربردی با عنوان لایه سوکت ایمن را گسترش داده و منتشر کرد. این پروتکل نرم‌افزارها و برنامه‌های کاربردی را قادر می‌ساخت تا در میان یک شبکه و به روشی امن و خصوصی بدون وجود جاسوسی و مداخلات ارتباط برقرار نمایند. درحالی‌که این محصول قابلیت افزودن امنیت به هر پروتکل استفاده کننده از اتصالات قابل اطمینان را داشت اما بیشر به وسیلهٔ نت اسکیپ با HTTP برای شکل‌دهی پروتکل امن انتقال ابرمتن به کار گرفته می‌شد.

روش‌های فراخونی امنیت

دو روش مجرای صریح و ضمنی با هدف فراخوانی امنیت سرویس گیرندگان برای استفاده با سرویس گیرندگان FTP توسعه یافت. روش صریح یک پیاده‌سازی سازگار به جا مانده‌است که در آن سرویس گیرندگان آگاه از FTPS می‌توانند با یک سرور آگاه از FTPS و بدون ایجاد انفصال در عملکرد کلی FTP با سرویس گیرندگان نا آگاه از FTPS، امنیت را فراخوانی نماید.

صریح

در حالت ضمنی یک سرویس گیرنده FTPS می‌بایست به‌طور صریح امنیت را از یک سرویس دهنده FTPS درخواست نماید و سپس به یک روش رمزگذاری توافقی دو جانبه عمل نماید. در صورت عدم درخئاست امنیتی سرویس گیرنده، سرور FTPS می‌تواند اجازهٔ ادامهٔ کار در حالت ناامن را به کاربر داده یا اتصال را نپذیرفته /یا محدود نماید. مکانیزم مذاکرهٔ تصدیق و امنیت با FTP تحت rfc2228 که شامل دستور AUTH جدید FTP می‌باشد اضافه شده‌است. روش‌های متداول فراخوانی امنیت FTPS در برگیرندهٔ AUTH TLS و AUTH SSL می‌باشد.

ضمنی

مذاکره در پیکربندی‌های ضمنی FTPS امکان‌پذیر نیست و انتظار می‌رود که سرویس گیرنده فوراً از طریق یک پیغام (سلام سرویس گیرنده) امنیت لایه انتقال ، سرور FTPS را به چالش بکشد. چنانچه چنین پیغامی توسط سرویس دهندهٔ FTPS دریافت نگردد سرور می‌بایست اتصال را قطع نماید. امنیت لایه انتقال (TLS) /لایه سوکت ایمن(SSL):

حمایت همگانی

FTPS متضمن پشتیبانی کامل برای پروتکل‌های رمزیTLS وSSL و شامل استفاده از گواهینامهٔ تصدیق کلید عمومی و گواهینامه‌های تصدیق سمت سرویس گیرنده می‌باشد. که این قابلت پشتیبانی از توابع درهم SHA ,MD5,MD4,MD2 را نیز دارا می‌باشد.

حوزهٔ کاربرد

در حالت ضمنی، کل نشست FTPS رمزگذاری می‌شود. هر چند که حالت صریح از این لحاظ که سرویس گیرندگان کنترل کاملی بر روی اینکه کدام نواحی اتصال باید رمزگذاری شوند دارند، متفاوت است. فعال سازی یا غیرفعال سازی رمزگذاری برای کانال کنترل FTPSوکانال اطلاعاتی FTPS در هر زمانی می‌تواند رخ دهد.

کانال فرمان ایمن

قابلیت ورود به حالت کانال فرمان ایمن از طریق فرستادن دستورها AUTH TLSوAUTH SSL وجود دارد. پس از این زمان کلیهٔ کنترل بین سرویس دهنده و گیرنده FTPS رمزگذاری شده فرض می‌شود. عموماً توصیه می‌شود که به منظور جلوگیری از سرقت اطلاعات نام کاربری و رمز توسط اشخاص ثالث، پیش از تصدیق کاربر و صدور اجازه برای آن وارد این مرحله شد.

کانال اطلاعاتی ایمن

این کانال از طریق فرستادن دستور PORT وجود دارد. این حالت به‌طور پیش فرض زمانیکه دستور AUTH TLS فرستاده می‌شود فعال نمی‌گردد. پس از این زمان کلیهٔ ارتباطات کانال اطلاعاتی بین سرویس دهنده و گیرنده FTPS رمزگذاری فرض می‌شود. سرویس گیرنده می‌تواند در هر زمانی با فرستادن یک دستور CDC (واضح کردن کانال اطلاعات)به سور از حالت کانال اطلاعاتی امن خارج گردد.

دلایل غیر فعال سازی رمزگذاری

استفاده از رمزگذاری کانال اطلاعاتی در زمان انجام انتقال تحت سناریوهای ذیل ممکن است سودمند نباشد:

1. پرونده‌های منتقل شونده ماهیت غیر حساسی داشته و از این رو ضرورتی برای رمزگذاری بر روی آن احساس نمی‌شود.
2. پرونده‌های منتقل شونده در سطح پرونده رمزگذاری شده‌اند و رمزگذاری مجدد یک کار زائد خواهد بود.
3. حالت‌های رمزگذاری موجود TSL یا SSL

سطح رمزگذاری مطلوب را برآورده نمی‌کنند.

استفاده از رمزگذاری کانال کنترل تحت تحت سناریوهای زیر سودمند به نظر نمی‌رسد

1. استفاده از FTPS زمانی که سرویس گیرنده یا سرویس دهنده پشت یک فایروال شبکه یا دستگاه ترجمهٔ آدرس شبکه مستقر شده‌اند.(بخش ذیل آسب پذیری‌های فایروال را ملاحظه نمایید.)
2. استفاده مکرر از دستورها AUTH وCCC/CDC توسط سرویس گیرندگان FTP ناشناس در یک نشست مشابه.

چنین رفتاری می‌تواند حملهٔ انکار سرویس مبتنی بر منبع به کار گرفته شود.