cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arundel, Donal" <donal.arun...@iona.com>
Subject RE: how to let cxf client accept all/any certificates
Date Wed, 16 Apr 2008 14:07:43 GMT
Cool, and thanks for posting back the answer :-)

-----Original Message-----
From: triathlon98 [mailto:joachim@triathlon98.com] 
Sent: 16 April 2008 11:56
To: cxf-user@incubator.apache.org
Subject: RE: how to let cxf client accept all/any certificates


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:joachim@triathlon98.com] 
> 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.

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
View raw message