RE: how to let cxf client accept all/any certificates
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
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:[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
RE: how to let cxf client accept all/any certificates
Cool, and thanks for posting back the answer :-)
-Original Message-
From: triathlon98 [mailto:[EMAIL PROTECTED]
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:[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
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.
RE: how to let cxf client accept all/any certificates
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
-Original Message-
From: yulinxp [mailto:[EMAIL PROTECTED]
Sent: 19 February 2008 18:24
To: cxf-user@incubator.apache.org
Subject: how to let cxf client accept all/any certificates
Below is my CXF client which use SSL. I have put server's certificate in
my
client side.
How to change it to let it accept all/any certificates from server??
QName SERVICE_NAME = new QName(http://spring.demo/;,
HelloWorldService);
HelloWorldService ss = new HelloWorldService(wsdlURL,
SERVICE_NAME);
HelloWorld port = ss.getHelloWorldPort();
org.apache.cxf.endpoint.Client c = ClientProxy.getClient(port);
HTTPConduit httpConduit = (HTTPConduit) c.getConduit();
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol(SSL);
try {
tlsParams.setKeyManagers(getKeyManagers());
tlsParams.setTrustManagers(getTrustManagers());
} catch (IOException e) {
e.printStackTrace();
}
httpConduit.setTlsClientParameters(tlsParams);
--
View this message in context:
http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-
tp15562373p15562373.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
RE: how to let cxf client accept all/any certificates
how to configure your client to trust the *Issuing Certificate
Authority*? Any code example?
Also what if server ca is self-assigned, how to handle in this case?
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
-Original Message-
From: yulinxp [mailto:[EMAIL PROTECTED]
Sent: 19 February 2008 18:24
To: cxf-user@incubator.apache.org
Subject: how to let cxf client accept all/any certificates
Below is my CXF client which use SSL. I have put server's certificate in
my
client side.
How to change it to let it accept all/any certificates from server??
QName SERVICE_NAME = new QName(http://spring.demo/;,
HelloWorldService);
HelloWorldService ss = new HelloWorldService(wsdlURL,
SERVICE_NAME);
HelloWorld port = ss.getHelloWorldPort();
org.apache.cxf.endpoint.Client c = ClientProxy.getClient(port);
HTTPConduit httpConduit = (HTTPConduit) c.getConduit();
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol(SSL);
try {
tlsParams.setKeyManagers(getKeyManagers());
tlsParams.setTrustManagers(getTrustManagers());
} catch (IOException e) {
e.printStackTrace();
}
httpConduit.setTlsClientParameters(tlsParams);
--
View this message in context:
http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-
tp15562373p15562373.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-tp15562373p15612155.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: how to let cxf client accept all/any certificates
Maybe try looking at the CXF demos - there is a WSDL first HTTPs demo
there.
Normally the CXF SSL trust information is specified through the spring
config.
Also what if server ca is self-assigned, how to handle in this case?
Generally a CA being self-signed doesn't make any difference to you,
it is actually the simplest CA case.
Please note that a CAs certificate is fundamentally different
to an applications certificate. i.e. There is no such thing as a
self-signed application cert.
So, a self-signed CA that signed a cert request for a server to create a
server certificate would simply mean that the chain length associated
with the servers certificate is 2.
If you are not using self-signed certificates then you are dealing with
CA chains in that a specific subordinate CA may be signed by a parent
CA.
If you only want to accept certificates issued by the subordinate CA
then only specify that CA as trusted, for all practical purposes this is
almost identical to using a self signed CA as mentioned above.
NB: Don't specify the parent CA (which itself may or may not be a
self-signed CA) unless you really do want to trust all certificates
issued by all CAs that the parent CA has signed.
Additionally, if you were to do this you would have to enable support
for cert-chaining in your applications to allow them to accept
application cert chains greater than length 2.
There are additional complexities with enabling cert chaining that I
wont go into now, but it sounds like you don't need to support chain
lengths greater than 2.
It might be an idea to have read up on the Java keytool and JSSE docs to
get an overview of the area?
There also are some excellent diagnostic and key/cert related utilities
(albeit C executables) available at www.openssl.org.
Specifically I find the openssl s_client and s_server utilties answer
almost all SSL diagnostic questions once you get familiar with them.
However they don't support the Java language proprietary Keytool JKS
format,
you would need to convert to PEM format.
While the openssl runtime proper does support PKCS#12 format, I don't
think they have updated the standalone utilities yet to support the
PKCS#12 from the command line.
Docs for these utilities are on the openssl website too.
Cheers,
Donal
-Original Message-
From: yulinxp [mailto:[EMAIL PROTECTED]
Sent: 21 February 2008 14:07
To: cxf-user@incubator.apache.org
Subject: RE: how to let cxf client accept all/any certificates
how to configure your client to trust the *Issuing Certificate
Authority*? Any code example?
Also what if server ca is self-assigned, how to handle in this case?
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
-Original Message-
From: yulinxp [mailto:[EMAIL PROTECTED]
Sent: 19 February 2008 18:24
To: cxf-user@incubator.apache.org
Subject: how to let cxf client accept all/any certificates
Below is my CXF client which use SSL. I have put server's certificate
in
my
client side.
How to change it to let it accept all/any certificates from server??
QName SERVICE_NAME = new QName(http://spring.demo/;,
HelloWorldService);
HelloWorldService ss = new HelloWorldService(wsdlURL,
SERVICE_NAME);
HelloWorld port = ss.getHelloWorldPort();
org.apache.cxf.endpoint.Client c =
ClientProxy.getClient(port);
HTTPConduit httpConduit = (HTTPConduit) c.getConduit();
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol(SSL);
try {
tlsParams.setKeyManagers(getKeyManagers());
tlsParams.setTrustManagers(getTrustManagers());
} catch (IOException e) {
e.printStackTrace();
}
httpConduit.setTlsClientParameters(tlsParams);
--
View this message in context:
http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-
tp15562373p15562373.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
Re: how to let cxf client accept all/any certificates
anybody knows? according to XFire document, XFire can do it. So how to do it in CXF client? -- View this message in context: http://www.nabble.com/how-to-let-cxf-client-accept-all-any-certificates-tp15562373p15597788.html Sent from the cxf-user mailing list archive at Nabble.com.
