[lug] FTPS + SSL parameters question...

[Bear Giles]

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/20191011/1dec48b2/attachment.html>