maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Obernöder (Jira) <>
Subject [jira] [Commented] (WAGON-600) FTP-Upload fails if server enforces data encryption
Date Thu, 17 Sep 2020 21:08:00 GMT


David Obernöder commented on WAGON-600:

Sorry for my delayed answer, I tested the code in a virtual machine to get the traces. For
the encryption I used the Certificate of phpstorm-docker-images:
So you can download this one and put it into Wireshark to read the encrypted content.

> Our code seems to never have worked (FTPSClientWagon)
Yes and no! The encryption does work for the communication channel on port 21. So the commands,
including Username and Password are encrypted properly (you can find the client request "AUTH
TLS" in the trace's packet No. 6, followed by the authentification in packet No. 24 and Password
in No. 28). But the transfer of the files is in plain text (you can see this for example in
packet 161 or 67 in the trace_ftp_original_wagon).

> I see no point in supporting C for an FTPSClientWagon
I think this is a question of stability VS. security. The best way would be that there is
an encrypted transfer. Due to the default of the RFC Well, to be honest I never saw a server
that had an TLS-Authentication enabled but did not support data encryption. I don't know how
realistic such a server would be. With focus on security the better way would be a abort of
the connection. I can't really decide what the best way is.

> I don't like that you are continuing in cleartext if P fails. It makes FTPS pointless,
doesn't it?
I had an implementation before where no fallback was made. Then I had a closer look on RFC4217
which says:
The initial state of the data connection MUST be 'Clear' (this is the behaviour as indicated
by [RFC-2228]).
I didn't find a hint that it is "bad practise" to use clear data mode when doing encrypted
authentification. It is just not obvious to users that there are two levels of encryption
-- I really had several users at the company who wondered about why we are enabling encryption

> Can you provide a debug log (wireshark or FTP server) with unsuccessful and successful
Please find the wireshark traces attached. "trace_ftp_original_wagon-ftp" is the one from
your repo and the "trace_ftp_modified_wagon-ftp" is the one with my adjustments.
I used vsftpd 3.0.2 to capture the traces in a VirtualBox environment. I set the Parameter
"force_local_data_ssl=YES". For my understanding this should have the same impact as "SECURE_DATACONN
PRIVATE" at the server we use at work and abort the connection with 425. Well, it looks like
the behaviour of vsftpd is a little bit different than I would have expected. The connection
does not abort, I probably switched the wrong parameter. Maybe I'll find some time at the
weekend and test it with VSFTP 3.0.3 again -- there have been some modification in the security

I hope this helps a little,
best regards, David

> FTP-Upload fails if server enforces data encryption
> ---------------------------------------------------
>                 Key: WAGON-600
>                 URL:
>             Project: Maven Wagon
>          Issue Type: Improvement
>          Components: wagon-ftp
>    Affects Versions: 2.0
>            Reporter: David Obernöder
>            Priority: Trivial
>   Original Estimate: 8h
>  Remaining Estimate: 8h
> We recently deployed stronger encryption rules to a few of our webservers. Unfortunately
this leads to an issue with the FTP-Upload of wagon plugin for FTP. We receive the message
"425-Server reqires protected data connection".
> Due to our FTP-Server allows only data transfer with encryption, this error arises.
> RFC4217, 9 defines the behaviour of Data Connection Protection and defines two available
modes for FTPS:
> 'C' - Clear - neither Integrity nor Privacy
> 'P' - Private - Integrity and Privacy
> With 'Clear' protection level, the data connection is made without
>  TLS. Thus, the connection is unauthenticated and has no
>  confidentiality or integrity. This might be the desired behaviour
>  for servers sending file lists, pre-encrypted data, or non-
>  sensitive data (e.g., for anonymous FTP servers).
>  If the data connection security level is 'Private', then a TLS
>  negotiation must take place on the data connection to the
>  satisfaction of the Client and Server prior to any data being
>  transmitted over the connection. The TLS layers of the Client and
>  Server will be responsible for negotiating the exact TLS Cipher
>  Suites that will be used (and thus the eventual security of the
>  connection).
> In addition, the PBSZ (protection buffer size) command, as
>  detailed in [RFC-2228], is compulsory prior to any PROT command.
>  This document also defines a data channel encapsulation mechanism
>  for protected data buffers. For FTP-TLS, which appears to the FTP
>  application as a streaming protection mechanism, this is not
>  required. Thus, the PBSZ command MUST still be issued, but must
>  have a parameter of '0' to indicate that no buffering is taking
>  place and the data connection should not be encapsulated.
> [...]
> However, it should be noted that using a value of '0' to mean a
>  streaming protocol is a reasonable use of '0' for that parameter
>  and is not ambiguous.
> Initial Data Connection Security
> The initial state of the data connection MUST be 'Clear' (this is
>  the behaviour as indicated by [RFC-2228]).
> While inspecting the code I noticed that the plugin does not do any switch to "secure
data connection" (PBSZ 0 and PROT P). So it looks like the plugin is not compatible to servers
that enforce a data connection.
> A good behaviour would be that the plugin tries to switch to protected data connections
and continue if the server can't handle the PROT Command. Many clients switch to data encryption
too when a TLS encrypted FTP was started.
> I'm pretty sure this is also an issue in the current version.

This message was sent by Atlassian Jira

View raw message