openvpn-devel

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

[George R. <gd...@in...>]

Sorry, I'm in meeting mode at the moment.  Just time to fire in a quick 
comment here...

> George's is not known - but the best guess is that he may be using 
> another external key loader (such as pkcs11, or maybe an android/ios 
> client.

Nope.  Just the following:

# TLS parameters
dh /etc/openvpn/dh1024.pem
tls-server
ca /etc/openvpn/EdUniRootCA.crt
cert /etc/openvpn/openvpn.crt+chain
extra-certs /etc/openvpn/openvpn.chain
key /etc/openvpn/openvpn.key
tls-verify /usr/lib/openvpn/dice-kx509-verify
tls-auth /etc/openvpn/tls.auth

SL6.something Linux on both ends, on a Dell server and a Dell laptop.

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?
-- 
George D M Ross MSc PhD CEng MBCS CITP, University of Edinburgh,
School of Informatics, 10 Crichton Street, Edinburgh, Scotland, EH8 9AB
Mail: gd...@in...   Voice: 0131 650 5147   Fax: 0131 650 6899
PGP: 1024D/AD758CC5  B91E D430 1E0D 5883 EF6A  426C B676 5C2B AD75 8CC5

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

Re: [Openvpn-devel] More on the George Ross failure

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

Having stolen a few minutes, a bit closer...

Backtracking, I believe George's error must be coming from 
openssl/ssl/s3_clnt.c: ssl3_send_client_verify(), the block of code 
starting 36 lines in, shown below.

There is a call to EVP_SignFinal, that I believe will turn out to 
dispatch to RSA_sign (openssl/crypto/rsa/rsa_sign.c ).  There is an 
intermediate maze of twisty passages that abstracts the signature 
mechanisms, but I'm pretty sure that's where we'll end up.

RSA_sign emits RSA_R_DIGEST_TOO_BIG_FOR_RSA_KEY when the size of the 
signature generated by i2d_X509_SIG is larger than the size allocated 
for it in the RSA structure.

Again, this is dependent (indirectly) on TLS version (the check is for 
md5_sha1 digest, which is used before TLS1.2).
The TLS1.1 path is too well-worn to be likely.  The code (abbreviated) 
goes like this:

     if(type == NID_md5_sha1) {
        ...
         i = SSL_SIG_LENGTH;
         s = m;
     } else {
            ...
         i=i2d_X509_SIG(&sig,NULL);
     }
     j=RSA_size(rsa);
     if (i > (j-RSA_PKCS1_PADDING_SIZE))
         {
         RSAerr(RSA_F_RSA_SIGN,RSA_R_DIGEST_TOO_BIG_FOR_RSA_KEY);
         return(0);
         }

This leaves the question of why the RSA structure doesn't have enough space.

Getting further back would be a lot easier with a reproducer and a 
debugger...

The ssl3_send_client_verify +36:

         if (TLS1_get_version(s) >= TLS1_2_VERSION)
             {
             long hdatalen = 0;
             void *hdata;
             const EVP_MD *md = s->cert->key->digest;
             hdatalen = BIO_get_mem_data(s->s3->handshake_buffer,
                                 &hdata);
             if (hdatalen <= 0 || !tls12_get_sigandhash(p, pkey, md))
                 {
                 SSLerr(SSL_F_SSL3_SEND_CLIENT_VERIFY,
                         ERR_R_INTERNAL_ERROR);
                 goto err;
                 }
             p += 2;
#ifdef SSL_DEBUG
             fprintf(stderr, "Using TLS 1.2 with client alg %s\n",
                             EVP_MD_name(md));
#endif
             if (!EVP_SignInit_ex(&mctx, md, NULL)
                 || !EVP_SignUpdate(&mctx, hdata, hdatalen)
                 || !EVP_SignFinal(&mctx, p + 2, &u, 
pkey))                   <===== breakpoint goes here
                 {
                 SSLerr(SSL_F_SSL3_SEND_CLIENT_VERIFY,
                         ERR_R_EVP_LIB);
                 goto err;
                 }
             s2n(u,p);
             n = u + 4;
             if (!ssl3_digest_cached_records(s))
                 goto err;
             }

.


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

This communication may not represent my employer's views,
if any, on the matters discussed.

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

[George R. <gd...@in...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

[Gert D. <ge...@gr...>]

Hi,

On Mon, Apr 28, 2014 at 04:04:10PM +0100, George Ross wrote:
> OK, with the attached patch it does appear to work for me.  I'll give it
> some more exercise tomorrow morning, but in a quick test the tunnel does
> now appear to come up properly.

Thanks.  That confirms the theory "it's the TLS negotiation patch", and
in particular "TLS 1.1 works, TLS 1.2 breaks".

Now the even more interesting question is "why is it breaking for you
in particular, while it works for other Linux users just fine" (half
of my testbed is Linux...)

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             ge...@gr...
fax: +49-89-35655025                        ge...@ne...

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

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

>   "why is it breaking for you
> in particular, while it works for other Linux users just fine" (half
> of my testbed is Linux...)
Indeed, that is the interesting question.    This has to do with how the 
client certificate is signed by the client, which in TLS1.2 is 
negotiated between the client and server - and depends on the 
available/selected ciphers.

As I wrote here: http://sourceforge.net/p/openvpn/mailman/message/32265218/, I believe I know where this is coming from, just not why.
I'd like to set a breakpoint in the client and forward/back track to find out.

George: One way to do that would be what I suggested here:  http://sourceforge.net/p/openvpn/mailman/message/32264919/

Is this feasible?  At this point, I think it would be the most efficient way to proceed.

I could give you instructions for creating a process dump - but a dump file would have more secrets in it than what I suggested.

The two referenced mail messages are as far as I got by inspection.


On 28-Apr-14 11:22, Gert Doering wrote:
> Hi,
>
> On Mon, Apr 28, 2014 at 04:04:10PM +0100, George Ross wrote:
>> OK, with the attached patch it does appear to work for me.  I'll give it
>> some more exercise tomorrow morning, but in a quick test the tunnel does
>> now appear to come up properly.
> Thanks.  That confirms the theory "it's the TLS negotiation patch", and
> in particular "TLS 1.1 works, TLS 1.2 breaks".
>
> Now the even more interesting question is "why is it breaking for you
> in particular, while it works for other Linux users just fine" (half
> of my testbed is Linux...)
>
> gert