[lug] FTPS + SSL parameters question... (Bear Giles)

[Evelyn Mitchell]

Do you have, or can you coordinate to get, more detailed logging on
the SFTP server side?

https://serverfault.com/questions/73319/sftp-logging-is-there-a-way
says there is a way to get more details on the connection attempts,
which might be helpful.

I debugged a similar issue to this, last year, and it turned out the
client was on the other side of a proxy they didn't tell us about,
which was doing dodgy things to the connection, which broke the
certificate.

So, it might not be your code, and it might not be something the other
side is aware of.

Evelyn Mitchell
tummy.com



On Sat, Oct 12, 2019 at 11:59 AM <lug-request at lug.boulder.co.us> wrote:
>
> Send LUG mailing list submissions to
>         lug at lug.boulder.co.us
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.lug.boulder.co.us/mailman/listinfo/lug
> or, via email, send a message with subject or body 'help' to
>         lug-request at lug.boulder.co.us
>
> You can reach the person managing the list at
>         lug-owner at lug.boulder.co.us
>
> When replying, please edit your Subject line so it is more specific
> Message: 1
> Date: Sat, 12 Oct 2019 11:58:45 -0600
> From: Bear Giles <bgiles at coyotesong.com>
> To: duboulder <blug-mail at duboulder.com>
> Cc: "Boulder \(Colorado\) Linux Users Group -- General Mailing List"
>         <lug at lug.boulder.co.us>
> Subject: Re: [lug] FTPS + SSL parameters question...
> Message-ID:
>         <CALBNtw7qWeLM6UjcFCySVZwAVO5ggE2nqzLY18nsr8Lccnc6HA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I've considered several of those issues but keep hitting the fact that the
> integration tests pass. The problem isn't in my code per se, it's some
> difference in the environment as it's executed inside the application. It
> looks a lot like a man-in-the-middle - and we are doing advanced tricks to
> monitor network traffic for statistical purposes - but it doesn't modify
> the payload.
>
> For people coming across this thread later -
>
> 1. the socket is provided by the server. More precisely I think the
> exchange is something like:
>
>   C> I want to establish a 'passive' data connection
>   S> use port 2007
>   C> (connects to port 2007)
>
> but I don't know if the server also provides the hostname/ip address of the
> passive data connection. The average FTP server won't but an 'enterprise'
> level server might for load balancing... but it could as easily use load
> balancing for the control connection and the data connection always uses
> the same IP address as the control connection.
>
> 2. yes, but I know that's not the case here. I had connected using an IP
> address and the logged messages show that both addresses use the same IP
> address.
>
> I did add addr3 = ... getCanonicalHostName() but it didn't matter.
>
> 3, 4. Always good advice to check but I can rule it out given the log
> messages. Plus our production systems might have a lot of things going on
> at the same time but this is happening on a dev laptop where I'm literally
> doing the absolute minimum required to run this test.
>
> Thanks for the help.
>
> On Fri, Oct 11, 2019 at 6:52 PM duboulder <blug-mail at duboulder.com> wrote:
>
> > This is getting farther into ssl programming than I know. Just some random
> > thoughts:
> >
> > 1) cache := session.context["sessionHostPortCache"]
> >     Can the cache puts use different addr1/addr2 as keys on different
> > sockets
> >     (different remote ports for data/control channels, or different local
> > ports on
> >      the client for the channels). Is that the expected behavior?
> >          grep ftp /etc/services reports
> >                 20/21 plain ftp, 989/990 over tls.
> > 2) getHostName -- possibly subject to dns servers, /etc/resolv.conf,
> > /etc/hosts
> >     and /etc/nsswitch.conf.  getHostName causing dns operations that might
> > return
> >     different results due to multiple names/addresses
> > 3) Non thread-safe or not immutable session, e.g. heart beat/keep
> > alive/renegotiation
> >     on the channel modiying the session.
> > 4) Race conditions/sequence issues that could affect the socket
> > address:port,
> >     e.g. reading socket ports before the connect has finished.
> >
> > Goo luck figuring it out.
> >