quickfixj-users

Re: [Quickfixj-users] SSL with QuickFIX/J 1.1.0

[Steve B. <st...@te...>]

Hi Christian,

Can you look at the test log that Toli described to see what happened 
with the LogUtil test? It passes for me. My guess is that this is a 
locale-related problem. I removed the session settings for start and 
end day from the test in case that is what's causing the problem. 
Although it's a good idea to run the tests, you can also just 
build the QFJ jar without running the tests and doing a complete 
release build, which is relatively time consuming.

The SSL code is QFJ is heavily based on examples from the MINA
project. It's very possible that it could be extended to be more
flexible. I added SSL because I thought it would be useful to the
user community but I don't use it myself so any information and/or
patches you can provide would be appreciated.

Have you tried using the TrustManagerFactory technique you mentioned?
Does that work? I'm currently very busy with my job so I may not be
able to try it for several days.

Steve

Re: [Quickfixj-users] SSL with QuickFIX/J 1.1.0

[Christian Z. <chr...@re...>]

Thanks Steve, and thanks Toli,

I fixed the problem in LogUtilTest by setting the default locale to US 
in the setUp() method:

    protected void setUp() throws Exception {
        super.setUp();
        SystemTime.setTimeSource(new 
MockSystemTimeSource(System.currentTimeMillis()));
        Locale.setDefault(Locale.US);
    }

Now I'm wondering about the MultiAcceptorTest, which seems to be waiting 
on something to happen... but what? The junit text file is nearly empty, 
it just shows the name of the class. Is there any documentation about 
the unit tests? In the meantime I'll do my code changes without running 
the unit tests.

I'll be happy to share the changes for configuring a trust store when it 
works. I'm trying to add that to the QFJ config file.

Thanks for the prompt reply!

Regards,

Christian

Re: [Quickfixj-users] SSL with QuickFIX/J 1.1.0

[Toli K. <to...@ma...>]

Christian,

I wanted to follow-up on this - did you ever manage to successfully
get QFJ and SSL to work together?

I'm writing an app that connects to a broker that requires SSL, and
I'm having issues with QFJ working out-of-the-box.

I'm not very familiar with how SSL works, but if I understand it
correctly, there are 3 ways SSL authenticates:
1. client authenticates just the server
2. server authenticates just the client
3. both client and server need to authenticate each other.

I think QFJ may only be covering case 2: it looks at trust stores only
in the Acceptor mode (AbstractSocketAcceptor), while for case 3 to
work I believe the initiator needs to have an SSL context as well.

Just wanted to run this past people to see if my understanding is
correct, and whether or not QFJ currently handles specifying certs for
outgoing connections.

thanks.

On 5/16/07, Christian Zapf <chr...@re...> wrote:

> I'll be happy to share the changes for configuring a trust store when it
> works. I'm trying to add that to the QFJ config file.
-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

Re: [Quickfixj-users] SSL with QuickFIX/J 1.1.0

[Steve B. <st...@te...>]

> I wanted to follow-up on this - did you ever manage to successfully
> get QFJ and SSL to work together?
>
> I'm writing an app that connects to a broker that requires SSL, and
> I'm having issues with QFJ working out-of-the-box.
>
> I'm not very familiar with how SSL works, but if I understand it
> correctly, there are 3 ways SSL authenticates:
> 1. client authenticates just the server
> 2. server authenticates just the client
> 3. both client and server need to authenticate each other.

> I think QFJ may only be covering case 2: it looks at trust stores only
> in the Acceptor mode (AbstractSocketAcceptor), while for case 3 to
> work I believe the initiator needs to have an SSL context as well.

I'm not an SSL expert either, but I think QFJ is implementing case
1 rather than case 2. The primary purpose of SSL in QFJ is for encryption
rather than authentication. However, the server sends credentials to
to the client and the client must decide whether to trust them or not.
In that sense, the client is authenticating the server. Currently, the
client trusts all servers and this behavior needs to be more configurable.

> Just wanted to run this past people to see if my understanding is
> correct, and whether or not QFJ currently handles specifying certs for
> outgoing connections.

No, it doesn't support two way transport-level authentication. Isn't it
more common to handle client authentication at the application level
rather than at the transport level?

Steve

Re: [Quickfixj-users] SSL with QuickFIX/J 1.1.0

[Toli K. <to...@ma...>]

> No, it doesn't support two way transport-level authentication. Isn't it
> more common to handle client authentication at the application level
> rather than at the transport level?

Well, we have a broker that requires SSL-level authentication for all
incoming client connections.
So i'll take a look at how to get QFJ to send certificates in the
outgoing connections (as initiator) as well, and post the patch later.

Do you have any suggestions or tips on how to do that best? I will
probably try to generalize the initializeKeyManager code to be used in
InitiatorContextFactory as well, instead of just always returning a
null set of keyManagers there.

-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

Re: [Quickfixj-users] SSL with QuickFIX/J 1.1.0

[Christian Z. <chr...@re...>]

Hi Guys,

Sorry about the delay! All I can tell you for now about SSL in 
QuickFIX/J... is that I spent a couple of days trying, and I'm now back 
to Stunnel until my implementation is in production. I hope I'll be able 
to spend some time on the issue afterwards.

Regards,

Christian Zapf

Toli Kuznets wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>   
>> No, it doesn't support two way transport-level authentication. Isn't it
>> more common to handle client authentication at the application level
>> rather than at the transport level?
>>     
>
> Well, we have a broker that requires SSL-level authentication for all
> incoming client connections.
> So i'll take a look at how to get QFJ to send certificates in the
> outgoing connections (as initiator) as well, and post the patch later.
>
> Do you have any suggestions or tips on how to do that best? I will
> probably try to generalize the initializeKeyManager code to be used in
> InitiatorContextFactory as well, instead of just always returning a
> null set of keyManagers there.
>
>