원문 보기: https://dawoum.duckdns.org/wiki/FTPS
FTPS (역시 FTP-SSL 및 FTP Secure로 알려져 있음)는 공통적으로 사용되는 파일 전송 프로토콜 (FTP)에 대한 확장으로, 전송 계층 보안 (TLS) 및 이전의 보안 소켓 계층 (SSL, 현재 RFC7568에 의해 금지됨) 암호화 프로토콜에 대한 지원이 추가되었습니다.
FTPS는 호환되지 않는 보안 쉘 (SSH) 프로토콜을 위한 보안 파일 전송 하위-시스템, SSH 파일 전송 프로토콜 (SFTP)과 혼동되어서는 안 됩니다. 그것은 역시 SSH 연결을 통해 FTP를 터널링의 관행인 FTP over SSH와도 다릅니다.
Background
파일 전송 프로토콜은 1971년에 과학 및 연구 네트워크, ARPANET과 함께 사용하도록 초안으로 작성되었습니다. 이 기간 동안 ARPANET에 대한 접근은 소수의 군사 기지와 대학, 프로토콜 내에서 데이터 보안 및 개인 정보 보호 요구 사항 없이 작업할 수 있는 소수의 사용자 커뮤니티로 제한되었습니다.
ARPANET이 NSFNET으로 옮겨가고, 그 뒤에 인터넷으로 자리를 내주면서, 더 많은 사람들이 클라이언트에서 서버로 가는 경로가 점점 더 길어지면서 데이터에 접근할 수 있는 가능성이 생겼습니다. 허가받지 않은 제3자가 데이터 전송을 도청할 수 있는 기회도 비례적으로 증가했습니다.
1994년, 인터넷 브라우저 회사 넷스케이프는 응용 계층 래퍼, 보안 소켓 계층을 개발하여 출시했습니다. 이 프로토콜은 응용 프로그램에게 네트워크를 통해 비공개적이고 안전하게 통신할 수 있도록 활성화하여, 도청, 변조, 및 메시지 위조를 방지했습니다. 그것은 TCP와 같이 안정적인 연결을 사용하는 임의의 프로토콜에 보안을 추가할 수 있지만, 넷스케이프에 의해 HTTP와 함께 HTTPS를 형성하기 위해 가장 공통적으로 사용되었습니다.
SSL 프로토콜은 결국 FTP에 적용되었으며, 1996년 후반에 초안 Request for Comments (RFC)가 공개되었습니다. 그 직후에 공식 IANA 포트가 등록되었습니다. 어쨌든, RFC는 2005년까지 완료되지 않았습니다.
Methods of invoking security
FTP 클라이언트에서 클라이언트 보안을 호출하기 위해 두 가지 별도의 방법: 암시적 방법과 명시적 방법이 개발되었습니다. 암시적 방법은 전송 계층 보안이 연결 시작부터 설정함을 요구하며, 이는 비-FTPS-인식 클라이언트 및 서버와의 호환성을 깨뜨리고, 반면에 명시적 방법은 표준 FTP 프로토콜 명령과 응답을 일반 텍스트 연결을 암호화된 연결로 업그레이드하기 위해 사용하여, FTPS-인식 클라이언트와 비-FTPS-인식 클라이언트를 모두 서비스하는 데 단일 제어 포트를 허용합니다.
Implicit
협상이 암시적 FTPS 구성에서 지원되지 않습니다. 클라이언트는 즉시 TLS ClientHello 메시지로 FTPS 서버에 도전해야 합니다. 만약 그러한 메시지가 FTPS 서버에 의해 수신되지 않으면, 서버는 연결을 끊어야 합니다.
기존의 비-FTPS-인식 클라이언트와의 호환성을 유지하기 위해, 암시적 FTPS는 FTPS 제어 채널에 대해 IANA의 잘 알려진 포트 990/TCP에서, 그리고 FTPS 데이터 채널에 대해 포트 989/TCP에서 수신하도록 예상되었습니다. 이것은 관리자에게 원래 21/TCP FTP 제어 채널에서 레거시-호환 서비스를 유지하도록 허용했습니다.
암시적 협상은 RFC 4217에 정의되지 않았다는 점에 주목하십시오. 이를테면, 그것은 FTP를 위한 TLS/SSL 협상의 더 이른 시기의 더 이상 사용되지 않는 방법으로 고려됩니다.
Explicit
명시적 모드 (FTPES라고도 알려져 있음)에서, FTPS 클라이언트는 FTPS 서버에서 보안을 "명시적으로 요청"해야 하고 그런-다음 상호 합의된 암호화 방법으로 전환해야 합니다. 만약 클라이언트가 보안을 요청하지 않으면, FTPS 서버는 클라이언트가 안전하지 않은 모드를 계속하도록 허용하거나 연결을 거부할 수 있습니다.
FTP와 인증 및 보안을 협상하는 메커니즘은 새로운 FTP 명령 AUTH를 포함하는 RFC 2228 아래에서 추가되었습니다. 이 RFC는 예를 들어, SSL이나 TLS와 같은 임의의 필수 보안 메커니즘을 명시적으로 정의하지 않지만, FTPS 클라이언트에게 서로 알려진 메커니즘으로 FTPS 서버에 도전하도록 요구합니다. 만약 FTPS 클라이언트가 알 수 없는 보안 메커니즘으로 FTPS 서버에 도전하면, FTPS 서버는 오류 코드 504 (지원되지 않음)로 AUTH 명령에 응답할 것입니다. 클라이언트는 FEAT 명령으로 FTPS 서버에 질의함으로써 어떤 메커니즘이 지원되는지 확인할 수 있지만, 서버는 반드시 그것들이 지원하는 보안 수준을 공개할 필요는 없습니다. FTPS 보안을 호출하는 공통적인 방법에는 AUTH TLS 및 AUTH SSL이 있습니다.
명시적 방법은 RFC 4217에 정의되어 있습니다. 그 문서의 이후 버전에서, FTPS 규정은 클라이언트가 항상 AUTH TLS 방법을 사용하여 협상함을 요구합니다.
Transport Layer Security (TLS)/Secure Socket Layer (SSL)
General support
FTPS에는 서버-측 공개 키 인증 인증서와 클라이언트-측 권한 부여 인증서의 사용을 포함하여 TLS 및 SSL 암호화 프로토콜에 대한 전체 지원이 포함됩니다. 그것은 역시 AES, RC4, RC2, Triple DES, 및 DES를 포함한 호환되는 암호도 지원합니다. 그것은 역시 해시 함수 SHA, MD5, MD4, 및 MD2를 지원합니다.
Scope of use
암시적 모드에서, 전체 FTPS 세션이 암호화됩니다. 명시적 모드는 클라이언트가 연결의 어떤 영역을 암호화할지 완전히 제어할 수 있다는 점에서 다릅니다. FTPS 제어 채널과 FTPS 데이터 채널에 대한 암호화의 활성화하는 것과 비활성화하는 것은 언제든지 가능합니다. 유일한 제한은 FTPS 서버에서 발생하며, 이는 서버 암호화 정책을 기반으로 명령을 거부하는 능력을 가집니다.
Secure command channel
보안 명령 채널 모드는 AUTH TLS 또는 AUTH SSL 명령의 발행을 통해 입력될 수 있습니다. 그러한 시점 이후에, FTPS 클라이언트와 서버 사이의 모든 명령 제어가 암호화된 것으로 가정됩니다. 일반적으로 제3자가 사용자 이름과 비밀번호 데이터를 도청하는 것을 방지하기 위해 사용자 인증 및 권한 부여 전에 이러한 상태로 들어가는 것이 좋습니다.
Secure data channel
보안 데이터 채널은 PROT 명령의 발행을 통해 입력될 수 있습니다. 그것은 AUTH TLS 명령을 발행할 때 기본적으로 활성화되지 않습니다. 그러한 시점 후에, FTPS 클라이언트와 서버 사이의 모든 데이터 채널 통신은 암호화된 것으로 가정됩니다.
FTPS 클라이언트는 CDC (데이터 채널 지우기) 명령을 실행함으로써 언제든지 보안 데이터 채널 모드를 종료할 수 있습니다.
Reasons to disable encryption
다음 시나리오에서는 전송을 수행할 때 데이터 채널 암호화를 사용하는 것이 유리하지 않을 수 있습니다:
- 전송되는 파일은 비-민감한 본성이며, 암호화가 필요하지 않습니다.
- 전송되는 파일은 이미 파일 수준에서 암호화되어 있거나 암호화된 VPN을 통해 전달되므로, 암호화가 중복됩니다.
- 사용 가능한 TLS 또는 SSL 암호화 모드가 원하는 수준의 암호화를 충족하지 못합니다. 이것은 이전 미국 고암호화 수출법으로 인해 40-비트 SSL로 제한되었을 수 있는 이전 FTPS 클라이언트 또는 서버에서 흔히 발생하는 문제입니다.
다음 시나리오에서는 제어 채널 암호화를 사용하는 것이 유리하지 않을 수 있습니다:
- 클라이언트 또는 서버가 네트워크 방화벽 또는 네트워크 주소 변환 (NAT) 장치 뒤에 있을 때 FTPS의 사용. (아래 방화벽 비호환성 참조)
- 같은 세션 내에서 익명 FTP 클라이언트에 의해 AUTH 및 CCC/CDC 명령의 반복적 사용. 그러한 행위는 TLS/SSL 세션이 매번 재생성되어야 하며, 서버 프로세서 시간을 사용해야 하므로 자원-기반 서비스 거부 공격으로 사용될 수 있습니다.
SSL certificates
HTTPS와 마찬가지로, FTPS 서버는 공개 키 인증서를 제공해야 합니다. 이들 인증서는 OpenSSL과 같은 도구를 사용하여 요청되고 생성될 수 있습니다.
이들 인증서가 신뢰할 수 있는 인증 기관에 의해 서명될 때, 이것은 클라이언트가 요청된 서버에 연결되어, 중간자 공격을 방지한다는 확신을 제공합니다. 만약 인증서가 신뢰할 수 있는 CA (자체-서명 인증서)에 의해 서명되지 않으면, FTPS 클라이언트는 인증서가 유효하지 않다는 경고를 생성할 수 있습니다. 클라이언트는 인증서를 수락하거나 연결을 거부할 수 있습니다.
이것은 서명된 인증서를 제시하는 것이 아니라 대신 공개 키의 대역-외 인증에 의존하는 SSH 파일 전송 프로토콜 (SFTP)과 대조적입니다.
Firewall incompatibilities
FTP는 동적 이차 포트 (데이터 채널용)를 사용하기 때문에, 많은 방화벽은 그것들이 허용해야 할 이차 데이터 연결을 결정하기 위해 FTP 프로토콜 제어 메시지를 엿보기 위해 설계되었습니다. 어쨌든, 만약 FTP 제어 연결이 TLS/SSL을 사용하여 암호화되면, 방화벽은 클라이언트와 FTP 서버 사이에 협상된 데이터 연결의 TCP 포트 번호를 결정할 수 없습니다. 그러므로, 많은 방화벽 네트워크에서, FTPS 배포가 암호화되지 않은 FTP 배포가 작동하더라도 실패할 것입니다. 이 문제는 데이터에 제한된 범위의 포트를 사용하고 이들 포트를 열기 위해 방화벽을 구성하여 해결될 수 있습니다.
External links
- Overview of FTPS, and lists of clients, servers
- Curl-loader - an open-source FTPS loading/testing tool
