FTPS

TLS를 통한 파일 전송 프로토콜

통신 프로토콜
목적	파일 전송
에 기반을 둔	FTP, TLS
포트	암묵적 FTPS의 경우 제어용 990, 데이터 전송용 989
RFC	RFC 959(FTP), RFC 8446(TLS 1.3), RFC 4217(명시 FTPS)

FTPS(FTP-SSL 및 FTP Secure라고도 함)는 일반적으로 사용되는 File Transfer Protocol(FTP)의 확장으로 Transport Layer Security(TLS; 트랜스포트층 보안) 및 이전에는 Secure Sockets Layer(SSL; RFC 7568에서 금지되어 있음)의 지원을 추가합니다.

FTPS는 SSH(Secure Shell) 프로토콜의 안전한 파일 전송 서브시스템인 SSH File Transfer Protocol(SFTP)과 혼동하지 마십시오.SFTP는 호환성이 없습니다.또, SSH 접속을 개입시켜 FTP 를 터널링 하는 프랙티스인 FTP over SSH 와도 다릅니다.

배경

파일 전송 프로토콜은 1971년 과학 및 연구 네트워크인 ARPANET과 ^[1]함께 사용하기 위해 초안되었습니다.이 기간 동안 ARPANET에 대한 액세스는 프로토콜 내에서 데이터 보안 및 개인 정보 보호 요구사항 없이 작동할 수 있는 소수의 군사 사이트와 대학 및 좁은 사용자 커뮤니티로 제한되었다.

ARPANET이 NSFNET에 이어 인터넷에 자리를 내줌에 따라 클라이언트에서 서버로 점점 더 긴 경로를 이동함에 따라 더 많은 사람들이 데이터에 액세스할 수 있게 되었습니다.승인되지 않은 제삼자가 데이터 전송을 도청할 기회는 그에 비례하여 증가했습니다.

1994년 인터넷 브라우저 회사인 Netscape는 애플리케이션 계층 래퍼인 Secure Sockets ^[2]Layer를 개발하여 출시했습니다.이 프로토콜을 통해 애플리케이션은 개인적이고 안전한 방식으로 네트워크를 통해 통신할 수 있으므로 도청, 변조 및 메시지 위조를 방지할 수 있습니다.TCP와 같이 신뢰할 수 있는 연결을 사용하는 프로토콜에 보안을 추가할 수 있지만, Netscape가 HTTPS를 형성하기 위해 HTTP와 함께 가장 일반적으로 사용되었습니다.

SSL 프로토콜은 결국 FTP에 적용되었고 1996년 ^[3]말에 초안 RFC가 발행되었습니다.그 직후 공식 IANA 포트가 등록되었습니다.그러나 RFC는 2005년까지 ^[4]확정되지 않았습니다.

보안을 호출하는 방법

FTP 클라이언트에서 사용하기 위해 클라이언트보안을 호출하기 위해 다음 두 가지 방법이 개발되었습니다.암묵적 및 명시적.암묵적인 방식으로는 접속 시작부터 트랜스포트층 보안이 확립되어 있어야 합니다.이것에 의해, 비FTPS 대응 클라이언트 및 서버와의 호환성이 깨집니다만, 명시적인 방식에서는, 플레인 텍스트 접속을 암호화된 것으로 업그레이드하기 위해서, 표준 FTP 프로토콜명령어와 응답이 사용됩니다.이것에 의해, 싱글이 가능하게 됩니다.FTPS 인식 클라이언트와 비 FTPS 인식 클라이언트의 양쪽 모두에 사용되는 제어 포트.

암묵적

암묵적인 FTPS 설정에서는 네고시에이션은 지원되지 않습니다.클라이언트는 즉시 TLS ClientHello 메시지를 사용하여 FTPS 서버에 도전합니다.FTPS 서버가 이러한 메시지를 수신하지 않으면 서버는 연결을 끊어야 합니다.

기존 비FTPS 인식 클라이언트와의 호환성을 유지하기 위해 암묵적인 FTPS는 FTPS 제어채널의 ^[5]경우 IANA의 well-known 포트 990/TCP, FTPS 데이터 채널의 경우 포트 989/TCP에서 리슨해야 합니다.이것에 의해, 관리자는 원래의 21/TCP FTP 제어 채널에 레거시 호환 서비스를 유지할 수 있게 되었습니다.

암묵적인 네고시에이션은 RFC 4217에 정의되어 있지 않습니다.따라서 ^[6]이 방법은 FTP용 TLS/SSL을 네고시에이트하기 위한 더 이전의 권장되지 않는 방법으로 간주됩니다.

명시적

명시 모드(FTPES라고도 함)에서는 FTPS 클라이언트는 FTPS 서버에 보안을 명시적으로 요구한 후 상호 합의된 암호화 방식을 따라야 합니다.클라이언트가 보안을 요구하지 않는 경우 FTPS 서버는 클라이언트의 보안 보호 모드를 계속 허용하거나 연결을 거부할 수 있습니다.

인증과 보안을 FTP와 네고시에이트하기 위한 메커니즘은 새로운 FTP 명령 AUTH를 포함한 RFC 2228에 추가되었습니다.이 RFC에서는 SSL이나 TLS 등 필요한 보안 메커니즘을 명시적으로 정의하지 않지만 FTPS 클라이언트가 서로 알려진 메커니즘으로 FTPS 서버에 도전해야 합니다.FTPS 클라이언트가 알 수 없는 보안 메커니즘으로 FTPS 서버에 도전하는 경우 FTPS 서버는 AUTH 명령에 오류 코드 504(지원되지 않음)로 응답합니다.클라이언트는 FEAT 명령어를 사용하여 FTPS 서버에 문의함으로써 지원되는 메커니즘을 결정할 수 있습니다.다만, 서버가 서포트되고 있는 시큐러티 레벨을 정직하게 공개할 필요는 없습니다.FTPS 보안을 호출하는 일반적인 방법에는 AUTH TLS와 AUTH SSL이 있습니다.

명시적 방식은 RFC 4217에 정의되어 있습니다.문서의 최신 버전에서는 FTPS 컴플라이언스를 위해 클라이언트는 항상 AUTH TLS 방식을 사용하여 네고시에이트해야 합니다.

트랜스포트층 보안(TLS)/시큐어 소켓층(SSL)

일반 지원

FTPS에는 서버 측 공개 키 인증 인증서 및 클라이언트 측 인증 인증서 사용을 포함하여 TLS 및 SSL 암호화 프로토콜에 대한 완전한 지원이 포함됩니다.또한 AES, RC4, RC2, Triple DES 및 DES 등의 호환 가능한 암호도 지원합니다.또한 해시 함수 SHA, MD5, MD4 및 MD2를 지원합니다.

사용범위

암묵 모드에서는 FTPS 세션 전체가 암호화됩니다.명시적 모드는 클라이언트가 암호화되는 접속 영역을 완전히 제어할 수 있다는 점에서 다릅니다.FTPS 컨트롤 채널 및 FTPS 데이터 채널의 암호화를 언제든지 활성화 또는 비활성화할 수 있습니다.유일한 제한은 서버 암호화 정책에 따라 명령을 거부하는 기능을 가진 FTPS 서버에서 발생합니다.

안전한 명령어 채널

시큐어 명령어채널 모드는 AUTH TLS 또는 AUTH SSL 명령어 중 하나를 발행하여 시작할 수 있습니다.이 시간이 지나면 FTPS 클라이언트와 서버 간의 모든 명령어컨트롤은 암호화되는 것으로 간주됩니다.일반적으로 사용자 이름과 비밀번호 데이터가 제삼자에 의해 도청되지 않도록 사용자 인증 및 인가 전에 이러한 상태를 시작하는 것이 좋습니다.

안전한 데이터 채널

보안 데이터 채널은 PROT 명령을 발행하여 입력할 수 있습니다.AUTH TLS 명령어 발행 시 디폴트로는 이니블이 되지 않습니다.이 시간이 지나면 FTPS 클라이언트와 서버 간의 모든 데이터 채널 통신은 암호화되는 것으로 간주됩니다.

FTPS 클라이언트는 CDC(clear data channel) 명령어를 발행하여 언제든지 시큐어 데이터 채널모드를 종료할 수 있습니다.

암호화를 비활성화해야 하는 이유

다음과 같은 시나리오에서 전송을 수행할 때는 데이터 채널 암호화를 사용하는 것이 유리하지 않을 수 있습니다.

• 전송되는 파일은 중요하지 않기 때문에 암호화가 불필요합니다.
• 전송되는 파일은 이미 파일레벨로 암호화되어 있거나 암호화된 VPN을 통과하고 있기 때문에 암호화가 용장화되어 있습니다.
• 사용 가능한 TLS 또는 SSL 암호화 모드가 원하는 암호화 수준을 충족하지 않습니다.이는 이전 미국의 고암호화 수출법에 의해 40비트 SSL로 제한되었던 오래된 FTPS 클라이언트 또는 서버에서 공통적으로 발생합니다.

다음과 같은 시나리오에서는 제어채널 암호화를 사용하는 것이 바람직하지 않을 수 있습니다.

• 클라이언트 또는 서버가 네트워크방화벽 또는 Network Address Translation(NAT; 네트워크주소 변환) 디바이스의 배후에 있는 경우의 FTPS 사용.(아래 방화벽 비호환성 참조).
• 같은 세션 내의 익명 FTP 클라이언트에 의한 AUTH 및 CCC/CDC 명령어 반복 사용.이러한 동작은 서버 프로세서 시간을 사용하여 매번 TLS/SSL 세션을 재생성해야 하므로 리소스 기반 서비스 거부 공격으로 사용할 수 있습니다.

SSL 증명서

HTTPS와 마찬가지로 FTPS 서버는 공개 키 증명서를 제공해야 합니다.이러한 인증서는 OpenSSL 등의 도구를 사용하여 요청 및 생성할 수 있습니다.

이러한 증명서가 신뢰할 수 있는 인증국에 의해 서명되면 클라이언트가 요청된 서버에 연결되어 있음을 보증하고 중간자 공격을 피할 수 있습니다.증명서가 신뢰할 수 있는 CA(자기서명증명서)에 의해 서명되지 않은 경우 FTPS 클라이언트는 증명서가 유효하지 않음을 나타내는 경고를 생성할 수 있습니다.클라이언트는 증명서를 받아들일지 접속을 거부할지를 선택할 수 있습니다.

이는 SSH File Transfer Protocol(SFTP)과는 대조적으로 서명된 증명서는 제시하지 않고 공용 키의 대역 외 인증에 의존합니다.

방화벽 비호환성

FTP는 동적 세컨더리 포트(데이터 채널용)를 사용하기 때문에 많은 방화벽은 FTP 프로토콜 제어 메시지를 스누핑하여 허용해야 하는 세컨더리 데이터 연결을 결정합니다.그러나 FTP 제어 연결이 TLS/SSL을 사용하여 암호화되어 있는 경우 방화벽은 클라이언트와 FTP 서버 간에 네고시에이트된 데이터 연결의 TCP 포트 번호를 확인할 수 없습니다.따라서 많은 방화벽네트워크에서는 암호화되지 않은FTP 전개가 동작할 때 FTPS 전개가 실패합니다.이 문제는 한정된 범위의 포트를 사용하여 이러한 포트를 열도록 방화벽을 설정하면 해결할 수 있습니다.

「 」를 참조해 주세요.

메모들

외부 링크

• FTPS의 개요 및 클라이언트, 서버 목록
• 컬 로더 - 오픈 소스 FTPS 로딩/테스트 도구