Re: [Openvpn-devel] Topics for today's community meeting

[Timothe L. <li...@ac...>]

On 24-Apr-14 10:52, George Ross wrote:
> On our server side the certificate chain goes: University CA -> School CA ->
> service-signing CA -> service cert.  The first two of these are kept
> off-line.  On the client side it goes: University CA -> School CA -> KCA ->
> kx509-cert.
>
> I wonder if that's just longer than most people use?
That may be, but it's the size of the signature, not the size of the 
certificate chain that's at issue.

Thanks for the information.  I'll do some more code browsing; it will 
help.  But I'm not optimistic that we'll figure this out before 
tonight's meeting.  I'm curious, but time-limited.

What happens is that the chain is hashed to form a fixed-length digest; 
the digest is then signed.  This is done to validate that the chain 
hasn't been tampered with in-transit.  Signing the hash means that the 
signature is over a fixed-length block, which prevents certain timing 
attacks.

In any case the signature (technically, digest+signature) size is 
independent of what's signed.

The error indicates that when signing the client certificate chain, the 
resulting digest is not the expected size.  It's entirely a client side 
issue; as a result the server isn't getting the client certificate.  
(That's why only the client log has a useful error. The server asks for 
the client certificate, never gets it & times-out, causing the handshake 
failure.)

That can happen if the wrong algorithm is used.  I still suspect that 
this is being triggered by using TLSV1.2.

When you're out of meeting mode, it will be useful to know whether 
forcing TLSV1.1 makes the problem disappear.

Any of the suggested patches should determine that.  The quickest and 
simplest is in

src/openvpn/ssl_openssl.c

The first line of tls_ctx_set_options() looks like:
longsslopt=SSL_OP_SINGLE_DH_USE|SSL_OP_NO_TICKET|SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3;

add | SSL_OP_NO_TLSv1_2

so it looks like

longsslopt=SSL_OP_SINGLE_DH_USE|SSL_OP_NO_TICKET|SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3| 
SSL_OP_NO_TLSv1_2;

This will prevent TLSv1.2 from being used. [Likewise, | 
SSL_OP_NO_TLSv1_1 | SSL_OP_TLS_V1_2 disables 1.1 and 1.2].

In case code inspection doesn't produce quick results...a thought:

I'm not quite there yet, but one approach would be to start a client in 
a debugger - easy enough as it's Linux.  How hard would it be to 
generate an expired /revoked certificate from your CA with a mismatched 
private key?  That (with the CA & intermediate certs, which are not 
secret) should reproduce the problem. You'd get a different error on the 
server if the client cert ever arrived there, which it doesn't in this 
case.

Such a certificate/keypair wouldn't allow access to your systems, but if 
it does reproduce the client-side problem, it would enable us (the real 
developers, and me since I'm curious) to work on it independently.  (The 
key mismatch would cause the signature not to validate; and expired + 
revoked should also refuse access.  The server certificate isn't 
involved; we can use any existing server.)