I made some updates to the Certificate Verification Service to make it more general:
- Added the validation of client certificates (instead of only server certs)
- Respect the javax.net.ssl.* properties (which allow to override the systems default keystore)
- Replaced the requirement to supply a destination port number for TrustManagers or SSLContexts by simply supplying the message why the validation failed. (Displaying the port number to the user rarely makes sense, and there are situations where no port is involved - e.g. when validating a client certificate received via MIKEY).
- Method to inject a certificate to trust. Although not yet implemented in any GUI, this could be used to manually add a trusted certificate to Jitsis truststore (jssecacerts)
The patch also includes the changes to the protocols using the CertificateValidationService.
I've just committed and your second patch for today and acked it.
This was almost straight commit with only two modifications, again 1.6 java.
- the IOException(Throwable) constructor
- SSLContext.getDefault()
Cheers and thanks
damecho
···
On Sat, Feb 12, 2011 at 3:21 AM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:
Moin
I made some updates to the Certificate Verification Service to make it more general:
- Added the validation of client certificates (instead of only server certs)
- Respect the javax.net.ssl.* properties (which allow to override the systems default keystore)
- Replaced the requirement to supply a destination port number for TrustManagers or SSLContexts by simply supplying the message why the validation failed. (Displaying the port number to the user rarely makes sense, and there are situations where no port is involved - e.g. when validating a client certificate received via MIKEY).
- Method to inject a certificate to trust. Although not yet implemented in any GUI, this could be used to manually add a trusted certificate to Jitsis truststore (jssecacerts)
The patch also includes the changes to the protocols using the CertificateValidationService.
I've just committed and your second patch for today and acked it.
This was almost straight commit with only two modifications, again 1.6
java. - the IOException(Throwable) constructor - SSLContext.getDefault()
Thanks!
As getDefault is not available, we might resort to a simpler replacement than the actual code. Per Javadoc (and trying out) of .init all parameters are allowed to be null, so there is no need trying to obtain defaults by ourself. But I have to investigate this further - the CertificateVerifactionService uses a similar lookup which might be replaced by null... I had a reason not to use null there, but I forgot why.
The 1.5 variant would be ctx = SSLContext.getInstance("tls");
Ctx.init(null, null, null);
So reflection would actually be worse.
Ingo
···
On 17.03.2011, at 11:44, "Emil Ivov" <emcho@jitsi.org> wrote:
On 17 mars 2011, at 10:53, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:
Hey
I've just committed and your second patch for today and acked it.
This was almost straight commit with only two modifications, again 1.6
java. - the IOException(Throwable) constructor - SSLContext.getDefault()
Thanks!
As getDefault is not available, we might resort to a simpler replacement than the actual code.
What we tend to do in such cases (i.e. where the 1.5 alternative involves undesired tradeoffs) is to use the 1.6 method through reflection and only fallback to the alternative if necessary. Most of our users on Windows recent Macs, and Linux would hence be able to use the 1.6 variant.
--sent from my mobile
Per Javadoc (and trying out) of .init all parameters are allowed to be null, so there is no need trying to obtain defaults by ourself. But I have to investigate this further - the CertificateVerifactionService uses a similar lookup which might be replaced by null... I had a reason not to use null there, but I forgot why.
The 1.5 variant would be ctx = SSLContext.getInstance("tls");
Ctx.init(null, null, null);
So reflection would actually be worse.
Not sure I follow.
Emil
···
Ingo
On 17.03.2011, at 11:44, "Emil Ivov" <emcho@jitsi.org> wrote:
On 17 mars 2011, at 10:53, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:
Hey
I've just committed and your second patch for today and acked it.
This was almost straight commit with only two modifications, again 1.6
java. - the IOException(Throwable) constructor - SSLContext.getDefault()
Thanks!
As getDefault is not available, we might resort to a simpler replacement than the actual code.
What we tend to do in such cases (i.e. where the 1.5 alternative involves undesired tradeoffs) is to use the 1.6 method through reflection and only fallback to the alternative if necessary. Most of our users on Windows recent Macs, and Linux would hence be able to use the 1.6 variant.
--sent from my mobile
Per Javadoc (and trying out) of .init all parameters are allowed to be null, so there is no need trying to obtain defaults by ourself. But I have to investigate this further - the CertificateVerifactionService uses a similar lookup which might be replaced by null... I had a reason not to use null there, but I forgot why.
I'll come back to this later.
Ingo
--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31
The 1.5 variant would be ctx = SSLContext.getInstance("tls");
Ctx.init(null, null, null);
So reflection would actually be worse.
Not sure I follow.
In Java 1.6 I'd do:
SSLContext ctx = SSLContext.getDefault();
And in Java 1.5 an equivalent context can (as far as I can tell now) be obtained by:
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, null, null);
Therefore using reflection for distinguishing between these two variants seems a bit overkill.
and acked it.