맨위로가기

FTPS

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

FTPS는 파일 전송 프로토콜(FTP)에 보안을 추가한 프로토콜로, 전송 계층 보안(TLS) 및 보안 소켓 계층(SSL) 암호화를 지원하여 데이터 도청 및 변조를 방지한다. FTPS는 암묵적(Implicit) 방식과 명시적(Explicit) 방식의 두 가지 보안 호출 방식을 제공하며, 명시적 방식은 FTPES로도 불린다. FTPS는 SFTP와 비교하여 ASCII/BINARY 모드 지원 및 폴더 단위 전송의 장점이 있지만, 방화벽과의 호환성 문제가 있을 수 있다. 다양한 클라이언트와 서버에서 FTPS를 지원하며, 보안 명령 채널 및 보안 데이터 채널을 통해 암호화를 제어할 수 있다.

더 읽어볼만한 페이지

  • 네트워크 파일 전송 프로토콜 - 백그라운드 인텔리전트 전송 서비스
    백그라운드 인텔리전트 전송 서비스(BITS)는 유휴 네트워크 대역폭을 활용하여 파일을 비동기적으로 전송하는 윈도우 서비스로, 네트워크 사용량이 적을 때 백그라운드에서 파일을 전송하며 중단된 부분부터 재개할 수 있고, 소프트웨어 업데이트 및 애플리케이션 배포 등에 활용되며, 작업 큐를 통해 전송을 관리하고, 윈도우 비스타 이후 운영체제에서는 `bitsadmin.exe` 명령 줄 유틸리티를 통해 관리가 가능하다.
  • 네트워크 파일 전송 프로토콜 - SSH 파일 전송 프로토콜
    SSH 파일 전송 프로토콜(SFTP)은 SSH를 통해 안전한 파일 전송 및 관리를 제공하며, SCP보다 플랫폼 독립적이고 정부 및 공공기관에서 사용이 권장되는 네트워크 프로토콜이다.
  • 전송 계층 보안 - 공개 키 기반 구조
    공개 키 기반 구조(PKI)는 공개 키 암호화를 기반으로 안전한 통신과 개체 식별을 가능하게 하는 기술로서, 디지털 인증서를 통해 공개 키를 특정 개체에 연결하고 인증서를 관리하며, 인증 기관(CA), 등록 기관(RA) 등 다양한 구성 요소로 이루어져 인증서 발급, 관리, 배포, 사용 및 폐기와 관련된 역할, 정책, 하드웨어, 소프트웨어 및 절차의 집합을 포함한다.
  • 전송 계층 보안 - HTTPS
    HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다.
FTPS
개요
FTPS 프로토콜의 Cryptii 다이어그램
FTPS 프로토콜의 Cryptii 다이어그램
프로토콜 종류파일 전송 프로토콜
목적파일 전송 보안 강화
포트명시적 FTPS의 경우 21번 포트, 암시적 FTPS의 경우 990번 포트를 제어용으로 사용, 989번 포트를 데이터 전송용으로 사용
RFC959 (FTP)
8446 (TLS 1.3)
4217 (명시적 FTPS)
기반 프로토콜FTP, TLS
상세 정보
설명FTP에 보안을 추가하는 확장
관련 프로토콜TLS
SFTP (혼동 주의)
특징암호화된 연결을 통해 사용자 이름, 암호, 파일 콘텐츠 등의 정보를 보호
운용 방식
명시적 (Explicit) FTPS클라이언트가 서버에 보안 연결을 요청하는 방식 (RFC 4217)
암시적 (Implicit) FTPS연결 즉시 TLS 암호화가 시작되는 방식 (더 이상 권장되지 않음)

2. 배경

파일 전송 프로토콜(FTP)은 1971년 아파넷(ARPANET)에서 사용될 목적으로 처음 만들어졌다.[5] 당시에는 아파넷이 소수의 군사 기지와 대학교에서만 사용되었기 때문에, 데이터 보안이나 개인 정보 보호에 대한 필요성이 크지 않았다. 그러나 인터넷이 발전하면서 데이터 도청의 위험성이 커졌고, FTP의 사용자 이름과 비밀번호가 암호화되지 않아 제3자에게 노출될 위험이 있었다. 이러한 문제를 해결하기 위해 FTPS가 제정되었다.

1994년 넷스케이프는 보안 소켓 레이어(SSL)를 개발, 출시하였으며,[6] 1996년 말 RFC 초안이 출판되면서 SSL 프로토콜이 FTP에 적용되었다.[7] 그 직후 IANA 포트가 등록되었으나, RFC는 2005년에야 완성되었다.[8]

2. 1. FTP의 등장과 보안 문제

1971년, 아파넷(ARPANET)에서 사용하기 위해 파일 전송 프로토콜(FTP) 초안이 작성되었다.[5] 초기에는 군사 지역 및 대학교 등 소수의 사용자 커뮤니티에 국한되어 데이터 보안 및 개인 정보 요구 없이 운영되었다. 인터넷이 발전하고 사용자가 증가하면서 데이터 도청 및 변조 위험이 커졌다. FTP 인증 시 전송되는 사용자 이름과 비밀번호는 암호화되지 않은 상태(클리어 텍스트)이므로 제3자에게 도청당할 위험이 있었다.

2. 2. SSL/TLS의 등장과 FTPS 개발

1994년, 인터넷 브라우저 회사인 넷스케이프는 응용 계층 래퍼인 보안 소켓 계층(SSL)을 개발하여 출시했다.[6] 이 프로토콜은 애플리케이션이 네트워크를 통해 비공개적이고 안전한 방식으로 통신하여 도청, 변조 및 메시지 위조를 방지했다. 이는 전송 제어 프로토콜(TCP)과 같이 신뢰할 수 있는 연결을 사용하는 모든 프로토콜에 보안을 추가할 수 있었지만, 넷스케이프에서 HTTPS를 형성하기 위해 HTTP와 함께 가장 일반적으로 사용되었다.

SSL 프로토콜은 결국 파일 전송 프로토콜(FTP)에 적용되었으며, 1996년 말에 초안 의견 요청(RFC)이 발표되었다.[7] 그 직후 공식적인 인터넷 할당 번호 기관(IANA) 포트가 등록되었다. 그러나 RFC는 2005년이 되어서야 최종 확정되었다.[8]

3. 보안 호출 방식

FTPS 클라이언트에서 보안을 호출하는 방식은 암묵적(Implicit) 방식과 명시적(Explicit) 방식 두 가지이다. 암묵적 방식은 연결 시작부터 전송 계층 보안(TLS)을 설정해야 하므로 FTPS를 인식하지 못하는 클라이언트 및 서버와 호환되지 않는다. 반면, 명시적 방식은 표준 FTP 프로토콜 명령과 응답을 사용하여 일반 텍스트 연결을 암호화된 연결로 업그레이드하므로, FTPS를 인식하는 클라이언트와 인식하지 못하는 클라이언트 모두 단일 제어 포트를 통해 지원할 수 있다.

3. 1. 암묵적 (Implicit) 방식

암묵적 FTPS는 협상을 지원하지 않는다. 클라이언트는 즉시 TLS `ClientHello` 메시지로 FTPS 서버에 도전해야 한다. FTPS 서버가 이러한 메시지를 수신하지 못하면 서버는 연결을 끊어야 한다.[3]

기존의 FTPS를 인식하지 못하는 클라이언트와의 호환성을 유지하기 위해, 암묵적 FTPS는 IANA에서 990/TCP(FTPS 제어 채널), 989/TCP(FTPS 데이터 채널)를 잘 알려진 포트로 할당받았다.[3] 이를 통해 관리자는 기존 21/TCP FTP 제어 채널에서 레거시 호환 서비스를 유지할 수 있었다.

암묵적 협상은 RFC 4217에 정의되어 있지 않다. 따라서 FTP에 대한 TLS/SSL 협상의 이전 방식이자 더 이상 사용되지 않는 방식으로 간주된다.[4] FTPS에는 인증 명령(AUTH 명령) 실행 후 암호화 통신을 시작하는 Explicit 모드와 FTPS 서버 접속 시작 시점부터 암호화 통신을 시작하는 Implicit 모드의 두 가지 종류가 있다. Explicit 모드는 FTPES라고도 불린다. 서버의 990/tcp 포트에 접속한 직후에는 SSL 또는 TLS 핸드셰이크가 수행된다.

Implicit 모드로 동작하는 서버에 접속하는 경우, 클라이언트는 서버가 채택하고 있는 암호화 프로토콜에 적합한 FTPS 클라이언트 소프트웨어를 사용할 필요가 있다.

데이터 전송 채널(PORT 또는 PASV 명령으로 생성되는 채널)에서의 통신을 암호화하는 경우, PROT 명령을 사용하여 보호 수준을 P (Private)로 설정해야 한다.

3. 2. 명시적 (Explicit) 방식 (FTPES)

명시적 방식(FTPES)에서 FTPS 클라이언트는 FTPS 서버에 보안을 "명시적으로 요청"한 다음 상호 합의된 암호화 방식으로 전환해야 한다. 클라이언트가 보안을 요청하지 않으면 FTPS 서버는 클라이언트가 안전하지 않은 모드에서 계속 작동하도록 허용하거나 연결을 거부할 수 있다.

FTP를 이용한 인증 및 보안 협상 메커니즘은 RFC 2228에 추가되었으며, 여기에는 새로운 FTP 명령 AUTH가 포함되었다. FTPS 클라이언트가 알 수 없는 보안 메커니즘으로 FTPS 서버에 질문하면 FTPS 서버는 오류 코드 ''504 (지원되지 않음)''으로 AUTH 명령에 응답한다. FTPS 보안을 호출하는 일반적인 방법에는 AUTH TLS 및 AUTH SSL이 포함된다.

명시적 방식은 RFC 4217에 정의되어 있다. FTPS 규정 준수를 위해 클라이언트는 항상 AUTH TLS 방식을 사용하여 협상해야 한다.

FTPS에는 인증 명령(AUTH 명령) 실행 후 암호화 통신을 시작하는 '''Explicit 모드'''와 FTPS 서버 접속 시작 시점부터 암호화 통신을 시작하는 '''Implicit 모드'''의 2가지 종류가 존재한다.[1] 이 Explicit 모드는 특히 FTPES라고도 불린다.[1] 소위 STARTTLS에 해당한다.[2]

서버의 21/tcp 포트에 접속한 후 클라이언트가 AUTH 명령을 실행하여 사용할 프로토콜(SSL 또는 TLS)의 협상을 수행하고, 적합한 프로토콜로 핸드셰이크가 완료된 후 암호화된 통신이 이루어진다.[2] 즉, Explicit 모드의 경우, 클라이언트가 AUTH 명령을 실행하지 않으면 일반 FTP로 기능한다.[2]

4. TLS/SSL

FTPS는 전송 계층 보안(TLS) 및 보안 소켓 계층(SSL) 암호화 프로토콜을 사용하여 통신을 보호한다.

서버 측 공개 키 인증서와 클라이언트 측 인증서를 모두 지원하며, 고급 암호화 표준(AES), RC4, RC2, 트리플 DES, 데이터 암호화 표준(DES) 등 다양한 암호와 SHA 계열, MD5, MD4, MD2 등의 해시 함수를 지원한다.

FTPS는 명시적 모드를 통해 클라이언트가 연결의 암호화 영역을 제어할 수 있다. FTPS 제어 채널과 데이터 채널의 암호화는 언제든지 활성화 및 비활성화할 수 있지만, 서버의 암호화 정책에 따라 명령이 거부될 수 있다.[1]

4. 1. 일반 지원

서버 측 공개 키 인증서 및 클라이언트 측 인증서를 포함하여 TLS 및 SSL 암호화 프로토콜에 대한 전체 지원을 제공한다. 고급 암호화 표준(AES), RC4, RC2, 트리플 DES, 데이터 암호화 표준(DES) 등 다양한 암호를 지원한다. SHA 계열, MD5, MD4, MD2 등 해시 함수를 지원한다.

4. 2. 사용 범위

명시적 모드에서는 클라이언트가 연결의 어떤 영역을 암호화할지 제어할 수 있다. FTPS 제어 채널 및 데이터 채널에 대한 암호화 활성화 및 비활성화는 언제든지 할 수 있다. 단, FTPS 서버에 서버 암호화 정책에 따라 명령을 거부할 수 있는 기능이 있으므로 제약이 있을 수 있다.[1]

4. 2. 1. 보안 명령 채널

보안 명령 채널 모드는 `AUTH TLS` 또는 `AUTH SSL` 명령을 실행하여 진입할 수 있다. 이후 FTPS 클라이언트와 서버 간의 모든 명령 제어는 암호화된 것으로 간주된다. 제3자에 의한 사용자 이름 및 비밀번호 데이터 도청을 방지하기 위해 일반적으로 사용자 인증 및 권한 부여 전에 이러한 상태로 진입하는 것이 좋다.[1]

FTP 인증 시 전송되는 사용자 이름과 비밀번호는 암호화되지 않은 상태(클리어 텍스트)이므로 제3자에게 도청 및 침입당할 위험이 있다. FTPS는 이러한 위험을 회피하기 위해 제정되었다.[1] 소위 STARTTLS에 해당한다.[1]

서버의 21/tcp 포트에 접속한 후 클라이언트가 AUTH 명령을 실행하여 사용할 프로토콜(SSL 또는 TLS)의 협상을 수행하고, 적합한 프로토콜로 핸드셰이크가 완료된 후 암호화된 통신이 이루어진다. 즉, Explicit 모드의 경우, 클라이언트가 AUTH 명령을 실행하지 않으면 일반 FTP로 기능한다.[1]

4. 2. 2. 보안 데이터 채널

보안 데이터 채널은 `PROT` 명령어를 통해 진입할 수 있다. `AUTH TLS` 명령어 실행 시에는 기본적으로 활성화되지 ''않는다''.[1] 이 시점 이후, FTPS 클라이언트와 서버 간의 모든 데이터 채널 통신은 암호화된 것으로 간주된다.[1]

FTPS 클라이언트는 `CDC` (clear data channel, 데이터 채널 해제) 명령어를 실행하여 언제든지 보안 데이터 채널 모드를 종료할 수 있다.[1]

4. 2. 3. 암호화 비활성화 이유

다음과 같은 경우 데이터 채널 암호화를 사용하지 않는 것이 유리하다.

  • 전송되는 파일이 민감하지 않아 암호화가 불필요한 경우.
  • 전송되는 파일이 이미 파일 수준에서 암호화되었거나, 암호화된 VPN을 통해 전송되어 암호화가 중복되는 경우.
  • 사용 가능한 TLS 또는 SSL 암호화 모드가 원하는 암호화 수준을 충족하지 못하는 경우. 이는 이전 미국의 고강도 암호화 수출법으로 인해 40비트 SSL로 제한되었을 수 있는 오래된 FTPS 클라이언트 또는 서버에서 흔히 발생한다.


다음과 같은 상황에서는 제어 채널 암호화를 사용하지 않는 것이 유리하다.

  • 클라이언트 또는 서버가 네트워크 방화벽 또는 네트워크 주소 변환 (NAT) 장치 뒤에 있는 경우 FTPS를 사용하는 경우. ( 방화벽 비호환성 참조).
  • 동일한 세션 내에서 익명 FTP 클라이언트가 AUTH 및 CCC/CDC 명령을 반복적으로 사용하는 경우. 이러한 동작은 TLS/SSL 세션을 매번 재생성해야 하고 서버 프로세서 시간을 사용해야 하므로 리소스 기반 서비스 거부 공격으로 사용될 수 있다.

4. 3. SSL 인증서

FTPS 서버는 공개 키 인증서를 제공해야 한다. 이러한 인증서는 OpenSSL과 같은 도구를 사용하여 요청하고 생성할 수 있다.

이러한 인증서가 신뢰할 수 있는 인증 기관(CA)에 의해 서명되면, 클라이언트가 요청된 서버에 연결되었음을 보장하여 중간자 공격을 방지한다. 인증서가 신뢰할 수 있는 CA (자가 서명 인증서)에 의해 서명되지 않은 경우 FTPS 클라이언트는 인증서가 유효하지 않다는 경고를 생성할 수 있다. 클라이언트는 인증서를 수락하거나 연결을 거부하도록 선택할 수 있다.

5. SFTP와의 비교

FTPS는 SFTP와 비교하여 ASCII/BINARY 모드 및 폴더 단위 전송을 지원한다. 서버 운영 시 SSL 인증서 구매 비용이 발생하지만, 와일드카드 인증서를 등록하면 자사 SSL 사이트(HTTPS)와 공통 인증서를 사용할 수 있어 비용을 절감할 수 있다.[1]

5. 1. 장점

FTPS는 SFTP와 비교하여 ASCII/BINARY 모드를 지원하고 폴더 단위 전송이 가능하다는 장점이 있다. 서버 운영 측면에서는 SSL 인증서 구매 비용이 발생하지만, 와일드카드 인증서를 등록하면 자사 SSL 사이트(HTTPS)와 공통 인증서를 사용할 수 있어 비용을 절감할 수 있다.

5. 2. 단점

서버 운영 측에서 SSL 인증서 구매 비용이 든다는 단점이 있지만, 와일드카드 인증서로 등록하면 자사 SSL 사이트(HTTPS)와 공통 인증서를 이용할 수 있어 비용 문제를 완화할 수 있다.

6. 방화벽 비호환성

FTP는 동적 보조 포트(데이터 채널용)를 사용하기 때문에, 많은 방화벽은 FTP 프로토콜 제어 메시지를 감시하여 허용해야 하는 보조 데이터 연결을 결정하도록 설계되었다. 그러나 TLS/SSL을 사용하여 FTP 제어 연결이 암호화된 경우, 방화벽은 클라이언트와 FTP 서버 간에 협상된 데이터 연결의 TCP 포트 번호를 결정할 수 없다. 따라서 많은 방화벽 네트워크에서 암호화되지 않은 FTP 배포가 작동하는 경우 FTPS 배포는 실패한다. 이 문제는 데이터에 대한 제한된 범위의 포트를 사용하고 방화벽이 이러한 포트를 열도록 구성하여 해결할 수 있다.

7. FTPS 지원 애플리케이션

FTPS를 지원하는 애플리케이션은 다음과 같다.

클라이언트서버


7. 1. 지원 클라이언트


  • 코어 FTP
  • 큐트 FTP
  • 사이버덕
  • FFFTP
  • FileZilla
  • 파이어 FTP (파이어폭스 부가 기능)
  • 플래시FXP
  • FTP 보이저
  • gFTP
  • lftp
  • 넥스트 FTP
  • 시큐어 FTP
  • 스마트FTP
  • 얼티메이트 FTP
  • 윈SCP

7. 2. 지원 서버


  • 아파치 FTP 서버
  • Bftpd
  • 세르베루스 FTP 서버
  • 크로스FTP 서버
  • DrFTPD
  • edtFTPD
  • FileZilla Server
  • Independent FTP 데몬
  • ProFTPD
  • 퓨어-FTPd
  • vsftpd
  • War FTP 데몬
  • 인터넷 정보 서비스(IIS, IIS7 이후)

참조

[1] 웹사이트 The SSL 0.2 Protocol https://www.mozilla.[...] 1995-02-09
[2] 간행물 Secure FTP Over SSL 1996-11-26
[3] 웹사이트 Service Name and Transport Protocol Port Number Registry https://www.iana.org[...] 2015-10-09
[4] 간행물 Securing FTP with TLS 2001-04-05
[5] 문서 RFC-265: File Transfer Protocol (FTP) http://tools.ietf.or[...]
[6] 문서 The SSL Protocol, Feb. 9th, 1995 http://www.mozilla.o[...] 1995-02-09
[7] 문서 RFC draft, Secure FTP Over SSL, revision 1996-11-26 http://tools.ietf.or[...] 1996-11-26
[8] 문서 RFC-4217: Securing FTP with TLS


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com