Thanks for your reply.
I have been able to figure out how to do this programmatically with the
simple client. Code looks like this :
ClientProxyFactoryBean factory = new ClientProxyFactoryBean();
factory.setServiceClass( PingService.class );
factory.setAddress( "https://localhost:8443/ca/pxws/1.0/ping"; );
PingService client = (PingService) factory.create();
Client proxy = ClientProxy.getClient( client );
HTTPConduit conduit = (HTTPConduit) proxy.getConduit();
TLSClientParameters tcp = new TLSClientParameters();
tcp.setTrustManagers( new TrustManager[]{ new
TrustAllX509TrustManager() } );
conduit.setTlsClientParameters( tcp );
More details on http://blog.progs.be
Thanks for the help,
Joachim
Arundel, Donal wrote:
>
> Hi Joachim,
>
> it sounds like the anonymous Diffie-Hellman ciphersuites might match
> your stated requirements more conveniently.
> No CAs are required here at all..
> Of course it depends on whether the server supports anonymous
> ciphersuites in the first place as to whether this is an option for you.
> You may not have control over the server.
>
> I would like though to point out the vulnerability downside of using
> anonymous ciphersuites, which is also the downside to lax CA certificate
> checking at the client side (as you are suggesting as a possibility).
>
> At a gut level people feel "I just encryption, I cant be bothered with
> the complexity of CA configuration - eugh!" :-)
> They just want to send stuff privately to another entity..
>
> The gotcha is that while it is possible to encrypt data between two
> parties using either of the mechanisms mentioned above (e.g. anonymous
> ciphersuites, or the "accept any CA" approach) they are open to a
> fundamental attack called "the man-in-the-middle attack" or MITM.
>
> Basically an attacker can "sit in the middle" between the intended
> recipient and the sender. The attacker won't be authenticated by the
> sender, and secure comms will be established between these two with the
> sender thinking he is talking to the intended target.
> Then the clever bit is that the attacker acts as a relay to the intended
> target and simply forwards data in either direction managing the two
> separate secure SSL connections.
> Of course the attacker is able to read all the data in either direction
> since it is the direct SSL peer of both the sender and the intended
> target.
>
> This is why one uses Certificate Authorities, and specifically why one
> does not accept just any Certificate authority since *anybody* can
> create a CA for their own purposes.
> The specification of Root certificate is a critical part of how SSL
> works in that places a base-line trust constraint that an attacker would
> have to surmount.
>
> That said if a client has no real security requirements relating to the
> data it obtains - it may suffice in some cases, once you understand the
> risks.
>
>>Is it possible to either specify directly that all certificates should
> be
>>accepted, or register your own TrustManager implementation which does
>>exactly that? This last case would also be useful for implementing more
>>strict checks that just comparing with a certificate store.
>
> I believe it is, I haven't done it myself though and don't have the API
> details to hand.
> If I get a chance later today I will see if I can root them out for you.
>
> Cheers,
> Donal
>
>
> -----Original Message-----
> From: triathlon98 [mailto:[EMAIL PROTECTED]
> Sent: 15 April 2008 15:59
> To: cxf-user@incubator.apache.org
> Subject: RE: how to let cxf client accept all/any certificates
>
>
> It is clear to me that certificates work like this.
> However, this already mixes two uses of SSL/certificates.
> One use is encrypting the data which is communicated, the other is
> verifying
> that the server is actually the correct one and not a spoof.
>
> When the only purpose is encrypting the data, you can easily use self
> signed
> certificates. In that case, you don't want the clients to fail because
> the
> server had a need to change the certificate.
>
> Is it possible to either specify directly that all certificates should
> be
> accepted, or register your own TrustManager implementation which does
> exactly that? This last case would also be useful for implementing more
> strict checks that just comparing with a certificate store.
>
> Kind regards,
> Joachim
>
>
>
> Arundel, Donal wrote:
>>
>> At the SSL protocol level the servers that a client will trust is
>> governed by the list of Certificate Authorities (CAs) that the client
> is
>> configured to trust.
>>
>> i.e. You need to configure your client to trust the *Issuing
> Certificate
>> Authority* that created the specific server certificate concerned.
>>
>> At a separate higher level there may be additional level application
>> specific constraints that one might want to apply to lock down things
>> further to individual server certificates if neccessary.
>> e.g. querying the TLS credentials and applying extra constraints on
> the
>> Subjects Common Name to limit things to a single server.
>>
>> Cheers,
>> Donal
>>
>
> --
> View this message in context:
> http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-
> tp15562373p16701169.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
>
--
View this message in context:
http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-tp15562373p16720852.html
Sent from the cxf-user mailing list archive at Nabble.com.
