RE: Re: SSL modifications since 2.0 RC 1 ?

2010-05-03 Thread 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=4447dsMessageId=2601883


RE: Re: SSL modifications since 2.0 RC 1 ?

2010-04-28 Thread 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=4447dsMessageId=2597872


RE: Re: SSL modifications since 2.0 RC 1 ?

2010-04-28 Thread 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=4447dsMessageId=2597997


RE: Re: SSL modifications since 2.0 RC 1 ?

2010-04-27 Thread 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 VectorParameter();
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=4447dsMessageId=2596684


RE: Re: SSL modifications since 2.0 RC 1 ?

2010-04-26 Thread 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=4447dsMessageId=2595972