Re: SSL modifications since 2.0 RC 1 ?

[Bruno Harbulot]

Hi Nicolas,

On 03/05/2010 15:09, Nicolas Rinaudo wrote:
> Hi Bruno,
>
> You certainly put a lot of effort into that !
>
> I have to admit that some of it went over my head - you obviously are
> a bit of an expert on the matter, which I'm not.
>
> If I understand you properly, the problem isn't Restlet, Safari, or
> even Java specific - it's a generic flaw (?) in client certificates
> management ?

Yes, it looks like it. I guess few services that rely on client
certificates reach that sort number of CAs they'd trust w.r.t. client
certificates. Usually, you'd tend to configure your server to accept
certificates for a smaller number of CAs, I think. 120+ is rather large 
and probably unusual.


> Which means that in my very specific, very selfish case, I should
> disable client certificate requests to make the problem go away.
> Which also means getting rid of the Simple connector, since this is
> hardcoded and can't be modified.
>
> Is that a fair summary, or did I misunderstand you even more badly
> than I thought ?

There are a few options:

1. Send an e-mail on the Simple framework list to request the feature. 
I'm afraid I don't have any spare time to do it, but the maintainer of 
Simple doesn't seem to be against the idea. Of course, that could take a 
bit of time to be implemented, but I guess it's worth asking. (Once it's 
in Simple, in a version that's then integrated in Restlet, adapting the 
connector should be straightforward.)

2. Use another connector and don't enable client certificate negotiation 
(the default in the other Restlet connectors).

3. Keep using Simple (with optional client-certificate negotiation), but 
use a smaller truststore (Note that you can't use an empty truststore.)
The easy way to do this would be to use your keystore as a truststore 
too (configuring the "truststore*" properties in addition to the 
"keystore*" properties to use the same corresponding values). You 
probably won't have more than your server certificate or perhaps the CA 
certificates in its chain, so you won't get anywhere near the limit.


Best wishes,

Bruno.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2602692

RE: Re: SSL modifications since 2.0 RC 1 ?

[Nicolas Rinaudo]

Hi Bruno,

You certainly put a lot of effort into that !

I have to admit that some of it went over my head - you obviously are a bit of 
an expert on the matter, which I'm not.

If I understand you properly, the problem isn't Restlet, Safari, or even Java 
specific - it's a generic flaw (?) in client certificates management ?

Which means that in my very specific, very selfish case, I should disable 
client certificate requests to make the problem go away. Which also means 
getting rid of the Simple connector, since this is hardcoded and can't be 
modified.

Is that a fair summary, or did I misunderstand you even more badly than I 
thought ?

Nicolas

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2601883

Re: SSL modifications since 2.0 RC 1 ?

[Bruno Harbulot]

On 30/04/2010 16:06, Bruno Harbulot wrote:
> Hi Nicolas,
>
> On 28/04/2010 12:55, Nicolas Rinaudo wrote:
>> This might be an important bit of information. After running a few more 
>> tests, I realised that Safari would:
>> - fail ignoring certificates if the server is running on OS X.
>> - succeed in ignoring certificates if the server is running on Debian Lenny 
>> (5.0)
>>
>> This might be an OS X only issue after all.
>
> I've looked a bit more into this issue, and it doesn't seem OSX-specific
> (on the server side) unfortunately. It's not even specific to
> self-signed certificates (I've tried with a trusted cert), the Simple
> connector or Restlet.
> I've managed to reproduce it with a basic Jetty server [1] running with
> the Sun JVM on a Linux box.
>
> It has similar symptoms to the buffer issue we had a few weeks ago [2],
> but I don't know whether it's a Java or a Safari problem at this stage.
>
> It appears with Simple, because Simple always requests (wants) a client
> certificate. It also happens with Jetty if it's configured to do so.
>
> To (try to) keep it short, when a TLS server requests a client
> certificate during the handshake, and extra TLS message is sent
> (CertificateRequest), which contains a list of the names of the CAs from
> which the server would be willing to accept client certificates.
> In Java, this list is automatically populated by the default SSLContext
> with the list of names corresponding to the certificates held in the
> truststore. The more certificates in the truststore, the longer the
> list, and thus the bigger the packet.
>
> On the current OSX 10.6, the default truststore [3] seems to have about
> 160 certificates, whereas on an Ubuntu 9.10 (Sun JVM) the default trust
> store contains about 75.
> When I use the Mac's truststore on the Linux box, this fails too. When I
> use a smaller truststore on the Mac, it works there.
>
> I've tried to debug the SSL handshake on the Java side and it looks like
> it works fine, internally; however, when looking at the packets with
> WireShark, not everything sent by the server according to the Java
> debugging logs seems to be effectively sent.
> I suspect this is a buffer size problem similar to [2], although in this
> case, it happens with other servers, using NIO or BIO.
>
>
> A workaround would be to specify a smaller truststore or to turn off the
> optional client-certificate authentication.


It looks like it's a more general problem, with some buffer stack 
settings in various TLS stacks.

I've just tried to set up Apache Httpd 2.2 with a large number of 
certificates too. Above about 150 DNs, it doesn't even accept 
connections from either Firefox or the OpenSSL test client (I suppose 
this number may vary slightly depending the length of the distinguished 
names in the certificates). This makes the server send something around 
22000 bytes during the handshake.

When Apache Httpd is configured with 118 CA certificates (again the 
exact number may vary), Firefox and the OpenSSL client can connect to 
it, but not Safari. (The server sends about 18000 bytes.)


Best wishes,

Bruno.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2599850

Re: SSL modifications since 2.0 RC 1 ?

[Bruno Harbulot]

Hi Nicolas,

On 28/04/2010 12:55, Nicolas Rinaudo wrote:
> This might be an important bit of information. After running a few more 
> tests, I realised that Safari would:
> - fail ignoring certificates if the server is running on OS X.
> - succeed in ignoring certificates if the server is running on Debian Lenny 
> (5.0)
>
> This might be an OS X only issue after all.

I've looked a bit more into this issue, and it doesn't seem OSX-specific 
(on the server side) unfortunately. It's not even specific to 
self-signed certificates (I've tried with a trusted cert), the Simple 
connector or Restlet.
I've managed to reproduce it with a basic Jetty server [1] running with 
the Sun JVM on a Linux box.

It has similar symptoms to the buffer issue we had a few weeks ago [2], 
but I don't know whether it's a Java or a Safari problem at this stage.

It appears with Simple, because Simple always requests (wants) a client 
certificate. It also happens with Jetty if it's configured to do so.

To (try to) keep it short, when a TLS server requests a client 
certificate during the handshake, and extra TLS message is sent 
(CertificateRequest), which contains a list of the names of the CAs from 
which the server would be willing to accept client certificates.
In Java, this list is automatically populated by the default SSLContext 
with the list of names corresponding to the certificates held in the 
truststore. The more certificates in the truststore, the longer the 
list, and thus the bigger the packet.

On the current OSX 10.6, the default truststore [3] seems to have about 
160 certificates, whereas on an Ubuntu 9.10 (Sun JVM) the default trust 
store contains about 75.
When I use the Mac's truststore on the Linux box, this fails too. When I 
use a smaller truststore on the Mac, it works there.

I've tried to debug the SSL handshake on the Java side and it looks like 
it works fine, internally; however, when looking at the packets with 
WireShark, not everything sent by the server according to the Java 
debugging logs seems to be effectively sent.
I suspect this is a buffer size problem similar to [2], although in this 
case, it happens with other servers, using NIO or BIO.


A workaround would be to specify a smaller truststore or to turn off the 
optional client-certificate authentication.


Best wishes,

Bruno.


[1] 
[2] 

[3] /Library/Java/Home/lib/security/cacerts
[4] /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2599797

RE: Re: SSL modifications since 2.0 RC 1 ?

[Nicolas Rinaudo]

This might be an important bit of information. After running a few more tests, 
I realised that Safari would:
- fail ignoring certificates if the server is running on OS X.
- succeed in ignoring certificates if the server is running on Debian Lenny 
(5.0)

This might be an OS X only issue after all.

Nicolas

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2597997

RE: Re: SSL modifications since 2.0 RC 1 ?

[Nicolas Rinaudo]

Hey Bruno,

Cheers, that clarified lots of SSL things for me and allowed me to fix the RC 3 
client as you suggested.

I'm still a bit confused about OS X Safari refusing connections, though - and 
wondering whether the same issue affects properly signed certificates (as 
opposed to self-signed ones). Do you have any idea what could cause this ? Is 
this something I should file a bug report for - after all, while Safari doesn't 
have that huge a market share, the fact that Restlet can't seem to serve HTTPS 
requests to it seems rather critical to me...

Thanks again !

Nicolas

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2597872

Re: SSL modifications since 2.0 RC 1 ?

[Bruno Harbulot]

Hi Nicolas,

Nicolas Rinaudo wrote:
> First, thanks for taking the time to look into this, I really appreciate it.
> 
> Now, to answer your post.
> 
>> 2. By default, the SSLContext (on the server connectors) is created by 
>> the DefaultSslContextFactory, which follows the defaults of the JSSE Ref 
>> guide by default. It will use javax.net.ssl.keyStore, 
>> javax.net.ssl.trustStore and related properties if specified, otherwise, 
>> the keystore is unspecified (you'd always have to configure it anyway) 
>> and the truststore is based on the CA certificates bundled with the JRE.
> 
> I'm not sure I follow. Do you mean that in order to configure my server side 
> keystore, I need to use the corresponding system properties ?
> What I'm doing is initialising the connector with parameters initialised as 
> follows:
> 
> parameters = new Vector();
> parameters.add(new Parameter("keystorePath", keystorePath));
> parameters.add(new Parameter("keystorePassword", keystorePassword));
> parameters.add(new Parameter("keyPassword",  keyPassword));
> 
> Has that changed ?

That hasn't changed. I don't usually use vectors, but change the 
existing parameters instead. I guess it's the same end-result.

Series parameters = context.getParameters();
parameters.add("keystorePath", ...);
parameters.add("keystorePassword", ...);
parameters.add("keyPassword", ...);
parameters.add("truststorePath", ...);
parameters.add("truststorePassword", ...);


What I meant when I was talking about the system properties is that the 
DefaultSslContextFactory works as follows (it's initialised with the 
parameters and falls back to system properties or default values):

- For the keystore:
   1. If 'keystorePath' is specified in the connector's context 
parameters (as above), those values are used.
   2. Failing (1), if the 'javax.net.ssl.keyStore' system property is used.
   3. Failing (1) and (2): there's no default value. If you want to use 
a keystore, you must specify it.

- For the truststore:
   1. If 'truststorePath' is specified in the connector's context 
parameters (as above), those values are used.
   2. Failing (1), if the 'javax.net.ssl.trustStore' system property is 
used.
   3. Failing (1) and (2): the JVM's default value is used. On the Sun 
JVM, that store is in $JAVA_HOME/security/cacerts.


If you're only setting the keystore and not the truststore, the JVM 
default value will be used. This should be fine for your server, since 
you're not using client certificates.


>> In addition, the Simple connector is set up to ask for an optional 
>> client certificate (that's hard-coded in Simple). If the client sends 
>> one it doesn't like, this would cause the connection to break.
> 
> Right, that might explain things.
> On the client side, I'm using the internal connector without any specific 
> configuration, except for the following code executed in our test cases:
> 
> SSLContext sc = SSLContext.getInstance("SSL");
> sc.init(null, new TrustManager[] {new X509TrustManager() {
> public X509Certificate[] getAcceptedIssuers() {return null;}
> public void checkServerTrusted(X509Certificate[] certs, String authType) 
> throws CertificateException {}
> public void checkClientTrusted(X509Certificate[] certs, String authType) 
> throws CertificateException {}
> }}, new SecureRandom());
> 
> HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
> HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
> public boolean verify(String urlHostName, SSLSession session) {return 
> true;}
> });
> 
> I don't really see how that could result in the client sending an odd 
> certificate, but I'm a bit out of my depths here and I might very well have 
> overlooked something.

Indeed, since your array of KeyManagers is null, that SSLContext won't 
provide a client certificate to send (so that's not the problem).

I think the problem comes from the fact you're setting the 
HttpsURLConnection.setDefaultSSLSocketFactory directly. The Restlet Net 
connectors doesn't use the java.net default SSLSocketFactory at all now. 
To harmonise the configuration, all connectors use the Restlet 
SslContextFactory (and implicitly its DefaultSslContextFactory if none 
is specified explicitly, with the behaviour described above).
This change was made between RC1 and RC2, so that's probably why you get 
the problem. The benefits of this change are that you can now use the 
same settings whether you're using the Net or the Apache HttpClient 
connector (whereas the code you had above was specific to the Net 
connector and affecting all the HttpsURLConnections); it also makes the 
configuration of the client connectors similar to that of the server 
connectors (i.e. via the 'sslContextFactory' attribute).


To fix this, here is how it can be done on the client side (based on 
your code):

final SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, new TrustManager[] {new X509TrustManager() {
  public X509Ce

RE: Re: SSL modifications since 2.0 RC 1 ?

[Nicolas Rinaudo]

First, thanks for taking the time to look into this, I really appreciate it.

Now, to answer your post.

> 2. By default, the SSLContext (on the server connectors) is created by 
> the DefaultSslContextFactory, which follows the defaults of the JSSE Ref 
> guide by default. It will use javax.net.ssl.keyStore, 
> javax.net.ssl.trustStore and related properties if specified, otherwise, 
> the keystore is unspecified (you'd always have to configure it anyway) 
> and the truststore is based on the CA certificates bundled with the JRE.

I'm not sure I follow. Do you mean that in order to configure my server side 
keystore, I need to use the corresponding system properties ?
What I'm doing is initialising the connector with parameters initialised as 
follows:

parameters = new Vector();
parameters.add(new Parameter("keystorePath", keystorePath));
parameters.add(new Parameter("keystorePassword", keystorePassword));
parameters.add(new Parameter("keyPassword",  keyPassword));

Has that changed ?

> In addition, the Simple connector is set up to ask for an optional 
> client certificate (that's hard-coded in Simple). If the client sends 
> one it doesn't like, this would cause the connection to break.

Right, that might explain things.
On the client side, I'm using the internal connector without any specific 
configuration, except for the following code executed in our test cases:

SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, new TrustManager[] {new X509TrustManager() {
public X509Certificate[] getAcceptedIssuers() {return null;}
public void checkServerTrusted(X509Certificate[] certs, String authType) 
throws CertificateException {}
public void checkClientTrusted(X509Certificate[] certs, String authType) 
throws CertificateException {}
}}, new SecureRandom());

HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
public boolean verify(String urlHostName, SSLSession session) {return true;}
});

I don't really see how that could result in the client sending an odd 
certificate, but I'm a bit out of my depths here and I might very well have 
overlooked something.

> They're not, but not all connectors support them in the same way 
> unfortunately (in some you can enable, in some you can disable).

Ok, I guess that Simple doesn't support this then. That would explain why I 
can't change my cipher suites.


Thanks !

Nicolas

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2596684

Re: SSL modifications since 2.0 RC 1 ?

[Bruno Harbulot]

Nicolas Rinaudo wrote:
>> Could you clarify what you mean by accept/ignore? I'm not sure what this 
>> means in the context of Firefox/Safari.
> 
> Right, sorry, that wasn't very clear.
> 
> "Accept": the browser will load the page without complaint.
> 
> "Refuse": the browser will fail to load the page with an error message such 
> as "Safari can’t establish a secure connection to the server 'localhost'."
> 
> "Ignore": instructing the browser to ignore the fact that the certificate is 
> self-signed - adding an exception in Firefox, for example.
> 
> All the tests I've described before are on OS X.

OK, from what you're saying, Firefox and Curl work as expected, Safari 
doesn't and your Restlet 2.0-RC3 based client doesn't either.

(I'll leave Safari aside for the moment, as I don't have an OSX machine 
with me right now.)

The main changes that were made regarding SSL between RC1 and RC3 are:

1. Clients no longer use $HOME/.keystore as their keystore by default 
(it has to be specified if the client wants to use a client-certificate).

2. By default, the SSLContext (on the server connectors) is created by 
the DefaultSslContextFactory, which follows the defaults of the JSSE Ref 
guide by default. It will use javax.net.ssl.keyStore, 
javax.net.ssl.trustStore and related properties if specified, otherwise, 
the keystore is unspecified (you'd always have to configure it anyway) 
and the truststore is based on the CA certificates bundled with the JRE.

This second change shouldn't break the existing connectors, since it's 
how they were initialised anyway (except that now, the code is in one 
place instead of copied across into each connector).
It does change the way the Simple connector works, because the simple 
connector was using the keystore settings for the truststore too.


In addition, the Simple connector is set up to ask for an optional 
client certificate (that's hard-coded in Simple). If the client sends 
one it doesn't like, this would cause the connection to break.


>> are you using client-certificates?
>> Could you explain what configuration you use for the client? (In 
>> particular w.r.t the trust store?)
> 
> I'm not using client-certificates, no.
> To be honest, I've no idea what a trust store is. The only thing I can think 
> of that might be related to that is the code we use in our tests to disable 
> SSL certificate validation:
> - set the default host name verifier to an instance that will accept anything.
> - set the trust manager to a pass-through implementation.

The trust store is the store used by most trust managers (in particular 
the default one) to load its trusted certificates from. If your client 
sets its own trust manager as a pass-through implementation, it's likely 
not to be used.

> I'd be happy to post the code if you need me to.

That could help indeed. It might have to do with how this trust manager 
is written and passed to the connectors.


>> for example, you would have to 
>> put your server's self-signed cert into the client's truststore for it 
>> to be trusted by the client).
> 
> This confuses me a bit - I thought that's exactly what I did when I told 
> Safari to add the certificate to the list of trusted certificates. Once I've 
> done that, however, Safari still refuses to load pages.
> 
>> I'm not sure where the change in cipher suites comes from, 
>> but it shouldn't affect how the certificates are trusted.
> 
> What confuses me is that even using the "enabledCipherSuites" and 
> "disabledCipherSuites", I can't change these. Are these instructions ignored 
> in the new version ?

They're not, but not all connectors support them in the same way 
unfortunately (in some you can enable, in some you can disable). There's 
little we can do about it, since it depends on the underlying library 
support (I got a patch in for Jetty a few weeks ago, but I'm not sure 
it's made it into the release yet).


Best wishes,

Bruno.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2595999

RE: Re: SSL modifications since 2.0 RC 1 ?

[Nicolas Rinaudo]

> Could you clarify what you mean by accept/ignore? I'm not sure what this 
> means in the context of Firefox/Safari.

Right, sorry, that wasn't very clear.

"Accept": the browser will load the page without complaint.

"Refuse": the browser will fail to load the page with an error message such as 
"Safari can’t establish a secure connection to the server 'localhost'."

"Ignore": instructing the browser to ignore the fact that the certificate is 
self-signed - adding an exception in Firefox, for example.

All the tests I've described before are on OS X.

> are you using client-certificates?
> Could you explain what configuration you use for the client? (In 
> particular w.r.t the trust store?)

I'm not using client-certificates, no.
To be honest, I've no idea what a trust store is. The only thing I can think of 
that might be related to that is the code we use in our tests to disable SSL 
certificate validation:
- set the default host name verifier to an instance that will accept anything.
- set the trust manager to a pass-through implementation.

I'd be happy to post the code if you need me to.

> for example, you would have to 
> put your server's self-signed cert into the client's truststore for it 
> to be trusted by the client).

This confuses me a bit - I thought that's exactly what I did when I told Safari 
to add the certificate to the list of trusted certificates. Once I've done 
that, however, Safari still refuses to load pages.

> I'm not sure where the change in cipher suites comes from, 
> but it shouldn't affect how the certificates are trusted.

What confuses me is that even using the "enabledCipherSuites" and 
"disabledCipherSuites", I can't change these. Are these instructions ignored in 
the new version ?

Nicolas

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2595972

Re: SSL modifications since 2.0 RC 1 ?

[Bruno Harbulot]

Hi Nicolas,

Nicolas Rinaudo wrote:
> Hey,
> 
> We've just upgraded form RC 1 to RC 3 (we skipped RC 2 due to blocking 
> issues), and there appears to have been some changes in the way SSL keystores 
> are managed - our test self-signed certificate that worked perfectly with RC 
> 1 now has issues with RC 3.
> 
> The behaviour is a bit odd:
> - Firefox accepts it after having been told to ignore it.
> - Safari refuses it, whether or not it has been told to ignore it.

Could you clarify what you mean by accept/ignore? I'm not sure what this 
means in the context of Firefox/Safari.

In Firefox, all I tend to see is 'Get me out of here!', 'I understand 
the risks' -> 'Add exception' (and perhaps 'Permanently store this 
exception').

(Is it Safari on Mac or Windows, btw?)

> - curl accepts it with the -k flag

That should always work indeed, since it doesn't verify the certificate 
of the server at all.

> - connecting using an RC 1 powered Java client works, an RC 3 powered one 
> fails.

Are you using client-certificates?
Could you explain what configuration you use for the client? (In 
particular w.r.t the trust store?)


> From what I've found, it appears that there were some modifications in 
> keystore management, but the only thing I could find was "SSL keystores 
> configuration was adjusted for simplicity purpose" in the RC 2 release notes. 
> Is there a list of what precisely these changes are I can find somewhere ?
> 
> I don't know whether that's useful, but:
> - we're using the Simple web server.
> - querying our server with curl, the only differences I could find between RC 
> 1 and RC 3 were: "SSL connection using EDH-RSA-DES-CBC3-SHA" (RC 1) and "SSL 
> connection using DHE-RSA-AES256-SHA" (RC 3).

One of the changes that was made was that the Simple connector was using 
the keystore for both the keystore and the truststore. Now, the 
truststore is the default JRE truststore unless explicitly specified 
(which is more correct), like it was the case for the other connectors 
(Jetty, Grizzly).
The keystore is what has the private key and the certificate that are 
local (server cert+priv. key on the server and client cert+priv. key on 
the client). The truststore is the repository of trust anchors used to 
evaluate trust in the remote certificate (for example, you would have to 
put your server's self-signed cert into the client's truststore for it 
to be trusted by the client).

I'm not sure where the change in cipher suites comes from 
(EDH-RSA-DES-CBC3-SHA/DHE-RSA-AES256-SHA), but it shouldn't affect how 
the certificates are trusted.


Best wishes,

Bruno.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2595939

SSL modifications since 2.0 RC 1 ?

[Nicolas Rinaudo]

Hey,

We've just upgraded form RC 1 to RC 3 (we skipped RC 2 due to blocking issues), 
and there appears to have been some changes in the way SSL keystores are 
managed - our test self-signed certificate that worked perfectly with RC 1 now 
has issues with RC 3.

The behaviour is a bit odd:
- Firefox accepts it after having been told to ignore it.
- Safari refuses it, whether or not it has been told to ignore it.
- curl accepts it with the -k flag
- connecting using an RC 1 powered Java client works, an RC 3 powered one fails.

>From what I've found, it appears that there were some modifications in 
>keystore management, but the only thing I could find was "SSL keystores 
>configuration was adjusted for simplicity purpose" in the RC 2 release notes. 
>Is there a list of what precisely these changes are I can find somewhere ?

I don't know whether that's useful, but:
- we're using the Simple web server.
- querying our server with curl, the only differences I could find between RC 1 
and RC 3 were: "SSL connection using EDH-RSA-DES-CBC3-SHA" (RC 1) and "SSL 
connection using DHE-RSA-AES256-SHA" (RC 3).

Any help or hints at where to look at would be greatly appreciated !

Cheers,
Nicolas

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2595919