During TLS handshaking server can ignore a cipher from the preference list in ClientHello message

I've noticed recently that when my client tries to negotiated a TLS session its ciphers preference list is being ignored by the server.

• Test 1

$ openssl s_client -connect server_ip:443 -state -msg -cipher AES128-SHA
# filtered out  ....
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA

• Test 2

$ openssl s_client -connect server_ip:443 -state -msg -cipher DES-CBC-SHA
# filtered out  ....
New, TLSv1/SSLv3, Cipher is DES-CBC-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DES-CBC-SHA

• Test 3

# openssl s_client -connect server_ip:443 -state -msg -cipher DES-CBC-SHA:AES128-SHA
# skiped ...
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID:
    Session-ID-ctx:
    Master-Key: C7E7F65B4E927AFDE568E52FDAE52495CE815DAC2958B82C854146CD383FC00BB47ED691840C713CE762B6430FCB3230
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1389568347
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)

• Test 4

# openssl s_client -connect server_ip:443 -state -msg -cipher AES128-SHA:DES-CBC-SHA
# skiped ...
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID:
    Session-ID-ctx:
    Master-Key: 1F0FB31410AAFFC234DC5598FFA2A676C63119A6367453D05578F9B1652DD085DB1D5C016694B9D293F3A2DFF769EF51
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1389568389
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)

We can see in (1) and (2) that the TLS servers supports 2 different ciphers suits.
In (3) and (4) we see that even though the preference list was directly specified by the client the TLS server ignored the settings in (3).

Example ssldump output from (3).

 
# ssldump -A -n -i eth0 port 443 and host my_server_ip
New TCP connection #1: 162.13.0.27(51869) <-> my_server_ip(443)
1 1  0.1013 (0.1013)  C>SV3.1(61)  Handshake
      ClientHello
        Version 3.2
        random[32]=
          52 d3 23 b5 62 f5 08 38 14 53 d9 ac a4 51 c2 28
          0d e2 0e b6 41 89 2d af a1 50 55 bd a9 35 05 75
        cipher suites
        TLS_RSA_WITH_DES_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        Unknown value 0xff
        compression methods
                unknown value
                  NULL
1 2  0.1984 (0.0970)  S>CV3.1(49)  Handshake
      ServerHello
        Version 3.1
        random[32]=
          2b ae 63 1e 9c da f3 38 b6 f9 dd c6 c0 4f ad 6c
          2c f0 f3 52 67 6e 28 29 8a 24 95 95 a5 67 f2 6f
        session_id[0]=

        cipherSuite         TLS_RSA_WITH_AES_128_CBC_SHA
        compressionMethod                   NULL
1 3  0.1984 (0.0000)  S>CV3.1(674)  Handshake
      Certificate
        certificate[664]=
          50 82 02 94 50 82 01 fd 02 02 03 79 50 0d 06 09
          2a 86 48 86 f7 0d 01 01 05 05 00 50 81 b6 31 0b
          50 11 06 03 55 04 06 13 02 55 53 31 0e 50 0c 06
          03 55 04 08 13 05 54 65 78 61 73 31 14 50 12 06
          03 55 04 07 13 0b 53 61 6e 20 41 6e 74 6f 6e 69
          6f 31 12 50 10 06 03 55 04 0a 13 11 52 61 63 6b
          73 70 61 63 65 31 1e 50 1c 06 03 55 04 0b 13 15
          53 79 73 74 65 6d 20 41 64 6d 69 6e 69 73 74 72
          61 74 69 6f 6e 31 23 50 21 06 03 55 04 03 13 1a
...
          b3 79 0a 37 cd 27 93 af
1 4  0.1984 (0.0000)  S>CV3.1(4)  Handshake
      ServerHelloDone
1 5  0.2126 (0.0141)  C>SV3.1(134)  Handshake
      ClientKeyExchange
        EncryptedPreMasterSecret[128]=
          33 25 53 17 c2 45 b0 32 8a ca c1 66 39 6e f0 31
          98 96 4c 34 f2 e4 fd b7 0c e6 15 af c7 d3 fc e4
          0d 15 c9 c9 d4 e0 78 5a a1 13 dc 55 8b 5a bc 69
          68 24 f5 d1 50 6a 19 2e 71 9a 66 ee 3a 64 bc 1e
          d8 9a da d4 e0 44 96 b3 43 20 f1 a0 b6 4c 49 8e
          b2 ae 2b a6 12 68 78 19 eb 61 06 1c 34 8a 03 22
          ab 7e ff f8 88 44 89 97 cd 53 06 b0 b6 66 7b 77
          2a c0 0a 15 a3 54 2d 8c 5b 74 bc fe 31 3f 1f 8f
1 6  0.2126 (0.0000)  C>SV3.1(1)  ChangeCipherSpec
1 7  0.2126 (0.0000)  C>SV3.1(48)  Handshake
1 8  0.3100 (0.0974)  S>CV3.1(1)  ChangeCipherSpec
1 9  0.3100 (0.0000)  S>CV3.1(48)  Handshake
1    1.4782 (1.1681)  C>S  TCP FIN
1    1.5740 (0.0958)  S>C  TCP FIN

Problem

Can TLS server ignore the cipher suite list passed from the client during TLS handshaking?

Analysis

The specification how the ClientHello message can be handled by the server during TLS handshaking has changed from TLS v1.0 to v1.2. The extract from the RFC comparing both relevant sections.

• rfc2246

7.4.1.2. Client hello

   The CipherSuite list, passed from the client to the server in the
   client hello message, contains the combinations of cryptographic
   algorithms supported by the client in order of the client's
   preference (favorite choice first). Each CipherSuite defines a key
   exchange algorithm, a bulk encryption algorithm (including secret key
   length) and a MAC algorithm.

   The server will select a cipher suite or, if no acceptable choices 
   are presented, return a handshake failure alert and close the 
   connection.

• rfc5246

7.4.1.2.  Client Hello

   The cipher suite list, passed from the client to the server in the
   ClientHello message, contains the combinations of cryptographic
   algorithms supported by the client in order of the client's
   preference (favorite choice first).  Each cipher suite defines a key
   exchange algorithm, a bulk encryption algorithm (including secret key
   length), a MAC algorithm, and a PRF.  The server will select a cipher
   suite or, if no acceptable choices are presented, return a handshake
   failure alert and close the connection.

   If the list contains cipher suites the server does not recognize, 
   support, or wish to use, the server MUST ignore those cipher suites,
   and process the remaining ones as usual.

In the yellow parts we can see that a server implementing TLS v1.2 has the ability to ignore ciphers specified by the client in its list ClientHello message. The criteria are very wide. The TLS server can ignore a cipher only because it doesn't wish to use it.

References

http://www.openssl.org/docs/apps/ciphers.html
DES and IDEA ciphers are deprecated in the latest TLS protocol
http://www.ietf.org/rfc/rfc2246.txt - The TLS Protocol, Version 1.0
http://tools.ietf.org/html/rfc5246.txt - The Transport Layer Security (TLS) Protocol, Version 1.2
http://support.f5.com/kb/en-us/solutions/public/10000/200/sol10209.html - ssldump

A definitely interesting reading about ciphers in the web browser to show some parasitical view at the cipher list topic.
https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/36na1B2brGU

How does SFTP work

Every network administrator knows how painful is it to troubleshoot FTP protocol issues. Many of them are related to the FTP design concept of independent control and data channels. Because both FTP data and control channels are handled in separate TCP session often network devices are allowing one TCP session but blocking the other. The end result is that you can't connect to FTP server or you can't download a file or your download hangs and never completes.

There are number of alternatives. On of them is SFTP (Secure File Transfer Protocol). The design of this protocols is very different from FTP even though it shares its name.

In FTP we have concept of separate control and data channels. The client can sent commands over the control TCP session and data transfers happens in the data TCP sessions. Both the control and data TCP session has its own TCP conventions. Passive and active FTP mode make it even more convoluted.

In SFTP there is one session (by default the client connect on port 22 from random source port). The single session is used to exchange a mix of control and data commands. This is still truth that for a file transfer you need a new TCP session but the session is initiated in a similar way on port 22. From network point of view there is not much difference how the first or second TCP session looks. The sessions are independent but connected.

Example tcpdump showing a single file transfer (100* is client, 200* is server):

 
Nr      Time        Source             Destination         Protocol flags      Length      vlan hsrc                  hdst             sport  dport  Window size value Seq#       Ack#       Info

# connecting to the SFTP server
    130 0.017634    100.0.0.1          200.0.0.1           TCP      0x02       66          Dell_75:49:e3         Cisco_ee:08:c0        55373  22     65535             0                     55373 > ssh [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=128 SACK_PERM=1
    131 0.002186    200.0.0.1           100.0.0.1          TCP      0x12       66          Cisco_ee:08:c0        Dell_75:49:e3         22     55373  8192              0          1          ssh > 55373 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1
    132 0.000033    100.0.0.1          200.0.0.1           TCP      0x10       54          Dell_75:49:e3         Cisco_ee:08:c0        55373  22     32768             1          1          55373 > ssh [ACK] Seq=1 Ack=1 Win=4194304 Len=0
    133 0.004121    200.0.0.1           100.0.0.1          SSHv2    0x18       87          Cisco_ee:08:c0        Dell_75:49:e3         22     55373  258               1          1          Server Protocol: SSH-2.0-1.82_sshlib GlobalSCAPE\r
    134 0.000234    100.0.0.1          200.0.0.1           SSHv2    0x18       97          Dell_75:49:e3         Cisco_ee:08:c0        55373  22     32767             1          34         Client Protocol: SSH-2.0-PuTTY_Local:_Jan__8_2012_14:40:35\r
    135 0.000055    100.0.0.1          200.0.0.1           TCP      0x18       566         Dell_75:49:e3         Cisco_ee:08:c0        55373  22     32767             44         34         [TCP segment of a reassembled PDU]
    136 0.000018    100.0.0.1          200.0.0.1           SSHv2    0x18       182         Dell_75:49:e3         Cisco_ee:08:c0        55373  22     32767             556        34         Client: Key Exchange Init
    137 0.002431    200.0.0.1           100.0.0.1          SSHv2    0x18       542         Cisco_ee:08:c0        Dell_75:49:e3         22     55373  258               34         44         Server: Key Exchange Init
    138 0.000001    200.0.0.1           100.0.0.1          TCP      0x10       60          Cisco_ee:08:c0        Dell_75:49:e3         22     55373  256               522        684        ssh > 55373 [ACK] Seq=522 Ack=684 Win=65536 Len=0
    139 0.000076    100.0.0.1          200.0.0.1           SSHv2    0x18       70          Dell_75:49:e3         Cisco_ee:08:c0        55373  22     32763             684        522        Client: Diffie-Hellman Key Exchange Init
    140 0.002168    200.0.0.1           100.0.0.1          SSHv2    0x18       334         Cisco_ee:08:c0        Dell_75:49:e3         22     55373  256               522        700        Server: Diffie-Hellman Key Exchange Reply
    141 0.018620    100.0.0.1          200.0.0.1           SSHv2    0x18       326         Dell_75:49:e3         Cisco_ee:08:c0        55373  22     32761             700        802        Client: Diffie-Hellman GEX Init
    142 0.024606    200.0.0.1           100.0.0.1          SSHv2    0x18       902         Cisco_ee:08:c0        Dell_75:49:e3         22     55373  254               802        972        Server: Diffie-Hellman GEX Reply
    144 0.005229    100.0.0.1          200.0.0.1           SSHv2    0x18       70          Dell_75:49:e3         Cisco_ee:08:c0        55373  22     32768             972        1650       Encrypted request packet len=16[Malformed Packet]
    145 0.000113    100.0.0.1          200.0.0.1           SSHv2    0x18       142         Dell_75:49:e3         Cisco_ee:08:c0        55373  22     32768             988        1650       Encrypted request packet len=88
    146 0.001946    200.0.0.1           100.0.0.1          TCP      0x10       60          Cisco_ee:08:c0        Dell_75:49:e3         22     55373  254               1650       1076       ssh > 55373 [ACK] Seq=1650 Ack=1076 Win=65024 Len=0
    147 0.000001    200.0.0.1           100.0.0.1          SSHv2    0x18       174         Cisco_ee:08:c0        Dell_75:49:e3         22     55373  254               1650       1076       Encrypted response packet len=120
    148 0.000249    100.0.0.1          200.0.0.1           SSHv2    0x18       158         Dell_75:49:e3         Cisco_ee:08:c0        55373  22     32767             1076       1770       Encrypted request packet len=104
    149 0.002327    200.0.0.1           100.0.0.1          SSHv2    0x18       122         Cisco_ee:08:c0        Dell_75:49:e3         22     55373  254               1770       1180       Encrypted response packet len=68
......

# we initiated a file transfer 
# new tcp session is created, similar like in passive FTP mode
   1683 0.064012    100.0.0.1          200.0.0.1           TCP      0x02       66          Dell_75:49:e3         Cisco_ee:08:c0        55375  22     65535             0                     55375 > ssh [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=128 SACK_PERM=1
   1684 0.002196    200.0.0.1           100.0.0.1          TCP      0x12       66          Cisco_ee:08:c0        Dell_75:49:e3         22     55375  8192              0          1          ssh > 55375 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1
   1685 0.000035    100.0.0.1          200.0.0.1           TCP      0x10       54          Dell_75:49:e3         Cisco_ee:08:c0        55375  22     32768             1          1          55375 > ssh [ACK] Seq=1 Ack=1 Win=4194304 Len=0
   1686 0.004089    200.0.0.1           100.0.0.1          SSHv2    0x18       87          Cisco_ee:08:c0        Dell_75:49:e3         22     55375  258               1          1          Server Protocol: SSH-2.0-1.82_sshlib GlobalSCAPE\r
   1687 0.000506    100.0.0.1          200.0.0.1           SSHv2    0x18       97          Dell_75:49:e3         Cisco_ee:08:c0        55375  22     32767             1          34         Client Protocol: SSH-2.0-PuTTY_Local:_Jan__8_2012_14:40:35\r
   1688 0.000053    100.0.0.1          200.0.0.1           TCP      0x18       566         Dell_75:49:e3         Cisco_ee:08:c0        55375  22     32767             44         34         [TCP segment of a reassembled PDU]
   1689 0.000015    100.0.0.1          200.0.0.1           SSHv2    0x18       182         Dell_75:49:e3         Cisco_ee:08:c0        55375  22     32767             556        34         Client: Key Exchange Init
   1690 0.002266    200.0.0.1           100.0.0.1          SSHv2    0x18       542         Cisco_ee:08:c0        Dell_75:49:e3         22     55375  258               34         44         Server: Key Exchange Init
   1691 0.000001    200.0.0.1           100.0.0.1          TCP      0x10       60          Cisco_ee:08:c0        Dell_75:49:e3         22     55375  256               522        684        ssh > 55375 [ACK] Seq=522 Ack=684 Win=65536 Len=0
   1692 0.000109    100.0.0.1          200.0.0.1           SSHv2    0x18       70          Dell_75:49:e3         Cisco_ee:08:c0        55375  22     32763             684        522        Client: Diffie-Hellman Key Exchange Init
   1693 0.002230    200.0.0.1           100.0.0.1          SSHv2    0x18       334         Cisco_ee:08:c0        Dell_75:49:e3         22     55375  256               522        700        Server: Diffie-Hellman Key Exchange Reply
   1697 0.000446    100.0.0.1          200.0.0.1           SSHv2    0x18       326         Dell_75:49:e3         Cisco_ee:08:c0        55375  22     32761             700        802        Client: Diffie-Hellman GEX Init
   1698 0.023470    200.0.0.1           100.0.0.1          SSHv2    0x18       902         Cisco_ee:08:c0        Dell_75:49:e3         22     55375  254               802        972        Server: Diffie-Hellman GEX Reply
   1699 0.027365    100.0.0.1          200.0.0.1           SSHv2    0x18       70          Dell_75:49:e3         Cisco_ee:08:c0        55375  22     32768             972        1650       Encrypted request packet len=16[Malformed Packet]
   1700 0.000111    100.0.0.1          200.0.0.1           SSHv2    0x18       142         Dell_75:49:e3         Cisco_ee:08:c0        55375  22     32768             988        1650       Encrypted request packet len=88
   1701 0.001906    200.0.0.1           100.0.0.1          TCP      0x10       60          Cisco_ee:08:c0        Dell_75:49:e3         22     55375  254               1650       1076       ssh > 55375 [ACK] Seq=1650 Ack=1076 Win=65024 Len=0
   1702 0.000001    200.0.0.1           100.0.0.1          SSHv2    0x18       174         Cisco_ee:08:c0        Dell_75:49:e3         22     55375  254               1650       1076       Encrypted response packet len=120
   1703 0.000303    100.0.0.1          200.0.0.1           SSHv2    0x18       158         Dell_75:49:e3         Cisco_ee:08:c0        55375  22     32767             1076       1770       Encrypted request packet len=104
   ...

# once the tranfer is finished both sessions are closed

   2498 0.015696    100.0.0.1          200.0.0.1           TCP      0x14       54          Dell_75:49:e3         Cisco_ee:08:c0        55373  22     0                 3768       3158       55373 > ssh [RST, ACK] Seq=3768 Ack=3158 Win=0 Len=0

Example loggin session from FileZilla:

 
Status: Connecting to 200.0.0.1...
Response:   fzSftp started
Command:    open "user_name@200.0.0.1" 22
Command:    Trust new Hostkey: Once
Command:    Pass: **********
Status: Connected to 200.0.0.1
Status: Retrieving directory listing...
Command:    pwd
Response:   Current directory is: "/"
Command:    ls
Status: Listing directory /
Status: Calculating timezone offset of server...
Command:    mtime "Archive"
Response:   1365109008
Status: Timezone offsets: Server: 0 seconds. Local: 3600 seconds. Difference: 3600 seconds.
Status: Directory listing successful
Status: Connecting to 200.0.0.1...
Response:   fzSftp started
Command:    open "user_name@200.0.0.1" 22
Command:    Trust new Hostkey: Once
Command:    Pass: **********
Status: Connected to 200.0.0.1
Status: Starting download of /paht/to/the/file.txt
Command:    cd "/"
Response:   New directory is: "/"
Command:    get "/paht/to/the/file.txt" "c:\Users\file.txt"
Status: remote:/paht/to/the/file.txt => local:c:\Users\file.txt
Status: File transfer successful, transferred 360 bytes in 1 second
Status: Disconnected from server
Status: Disconnected from server

References

1. http://blog.asmallorange.com/the-difference-between-ftp-sftp-and-ftps/
2. https://wiki.filezilla-project.org/SFTP_specifications
3. http://en.wikipedia.org/wiki/SFTP (some info about FTP alternatives)
4. http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13

Howto tune HTTP browser connection with Connection and Keep-Alive HTTP headers

I've come across this response today. This is diffident from all other I have seen so far. It uses the timeout and max options for the Keep-Alive header that should influences how the TCP connection should be handled.

 
HTTP/1.1 200 OK
Date: Wed, 10 Apr 2013 08:42:48 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Wed, 10 Apr 2013 08:42:48 GMT
Cache-Control: no-store,no-cache,must-revalidate
Expires: -1
Content-Length: 1567
Keep-Alive: timeout=5, max=10
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

Looking at the recent HTTP 1.1 RFC rfc2616 we can see that this options is addressed in more details here:

The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in RFC 2068.

Looking at RFC 2068 we see that it specifies in the paragraph  19.7.1.1 The Keep-Alive Header

The Keep-Alive header itself is optional, and is used only if a parameter is being sent. HTTP/1.1 does not define any parameters.

It doesn't specify anything about max or timeout parameters  With Google help I found this RFC draft Hypertext Transfer Protocol (HTTP) Keep-Alive Header. In this one we can see that:

The value of the timeout parameter is a single integer in seconds.
The value of the max parameter counts the number of requests since the connection was created.

How to inspect HTTP headers for GET request in Chrome

When troubleshooting HTTP protocol it is required to inspection and verify various HTTP headers for the sending requests and receiving response.

Problem

When in Chrome navigating to http://example.com/mysite.html URL how to see all headers.

Solution and demonstration

There are very few extensions that allow you to inspect the request headers  Most of them give you access to the response data only. The Developer tools is the only one extension I found that shows request and response headers in Chrome.

This is how you can start and test it:

• Chrome main menu
• navigate to Tools
• select Developer tools

References

1. https://developers.google.com/chrome-developer-tools/
2. http://stackoverflow.com/questions/4423061/view-http-headers-in-google-chrome 
3. http://blog.ashfame.com/2010/05/view-html-headers-firefox-google-chrome/

What happens to FTPS data channel if client closes control connection

There are couple of extensions added to standard FTP protocol to make it secure. It is important as in the default FTP configuration the control as well as the data channel use clear text to exchange commands or transmit data.

Problem

We assume that we were able to established a successful FTPS base session between a client and server. The client started a new data session to download a large file from the server or is uploading a file using the passive mode.

What happens to a file transfer if the control session is terminated by the client.

Troubleshooting

To verify the scenario we are going to setup a simple test scenario like in Does IPv4 based FTPS server supports EPSV FTP protocol extension blog [1].

As the curl client by default is not closing the control connections (what is a correct behavior that we will discuss at the end of this blog) we are going to use an active method to close an established tcp session described here How to forcibly kill an established TCP connection in Linux  [2].

Test #1: client download a large file

Client logs

Logs when the control connection is being closed and reseted

root@clinet:~# netstat -tulpan | grep curl
tcp        0      0 5.79.21.166:45707       5.79.17.48:8000         ESTABLISHED 5546/curl
tcp    64210      0 5.79.21.166:43796       5.79.17.48:8011         ESTABLISHED 5546/curl

root@clinet:~# ./killcx.pl 5.79.17.48:8011
killcx v1.0.3 - (c)2009-2011 Jerome Bruandet - http://killcx.sourceforge.net/

[PARENT] checking connection with [5.79.17.48:8011]
[PARENT] found connection with [5.79.21.166:43796] (ESTABLISHED)
[PARENT] forking child
[CHILD]  interface not defined, will use [eth0]
[CHILD]  setting up filter to sniff ACK on [eth0] for 5 seconds
[CHILD]  hooked ACK from [5.79.21.166:43796]
[CHILD]  found AckNum [1229126485] and SeqNum [3095306962]
[CHILD]  sending spoofed RST to [5.79.21.166:43796] with SeqNum [1229126485]
[CHILD]  sending RST to remote host as well with SeqNum [3095306962]
[CHILD]  all done, sending USR1 signal to parent [5781] and exiting
[PARENT] received child signal, checking results...
         => success : connection has been closed !

These are the client logs from the start of downloading until the control session is closed.

root@client:~# curl -v --limit-rate 10K -o file.txt -u rado:pass -k --ftp-ssl ftp://5.79.17.48:8000/c2900-universalk9-mz.SPA.152-1.T.bin
* About to connect() to 5.79.17.48 port 8000 (#0)
*   Trying 5.79.17.48...   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0connected
< 220-FileZilla Server version 0.9.41 beta
< 220-written by Tim Kosse (Tim.Kosse@gmx.de)
< 220 Please visit http://sourceforge.net/projects/filezilla/
> AUTH SSL
< 234 Using authentication type SSL
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS handshake, Server finished (14):
{ [data not shown]
* SSLv3, TLS handshake, Client key exchange (16):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSL connection using AES256-SHA
* Server certificate:
*        subject: CN=www; C=11; ST=aaa; L=bbb; O=ddd; OU=aaa; emailAddress=a@a.com
*        start date: 2012-11-08 00:13:54 GMT
*        expire date: 2013-11-08 00:13:54 GMT
*        common name: www (does not match '5.79.17.48')
*        issuer: CN=www; C=11; ST=aaa; L=bbb; O=ddd; OU=aaa; emailAddress=a@a.com
*        SSL certificate verify result: self signed certificate (18), continuing anyway.
> USER rado
< 331 Password required for rado
> PASS pass
< 230 Logged on
> PBSZ 0
< 200 PBSZ=0
> PROT P
< 200 Protection level set to P
> PWD
< 257 "/" is current directory.
* Entry path is '/'
> EPSV
* Connect data stream passively
< 229 Entering Extended Passive Mode (|||8011|)
*   Trying 5.79.17.48... connected
* Connecting to 5.79.17.48 (5.79.17.48) port 8011
> TYPE I
< 200 Type set to I
> SIZE c2900-universalk9-mz.SPA.152-1.T.bin
< 213 77200652
> RETR c2900-universalk9-mz.SPA.152-1.T.bin
< 150 Connection accepted
* Doing the SSL/TLS handshake on the data stream
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL re-using session ID
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSL connection using AES256-SHA
* Server certificate:
*        subject: CN=www; C=11; ST=aaa; L=bbb; O=ddd; OU=aaa; emailAddress=a@a.com
*        start date: 2012-11-08 00:13:54 GMT
*        expire date: 2013-11-08 00:13:54 GMT
*        common name: www (does not match '5.79.17.48')
*        issuer: CN=www; C=11; ST=aaa; L=bbb; O=ddd; OU=aaa; emailAddress=a@a.com
*        SSL certificate verify result: self signed certificate (18), continuing anyway.
* Maxdownload = -1
* Getting file with size: 77200652
{ [data not shown]
  0 73.6M    0  616k    0     0  10095      0  2:07:27  0:01:02  2:06:25  9753* SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
  0 73.6M    0  620k    0     0  10160      0  2:06:38  0:01:02  2:05:36 11170
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
} [data not shown]
curl: (56) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104

Server logs

As the file download started this is logged on the server.

After the client control connections is terminated the server logs '426 Connection closed' tranfer aborted' log message.

After about 3-5 seconds after the connections clears from the server logs.

Test #2: client upload a large file

Client logs

The client logs when control channel is terminated.

root@client:~# netstat -tulpan | grep curl
tcp        0      0 5.79.21.166:43489       5.79.17.48:8016         ESTABLISHED 13177/curl
tcp        0      0 5.79.21.166:45717       5.79.17.48:8000         ESTABLISHED 13177/curl

root@client:~# ./killcx.pl  5.79.17.48:8016 
killcx v1.0.3 - (c)2009-2011 Jerome Bruandet - http://killcx.sourceforge.net/

[PARENT] checking connection with [5.79.17.48:8016]
[PARENT] found connection with [5.79.21.166:43489] (ESTABLISHED)
[PARENT] forking child
[CHILD]  interface not defined, will use [eth0]
[CHILD]  setting up filter to sniff ACK on [eth0] for 5 seconds
[PARENT] sending spoofed SYN to [5.79.21.166:43489] with bogus SeqNum
[CHILD]  hooked ACK from [5.79.21.166:43489]
[CHILD]  found AckNum [781536832] and SeqNum [2094006657]
[CHILD]  sending spoofed RST to [5.79.21.166:43489] with SeqNum [781536832]
[CHILD]  sending RST to remote host as well with SeqNum [2094006657]
[CHILD]  all done, sending USR1 signal to parent [13547] and exiting
[PARENT] received child signal, checking results...
         => success : connection has been closed !

Curl logs when the upload starts and the control channel is terminated.

root@client:~# curl -v --limit-rate 10K -T file.txt -u rado:pass -k --ftp-ssl ftp://5.79.17.48:8000/
* About to connect() to 5.79.17.48 port 8000 (#0)
*   Trying 5.79.17.48...   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0connected
< 220-FileZilla Server version 0.9.41 beta
< 220-written by Tim Kosse (Tim.Kosse@gmx.de)
< 220 Please visit http://sourceforge.net/projects/filezilla/
> AUTH SSL
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0< 234 Using authentication type SSL
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS handshake, Server finished (14):
{ [data not shown]
* SSLv3, TLS handshake, Client key exchange (16):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSL connection using AES256-SHA
* Server certificate:
*        subject: CN=www; C=11; ST=aaa; L=bbb; O=ddd; OU=aaa; emailAddress=a@a.com
*        start date: 2012-11-08 00:13:54 GMT
*        expire date: 2013-11-08 00:13:54 GMT
*        common name: www (does not match '5.79.17.48')
*        issuer: CN=www; C=11; ST=aaa; L=bbb; O=ddd; OU=aaa; emailAddress=a@a.com
*        SSL certificate verify result: self signed certificate (18), continuing anyway.
> USER rado
< 331 Password required for rado
> PASS pass
< 230 Logged on
> PBSZ 0
< 200 PBSZ=0
> PROT P
< 200 Protection level set to P
> PWD
< 257 "/" is current directory.
* Entry path is '/'
> EPSV
* Connect data stream passively
< 229 Entering Extended Passive Mode (|||8016|)
*   Trying 5.79.17.48... connected
* Connecting to 5.79.17.48 (5.79.17.48) port 8016
> TYPE I
< 200 Type set to I
> STOR file.txt
< 150 Connection accepted
* Doing the SSL/TLS handshake on the data stream
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL re-using session ID
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSL connection using AES256-SHA
* Server certificate:
*        subject: CN=www; C=11; ST=aaa; L=bbb; O=ddd; OU=aaa; emailAddress=a@a.com
*        start date: 2012-11-08 00:13:54 GMT
*        expire date: 2013-11-08 00:13:54 GMT
*        common name: www (does not match '5.79.17.48')
*        issuer: CN=www; C=11; ST=aaa; L=bbb; O=ddd; OU=aaa; emailAddress=a@a.com
*        SSL certificate verify result: self signed certificate (18), continuing anyway.
} [data not shown]
  0 73.6M    0     0    0  688k      0  10122  2:07:07  0:01:09  2:05:58  9814* SSL_write() returned SYSCALL, errno = 10422:51:35
  0 73.6M    0     0    0  688k      0  10122  2:07:07  0:01:09  2:05:58  8177
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
} [data not shown]
curl: (55) SSL_write() returned SYSCALL, errno = 104

Server logs

When the upload starts and 1-3 seconds after the control channel is closed.

Results discussion

We can see that every time the client closes the TCP session used to host the control channel bad things happen to the upload or download process.

This is expected behavior and is documented in the relevant RFC documents:


http://tools.ietf.org/html/rfc4217
7. Data Connection Behaviour

http://tools.ietf.org/html/rfc959
3.2.  ESTABLISHING DATA CONNECTIONS

The server MUST close the data connection under the following conditions:

         1. The server has completed sending data in a transfer mode
            that requires a close to indicate EOF.

         2. The server receives an ABORT command from the user.

         3. The port specification is changed by a command from the
            user.

         4. The control connection is closed legally or otherwise.

         5. An irrecoverable error condition occurs.

References

1. http://rtomaszewski.blogspot.co.uk/2012/11/does-ipv4-based-ftps-server-supports.html
2. http://rtomaszewski.blogspot.co.uk/2012/11/how-to-forcibly-kill-established-tcp.html