[lug] FTPS + SSL parameters question...
Bear Giles
bgiles at coyotesong.com
Sat Oct 12 11:58:45 MDT 2019
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/20191012/60e1d29f/attachment-0001.html>
More information about the LUG
mailing list