[lug] FTPS + SSL parameters question...

[duboulder]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20191012/d592b545/attachment-0001.html>