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

[Timothe Litt]

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.

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





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

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 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]. 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.)

smime.p7s
Description: S/MIME Cryptographic Signature