5

So here is my 'problem', I set up an FTP server thanks to vsftpd so that both login & data transfers should be encrypted.

Here is the interesting part of my vsftpd.conf file.

ssl_enable=YES
allow_anon_ssl=NO
require_ssl_reuse=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES

ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES

rsa_cert_file=/etc/vsftpd/vsftpd.pem
rsa_private_key_file=/etc/vsftpd/vsftpd.pem
ssl_ciphers=HIGH

I am using Filezilla as an FTP client, the connection is configured like this :

Protocol : FTP - File Transfer Protocol
Encryption : Require explicit FTP over TLS
Logon type: Normal

Some things to note :

  • Encryption : Plain FTP : does not work and I am happy with that. (Response: 530 Non-anonymous sessions must use encryption.)

  • Encryption : Require implicit FTP over TLS : does not work either, the connection is refused by the server. I guess it is because I forced the SSL connection.

Now, once the (explicit) connection is established, Filezilla is showing a small lock icon at the bottom of the window saying The connection is encrypted. Click icon for details.

I wanted to make sure that the data transfers were indeed encrypted and not plain so I captured everything on my eth. card with Wireshark while downloading a file from my server to my computer.

Except that I can not find a single packet of SSL protocol, everything is TCP.

I am out of ideas on how to make sure the data transferred is encrypted, even if filezilla says so, and each time I google "vsftpd how to make sure data transfers are encrypted", the only answers I get is "ssl_enable=YES" or "Check the box Use SSL" ...

Thank you in advance for helping me !

Alfred Huang
  • 17,654
  • 32
  • 118
  • 189
Laurent Dezitter
  • 710
  • 1
  • 8
  • 16
  • Have you followed the instructions on http://wiki.wireshark.org/SSL ? – Neil May 29 '12 at 23:37
  • I did read this part of the Wiki. I have also tested capturing packets while browsing an https link. – Laurent Dezitter May 30 '12 at 00:05
  • Would the person that vote this question down be kind enough to say why ? It does not really help me... – Laurent Dezitter May 30 '12 at 11:41
  • HTTPS is equivalent to implicit FTPS in that it starts with an SSL handshake over a different port to the regular HTTP/FTP. Have you tried capturing, say, SMTP over TLS instead? – Neil May 30 '12 at 20:39
  • No i did not. What i don't understand is that the protocol used is TCP while the data transfered should be encrypted and so the protocol identified be SSL. – Laurent Dezitter May 31 '12 at 14:22

1 Answers1

8

After a little more research and especially after following the Complete walk through on http://wiki.wireshark.org/SSL, I have a better understanding of the whole thing.

I am answering to my own question hoping this will help someone someday, as long as what follows is correct...

Also writing this down is a good way for me, I think, to see if have clearly understood my problem. Any difficulties in writing this answer will prove me wrong.

First :

Typically, SSL uses TCP as its transport protocol.

SSL is wrapped in TCP, that is why I couldn't observe explicitly the SSL protocol while capturing packets.

When analyzing a TCP packet, I could only "Follow TCP stream" but not "Follow SSL stream" which mislead me into thinking the packet was not holding encrypted data. That is funny because the observable data was not human readable ... so encrypted.

To be able to decrypt it I had to provide wireshark the encryption key :

RSA keys list

This option specifies the bindings between an IP address, a port, a protocol and a decryption key.

Then, I could observe both encrypted / unencrypted data.

Also, after reading this on http://wiki.filezilla-project.org/ :

When you apply encryption to your FTP server the CPU will have to do many calculations to encrypt the data being sent and decrypt the data being received.

I simply decided to run the UNIX top command while downloading a file. I was able to observe a high CPU usage of the filezilla client process, contrary to a unencrypted data transfer. This was a second argument that confirmed the data transfered were indeed encrypted, and thus needed to be decrypted.

Community
  • 1
  • 1
Laurent Dezitter
  • 710
  • 1
  • 8
  • 16