[lug] FTPS + SSL parameters question...

[Bear Giles]

The somewhat confusing conclusion to this story is that the coworker I'm
covering for reports no problems accessing his local FTPS server. I don't
think it's a case of misconfiguration since he saw the same error messages
with the original implementation.

On Sat, Oct 12, 2019 at 11:58 AM Bear Giles <bgiles at coyotesong.com> wrote:

> 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.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Friday, October 11, 2019 2:25 PM, Bear Giles <bgiles at coyotesong.com>
>> wrote:
>>
>> AFAIK everything is identical. The only difference is that the
>> integration test is run in a small test class and the application is a
>> heavy monster. It's not "ear file on jboss"... but similar in the sense of
>> modules that run on top of a platform.
>>
>> There is a test framework that lives in the middle but I don't think it
>> will show anything different. My intuition is that it's something subtle
>> change due to running on top of the platform.
>>
>> (Hmm... could I create a module that just runs junit integration
>> tests....)
>>
>> The server's error message makes it look pretty clear that the problem is
>> that the connection is failing since I'm not reusing the SSL properties. At
>> least it's the same error I see with the integration tests when I either
>> don't create a cache entry or don't set a magic value in the system
>> properties. I know that's not the case though since I'm logging those
>> fields at the last point before it's entirely Apache commons-net code.
>>
>> This is more "java client" side than "server" side but it occurred to me
>> that one possible cause is if the cache lookup key is different. My code is
>>
>>     private void setSession(SSLSocket socket, SSLSession session) throws IOException
>> {
>>         final SSLSessionContext context = session.getSessionContext();
>>
>>         final String addr1 = String.format("%s:%d",
>> socket.getInetAddress().getHostName(),
>>                 socket.getPort()).toLowerCase(Locale.ROOT);
>>         final String addr2 = String.format("%s:%d",
>> socket.getInetAddress().getHostAddress(),
>>                 socket.getPort()).toLowerCase(Locale.ROOT);
>>         try {
>>             // sun.security.util.MemoryCache
>>             final Object cache = FieldUtils.readDeclaredField(context,
>> "sessionHostPortCache",
>>                     true);
>>             final Method put = cache.getClass().getDeclaredMethod("put",
>> Object.class,
>>                     Object.class);
>>             put.setAccessible(true);
>>             put.invoke(cache, addr1, session);
>>             put.invoke(cache, addr2, session);
>>             //logSSLSessionCache(context);
>>         } catch (Exception e) {
>>             throw new IOException(e);
>>         }
>>     }
>>
>> so I'm covering both the host name and IP address. I don't know why the
>> system would use a different value for the key.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Oct 11, 2019 at 11:27 AM duboulder <blug-mail at duboulder.com>
>> wrote:
>>
>>> Assuming your tests are connecting to the same ip/port/dns name as the
>>> app and you aren't having a source ip access problem, I wonder if you have
>>> the same jvm/jvm setup for the app vs tests.
>>>
>>> Does the ftps server give any details about the app connect failure? Or
>>> does the java class provide any details about the failure?
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Friday, October 11, 2019 10:03 AM, Bear Giles <bgiles at coyotesong.com>
>>> wrote:
>>>
>>> This is a stretch but I'm running out of ideas.
>>>
>>> We're trying to connect to an FTPS server in implicit mode. The server
>>> requires the data connection to use the same SSL parameters as the control
>>> connection as an authentication mechanism.
>>>
>>> Java isn't happy but I can force it by seeding the undocumented
>>> SSLSession cache.
>>>
>>> Bottom line is that my integration tests pass - I'm connecting to the
>>> (Filezilla) server...
>>>
>>> ... but my actual application fails. I've verified that everything is
>>> lined up and (AFAIK) it's creating the request with the correct SSL
>>> Parameters but something, somehow, is changing them in flight.
>>>
>>> I've checked with coworkers - we have a packet monitor but it doesn't do
>>> deep packet inspection. We don't have a network proxy. I can't think of
>>> anything else that would modify the SSL Parameters.
>>>
>>> Any ideas, esp. something that would appear in a Java environment?
>>>
>>> Unfortunately we can't ask the customer to change their server settings.
>>> We can't try switching to mutual authentication (using SSL keypairs) either.
>>>
>>> Thanks
>>>
>>>
>>> _______________________________________________
>>> Web Page:  http://lug.boulder.co.us
>>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>>> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>>>
>>
>> _______________________________________________
>> Web Page:  http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20191015/a5c47f26/attachment-0001.html>