synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Supporting Multiple SSL Configurations at Sender
Date Tue, 21 Jul 2009 10:22:21 GMT
On Tue, Jul 21, 2009 at 12:08, Hiranya Jayathilaka<hiranya911@gmail.com> wrote:
> Hi Folks,
>
> I did some testing using two Axis2 instances each using its own
> certificates. I managed to get Synapse to connect to both servers using a
> single truststore. I had to put both client certs as well as the CA cert in
> the Synapse truststore for this scenario to work. So I guess our current
> implementation is good enough for a great extent.
>
> However the problem I have is the way Synapse (or rather the Java SSL API)
> selects the client cert at runtime. As Andreas has mentioned it seems to be
> using some data sent by the server in selecting the correct client cert. I
> tried to find some documentation which properly explains this procedure but
> still couldn't find something satisfactory. However according to most
> resources and explanation provided by Oleg, it seems that client can decide
> which cert to present the way it wishes. In that case the above scenario
> might fail in certain situations.
>
> So IMHO the best option (most scalable and robust) we got is to implement a
> custom IOEventDispatch. WDYT?

Personally, I think that the HTTP(S) transport is already complex
enough and that we should only add to that complexity if there is a
good reason to do so. Assuming that the client certificate selection
algorithm doesn't give the expected results, I think that implementing
a custom IOEventDispatch is only the second best solution. We should
first investigate the possibility to change the behavior of the key
manager. Since this is the component that selects the client
certificate, from a design perspective it would be the right place do
implement custom behavior. This approach would also have the advantage
of isolating the changes from the core of the transport.

Andreas

> Thanks,
> Hiranya
>
>
>
> On Tue, Jul 21, 2009 at 3:25 PM, Andreas Veithen <andreas.veithen@gmail.com>
> wrote:
>>
>> On Tue, Jul 21, 2009 at 11:30, Oleg Kalnichevski<olegk@apache.org> wrote:
>> > On Tue, Jul 21, 2009 at 11:22:58AM +0200, Andreas Veithen wrote:
>> >> > Well, if not through different stores, how can we let the KeyManager
>> >> > know
>> >> > what cert to use for this particular endpoint?
>> >>
>> >> If I remember well, this is how it works: during the handshake, the
>> >> server presents a list of trusted CAs to the client. The client than
>> >> selects the certificate that is signed (directly or indirectly) by
>> >> that CA and uses that to authenticate. I'm pretty sure this is what
>> >> happens when you create a java.net.URL with the https scheme and call
>> >> openConnection on it. Since behind the scene this uses an SSLContext,
>> >> chances are high that it also works with our HTTPS transport (or that
>> >> it would be pretty easy to make it work).
>> >>
>> >> Of course this only satisfies the requirement if the two endpoints use
>> >> different CAs, which should be the usual case.
>> >>
>> >> Andreas
>> >>
>> >
>> > Hi Andreas
>> >
>> > I may be wrong about it but I believe the client can present whatever
>> > client
>> > cert it pleases. That cert does not _have_ to be signed by one of the
>> > trusted
>> > CA certs sent to client by the server. For instance, common browsers
>> > simply pop
>> > up a UI dialog and let you pick any client certificate available in the
>> > certificate store, if the server requests client authentication in the
>> > course
>> > of SSL context negotiation.
>> >
>> > Oleg
>> >
>>
>> That is possible, but it is only relevant for a scheme where the
>> consumer of the service creates a certificate himself (typically a
>> self-signed certificate) and somehow registers that with the provider
>> of the service. This implies that the provider has to manage a list of
>> recognized client certificates to authenticate the client. I don't
>> think that is a usual scheme for Web services (BTW, how would you do
>> that with Axis2?), but that it is more usual for the provider to issue
>> certificates to the consumer, so that authentication is based on the
>> signature on the client certificate. But again, this is a question
>> about the requirements.
>>
>> Andreas
>>
>> >
>> >
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> > For additional commands, e-mail: dev-help@synapse.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> Hiranya Jayathilaka
> Software Engineer;
> WSO2 Inc.;  http://wso2.org
> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org


Mime
View raw message