FTP over TLS

FTP 프로토콜은 오래전부터 그 목적에 맞는 용도로 훌륭하게 동작하고 있다. 다만, 인터넷이 상호 호의적인 분위기일 때 만들어진 대부분의 프로토콜들과 마찬가지로 보안에 취약하다. 사용자 아이다와 암호를 평문으로 전송하는 문제가 제일 크며, 그 다음으로 컨트롤 채널을 가로채면 암호를 몰라도 파일 전송, 조작 등을 수행할 수 있기 때문이다.

이런 문제점을 극복하기 위해서 TLS 를 이용해서 컨트롤과 데이터 채널 모두를 암호화 하는 FTP over TLS가 만들어졌다. 두 가지 방법이 있는데 명시적 모드에 대해서 조금 부연 설명이 필요하다. (암시적 방법은 구형 FTP 서버를 어쩔 수 없이 사용해야 하는 상황에 적용하는 것이고 일부러 사용할 이유는 없다. 단순히 구형 FTP 서버 전체를 SSL로 감싸는 것이다. 당연히 접속 후 암호화 해제는 불가능)

FTPES (FTP Explicit  over TLS)  는 최초 컨트롤 채널을 만들기 위해서 잘 알려진 21번 포트에 일반적인 접속 방법으로 접속을 한다.  접속 후 AUTH TLS 명령을 보내고 암호화 과정을 거친 후에 아이디와 암호를 전송하게 되며, 다른 요구가 있기 전까지는 이 암호화를 그대로 유지한다.

클라이언트에서 파일 목록이나 전송 등을 요구하면, 해당하는 데이터 채널을 열게 되는데 사용자 인증이 성공한 다음 PROT 명령을 전달하여 데이터 채널의 암호화 여부를 미리 결정하도록 되어 있다. (디폴트가 있는지 확인 필요)

https://kldp.org/node/93100 에 관련 글을 쓴 적이 있는데, 조금 많이 부끄러운 것이 하나 있다. FTPES 에서 컨트롤 채널의 암호화를 해제하는 것과 데이터 채널에 암호화를 쓰지 않도록 하는 명령이 다른데, 이를 무시하고 모르고 쓴 글이다.

컨트롤 채널의 암호화 해제는 CCC (Clear Control Channel), 데이터 채널의 암호화 해제는 CDC 명령으로 하는 것인데, 해당 글에서는 PROT C 로 문제를 해결하려고 하였다.

PROT C 는 인증과정 후 데이터 채널을 암호화 하지 않겠다고 알리는 것이다. CDC 사용과 유사하기는 하지만,  컨트롤 채널의 암호화를 해제하지는 않는다. 이 명령을 쓰더라도 여전히 컨트롤 채널은 암호화되어 있다.

그러므로, 해당 글의 내용중 방화벽이나 NAT를 회피하기 위해서 사용했다는 말은 틀린 것이다. 이 문제는 특정 포트의 범위를 데이터 채널용으로 사용하여 회피하도록 하였다.

여기서, 컨트롤 채널의 암호화를 풀면 어떻게 되는지 고민을 조금 해보았는데, 처음 생각은 이랬다. ‘아이다와 암호가 암호화된 채널로 전송되니까 이제 좀 안심이 되겠구나. 인증 과정이 끝나면 암호화를 풀어서 PASV 명령을 공유기가 알 수 있도록 평문 형태가 되도록 하자.’

자 여기까지는 좋은 생각 같지만, 문제가 있다. 이 글 초반에도 적었지만 컨트롤 채널을 가로채는 해킹의 경우 아이디와 암호를 몰라도 원하는 파일 전송, 조작 등을 수행할 수 있다는 것이다. 미들맨 어택에 속수무책이라는 것이다.

결국 컨트롤 채널은 암호화 과정을 계속 유지하는 것이 올바른 판단으로 보이고, 경우에 따라서 데이터 채널만 암호화를 해제하는 것이 좋겠다고 결론을 내렸다. (전송되는 데이터가 해킹되어도 문제가 없을 경우에 한해서)