1 Reply by Zeddi

(2 replies, posted in wolfSSL)

After a closer look I saw that the same thing which I try to do is done in the code above if verify is set to 1 (which is not the case if I want to do a stand-alone OCSP lookup via CyaSSL_CertManagerCheckOCSP).
So I changed the code that the verify-flag is not already validated within

if (verify && type != CA_TYPE) {

but rather inside the changed if-statement

if (type != CA_TYPE) {
    [...]
    if (ca) {
        [...]
        if (verify) {
            /* try to confirm/verify signature */
            [...]
        }
    }
}

This way, the ca's public key hash is set for any cert which is not a CA itself, but verification itself is only done if the verify-flag is also set.

So, does this change to set the ca's public key hash every time, not only if verify=1, seem ok?

- Daniel

Go to forum: wolfSSL

2 Topic by Zeddi

(2 replies, posted in wolfSSL)

I've tried verifying a certificate with the following function:

CyaSSL_CertManagerCheckOCSP

I know that the certificate in question is valid and that the OpenSSL OCSP responder running here uses the correct CA certificate and knows the states of the certificates.

When trying to verify my cert, the responder stated that the certificate status is unknown.
After trying some more, I saw that the "Issuer Key Hash"-value in the OCSP request changed. This was due to this field not being set anywhere and thus pointing to some uninitialized value.

I've now patched the function ParseCertRelative inside ctaocrypt/src/asn.c (CyaSSL embedded SSL v2.9.0) to set the "Issuer Key Hash"-field in the certificate which state is to be checked:

    if (verify && type != CA_TYPE) {
        [...]
    } else if (type != CA_TYPE) {
        Signer* ca = NULL;
#ifndef NO_SKID
        if (cert->extAuthKeyIdSet)
            ca = GetCA(cm, cert->extAuthKeyId);
        if (ca == NULL)
            ca = GetCAByName(cm, cert->issuerHash);
#else /* NO_SKID */
        ca = GetCA(cm, cert->issuerHash);
#endif /* NO SKID */

        // Store Issuer Key Hash for later OCSP request
        memcpy(cert->issuerKeyHash, ca->subjectKeyIdHash, SHA_SIZE);
    }

This way, the OCSP request has the correct "Issuer Key Hash" and the OCSP responder correctly responds "good" as certificate status.

Is this a bug or am I using the OCSP api wrong?

- Daniel

Go to forum: wolfSSL

3 Topic by Zeddi

(1 replies, posted in wolfSSL)

I saw that the benchmark.c-file from wolfSSL embedded SSL contains a function for testing DH key generation/agreement (bench_dh).
For this test, pre-generated DH parameters from the file certs/dh2048.der are used.

I am now wondering, if I can speed up the setup of TLS connections with ECDH-ECDSA-AES256-SHA and ECDHE-ECDSA-AES256-SHA cipher suites using pre-generated DH parameters.

I searched the code a little, but I didn't find a place where pre-generated DH parameters are used other than the benchmark function.

Is it possible to somehow use a pre-generated DH parameters file for TLS connections or am I misunderstanding this topic?

Thanks!
- Daniel

Go to forum: wolfSSL

4 Reply by Zeddi

(2 replies, posted in wolfSSL)

Thank you for the explanation!
With the client certificate being self-signed, this makes sense now smile.

Go to forum: wolfSSL

5 Reply by Zeddi

(4 replies, posted in wolfSSL)

Hi Douglas,

regarding the outdated certificates:
AFAIK, the ones outdated were recently updated in git [1]. You could try to download them from there and try again with those - this should eliminate the possibility of your self-created certificates not being correct in some way.

WolfSSL also released wolfSSL embedded SSL 2.9.0 last Friday (the downloads on the website are not updated yet I saw, but they tagged this version already in git [2]). You could try downloading this version and trying it.

[1] https://github.com/cyassl/cyassl/tree/master/certs
[2] https://github.com/cyassl/cyassl/tree/v2.9.0

Best regards,
Daniel

Go to forum: wolfSSL

6 Topic by Zeddi

(1 replies, posted in wolfSSL)

I saw that the embedded SSL client and server examples fail to link against the following methods if the NO_FILESYSTEM define is set:

  • CyaSSL_CTX_SetOCSP_OverrideURL

  • CyaSSL_CTX_EnableOCSP

I use the code from github as of Feb 2, 2014 (up to commit 51b3b1cb6cf35dedccd0311289d43aa8c628648d).

I think the problem is located within the file /src/ssl.c:
On line 2232, there is

#ifndef NO_FILESYSTEM

and as far as I can tell, this #define is closed no earlier than on line 3309:

#endif /* NO_FILESYSTEM */

Inside this block are many methods using file operations, but also quite some which should imho be available independently of the filesystem, like the OCSP ones.

Go to forum: wolfSSL

7 Topic by Zeddi

(2 replies, posted in wolfSSL)

I've seen that the server example (/examples/server/server.c) uses the client certificate instead of the CA certificate as the default CA certificate. This applies to both, ECC and non-ECC:

    char* verifyCert = (char*)cliCert;
    char* ourCert = (char*)svrCert;
    char* ourKey = (char*)svrKey;
#ifdef NO_RSA
    verifyCert = (char*)cliEccCert;
    ourCert = (char*)eccCert;
    ourKey = (char*)eccKey;
#endif

Shouldn't it be

char* verifyCert = (char*)caCert;

in the first and

char* verifyCert = (char*)eccCert;

in the second case?

As an addition:
I think it's confusing that the server and CA certificate are the same in case of ECC (eccCert, expanding to "./certs/server-ecc.pem"), whereas an individual server certificate (svrCert, expanding to "./certs/server-cert.pem") and CA certificate (caCert, expanding to "./certs/ca-cert.pem") exist for the non-ECC case.
Imho it would be more intuitive if there would be two individual certificates (e.g. ./certs/server-ecc-cert.pem for the server with CA:FALSE basic constraint and ./certs/ca-ecc-cert.pem for the CA with CA:TRUE basic constraint) in the case of ECC.

Go to forum: wolfSSL

8 Reply by Zeddi

(2 replies, posted in wolfSSL)

I've debugged a bit further. This is where the parsing fails:

    if (source[idx++] != (ASN_CONSTRUCTED | ASN_CONTEXT_SPECIFIC | 1))
        return ASN_PARSE_E;

source[idx++] points to the value 0x30 in my error case, which is unlike ASN_CONSTRUCTED (0x20) or ASN_CONTEXT_SPECIFIC (0x80).

Since the name of the function is DecodeOcspRespExtensions, I tried changing the OCSP options for the wolfaSSL test client from ...

            CyaSSL_CTX_OCSP_set_options(ctx,
                                        CYASSL_OCSP_ENABLE | CYASSL_OCSP_NO_NONCE
                                            | CYASSL_OCSP_URL_OVERRIDE);

... to ...

            CyaSSL_CTX_OCSP_set_options(ctx,
                                        CYASSL_OCSP_ENABLE
                                            | CYASSL_OCSP_URL_OVERRIDE);

and the function completes without an error!

This is the response my OpenSSL OCSP responder sent in this case:

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = DE, ST = Bayern, O = Daniel Zebralla, OU = A S&T CDS TCD,
CN = test1.test.de, emailAddress = daniel.zebralla@continental-corporation.com
    Produced At: Jan 31 08:35:07 2014 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 694F0EA887A109BF63EFD1420E7F0B501195929E
      Issuer Key Hash: ACCCEC3C2E4DDCF100AFD46C6D085E8C92C80F81
      Serial Number: 1003
    Cert Status: good
    This Update: Jan 31 08:35:07 2014 GMT

    Response Extensions:
        OCSP Nonce:
            9DBE63800346529A6222420658C6EA6D91F3
    Signature Algorithm: ecdsa-with-SHA1
         30:45:02:20:10:27:9e:78:1e:c4:28:d6:3c:1f:05:af:6f:27:
         0e:72:ff:78:a6:ab:73:6e:6e:60:8c:54:d1:31:01:82:ba:f8:
         02:21:00:eb:46:5b:7e:15:39:aa:72:a3:92:dd:c4:ba:e1:fd:
         f7:21:c1:17:fa:bb:5f:56:de:d7:2d:99:4d:6a:e6:74:7b
Certificate:
 ...

Note the new lines:

    Response Extensions:
        OCSP Nonce:
            9DBE63800346529A6222420658C6EA6D91F3

So, in conclusion, I assume that wolfSSL treats the "response extensions" block as mandatory and stops parsing the OCSP response if it's not there (thus not checking the signature which would be done later in the code).

I've looked up RFC6960, and 4.2.2.3. Basic Response states [1]:

The basic response type contains:
[...]
o  optional extensions;
[...]

I guess wolfSSL should treat OCSP response extensions as optional and continue parsing the response in any case.

[1] http://tools.ietf.org/html/rfc6960#section-4.2.2.3

- Daniel

Go to forum: wolfSSL

9 Topic by Zeddi

(2 replies, posted in wolfSSL)

I've set up my own CA with OpenSSL (1.0.1e). I created ECC-keys and issued the following certs:

  • cacert-ecc.pem

  • test3-ecc.pem

The following commands are all issued on my local laptop (which has 192.168.1.5 assigned).
I start my OpenSSL server:

D:\OpenSSL-CA-ECC>openssl s_server -CAfile cacert-ecc.pem -cert test3-ecc.pem -key test3-ecc-key.pem -debug -port 11111

I start my OpenSSL OCSP responder:

D:\OpenSSL-CA-ECC>openssl ocsp -index index.txt -port 192.168.1.5:8888 -rsigner cacert-ecc.pem -rkey private\cakey-ecc.pem -CA cacert-ecc.pem -text
Waiting for OCSP client connections...

I start my wolfSSL 2.8.0 test client on the same laptop inside a Cygwin environment (hence the unix style):

$ ./client -o -A /cygdrive/d/OpenSSL-CA-ECC/cacert-ecc.pem -c /cygdrive/d/OpenSSL-CA-ECC/test3-ecc.pem -k /cygdrive/d/OpenSSL-CA-ECC/test3-ecc-key.pem -h 192.168.1.5 -p 11111

The OCSP request and response dumped by the OpenSSL OCSP responder:

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 694F0EA887A109BF63EFD1420E7F0B501195929E
          Issuer Key Hash: ACCCEC3C2E4DDCF100AFD46C6D085E8C92C80F81
          Serial Number: 1003
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = DE, ST = Bayern, L = Regensburg, O = Daniel Zebralla, OU = A S&T CDS TCD, CN = ca.test.de, emailAddress = daniel.zebralla@continental-corporation.com
    Produced At: Jan 24 11:35:15 2014 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 694F0EA887A109BF63EFD1420E7F0B501195929E
      Issuer Key Hash: ACCCEC3C2E4DDCF100AFD46C6D085E8C92C80F81
      Serial Number: 1003
    Cert Status: good
    This Update: Jan 24 11:35:15 2014 GMT

    Signature Algorithm: ecdsa-with-SHA1
         30:45:02:20:55:7c:09:e9:6b:09:15:ef:79:fc:55:5d:97:d4:
         34:e1:db:f1:36:a6:01:b6:62:60:1f:3d:40:74:87:1a:fc:99:
         02:21:00:b7:ae:b9:78:f1:69:5b:49:2b:88:95:2e:13:03:4c:
         a3:63:83:2a:8f:65:6c:66:7e:f8:2c:80:23:b7:1e:94:d3
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            8b:d4:04:ab:af:5b:65:69
    Signature Algorithm: ecdsa-with-SHA1
        Issuer: C=DE, ST=Bayern, L=Regensburg, O=Daniel Zebralla, OU=A S&T CDS TCD, CN=ca.test.de/emailAddress=daniel.zebralla@continental-corporation.com
        Validity
            Not Before: Jan 14 07:47:23 2014 GMT
            Not After : Jan 12 07:47:23 2024 GMT
        Subject: C=DE, ST=Bayern, L=Regensburg, O=Daniel Zebralla, OU=A S&T CDS TCD, CN=ca.test.de/emailAddress=daniel.zebralla@continental-corporation.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:5d:a8:08:01:2e:b7:26:1e:6e:f3:36:16:70:b9:
                    c5:30:63:85:72:62:66:39:fe:ed:b8:71:6e:1c:ca:
                    30:62:be:d9:80:d2:f3:32:36:5b:08:8e:04:ad:29:
                    7d:b8:ce:ad:ab:14:e5:d5:9c:c9:24:5e:32:7f:52:
                    ab:6e:be:38:42
                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                AC:CC:EC:3C:2E:4D:DC:F1:00:AF:D4:6C:6D:08:5E:8C:92:C8:0F:81
            X509v3 Authority Key Identifier:
                keyid:AC:CC:EC:3C:2E:4D:DC:F1:00:AF:D4:6C:6D:08:5E:8C:92:C8:0F:81

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: ecdsa-with-SHA1
         30:45:02:20:61:f8:17:c9:45:89:0b:50:4d:6a:1e:92:e2:df:
         09:14:e4:9d:1a:8b:c7:85:35:d3:de:77:b4:43:de:d8:b9:60:
         02:21:00:9a:43:25:7b:8f:e6:13:21:18:26:5c:78:2e:5c:9a:
         f1:55:36:8b:a5:2a:09:ac:26:ee:35:2e:77:bf:c7:53:2e
-----BEGIN CERTIFICATE-----
MIICszCCAlqgAwIBAgIJAIvUBKuvW2VpMAkGByqGSM49BAEwgbYxCzAJBgNVBAYT
AkRFMQ8wDQYDVQQIDAZCYXllcm4xEzARBgNVBAcMClJlZ2Vuc2J1cmcxGDAWBgNV
BAoMD0RhbmllbCBaZWJyYWxsYTEWMBQGA1UECwwNQSBTJlQgQ0RTIFRDRDETMBEG
A1UEAwwKY2EudGVzdC5kZTE6MDgGCSqGSIb3DQEJARYrZGFuaWVsLnplYnJhbGxh
QGNvbnRpbmVudGFsLWNvcnBvcmF0aW9uLmNvbTAeFw0xNDAxMTQwNzQ3MjNaFw0y
NDAxMTIwNzQ3MjNaMIG2MQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmF5ZXJuMRMw
EQYDVQQHDApSZWdlbnNidXJnMRgwFgYDVQQKDA9EYW5pZWwgWmVicmFsbGExFjAU
BgNVBAsMDUEgUyZUIENEUyBUQ0QxEzARBgNVBAMMCmNhLnRlc3QuZGUxOjA4Bgkq
hkiG9w0BCQEWK2RhbmllbC56ZWJyYWxsYUBjb250aW5lbnRhbC1jb3Jwb3JhdGlv
bi5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARdqAgBLrcmHm7zNhZwucUw
Y4VyYmY5/u24cW4cyjBivtmA0vMyNlsIjgStKX24zq2rFOXVnMkkXjJ/UqtuvjhC
o1AwTjAdBgNVHQ4EFgQUrMzsPC5N3PEAr9RsbQhejJLID4EwHwYDVR0jBBgwFoAU
rMzsPC5N3PEAr9RsbQhejJLID4EwDAYDVR0TBAUwAwEB/zAJBgcqhkjOPQQBA0gA
MEUCIGH4F8lFiQtQTWoekuLfCRTknRqLx4U10953tEPe2LlgAiEAmkMle4/mEyEY
Jlx4Llya8VU2i6UqCawm7jUud7/HUy4=
-----END CERTIFICATE-----

I am wondering, why the signature of the OCSP response seems NOT to get checked. Note the one line of debug output I've added in the wolfSSL embedded SSL debug messages further below, indicating an error in looking for OCSP extensions ( >>> DZ: In OcspResponseDecode, ret = -140). I'm missing a line like "About to verify certificate signature" while OCSP processing. As far as I debugged, the error code -140 results in OCSP response processing returning before the signature of its attached certificate would be checked. Is this the way it should be:

    if (DecodeResponseData(source, &idx, resp, size) < 0)
        return ASN_PARSE_E;
[...]
    * see if there are certificates, they are optional.
    */
    if (idx < end_index)
    {
[...]
        ret = ConfirmSignature(resp->response, resp->responseSz,
                            cert.publicKey, cert.pubKeySize, cert.keyOID,
                            resp->sig, resp->sigSz, resp->sigOID, NULL);
CyaSSL Entering CYASSL_CTX_new
CyaSSL Entering CyaSSL_CertManagerNew
CyaSSL Leaving CYASSL_CTX_new, return 0
CyaSSL Entering CyaSSL_CTX_OCSP_set_options
CyaSSL Entering CyaSSL_CTX_use_certificate_chain_file
Getting dynamic buffer
Checking cert signature type
CyaSSL Entering GetExplicitVersion
CyaSSL Entering GetMyVersion
CyaSSL Entering GetAlgoId
Getting Cert Name
Getting Cert Name
CyaSSL Entering GetAlgoId
ECDSA cert signature
CyaSSL Entering CyaSSL_CTX_use_PrivateKey_file
CyaSSL Entering GetMyVersion
CyaSSL Entering CyaSSL_CTX_load_verify_locations
Getting dynamic buffer
Processing CA PEM file
Adding a CA
CyaSSL Entering GetExplicitVersion
CyaSSL Entering GetMyVersion
CyaSSL Entering GetAlgoId
Getting Cert Name
Getting Cert Name
CyaSSL Entering GetAlgoId
CyaSSL Entering DecodeCertExtensions
CyaSSL Entering DecodeSubjKeyId
CyaSSL Entering DecodeAuthKeyId
CyaSSL Entering DecodeBasicCaConstraint
CyaSSL Leaving DecodeCertExtensions, return 0
CyaSSL Entering GetAlgoId
    Parsed new CA
    Freeing Parsed CA
    Freeing der CA
        OK Freeing der CA
CyaSSL Leaving AddCA, return 0
   Processed a CA
CyaSSL Entering SSL_new
CyaSSL Leaving SSL_new, return 0
CyaSSL Entering SSL_set_fd
CyaSSL Leaving SSL_set_fd, return 1
CyaSSL Entering SSL_connect()
growing output buffer

Shrinking output buffer

connect state: CLIENT_HELLO_SENT
growing input buffer

growing input buffer

received record layer msg
CyaSSL Entering DoHandShakeMsg()
CyaSSL Entering DoHandShakeMsgType
processing server hello
CyaSSL Leaving DoHandShakeMsgType(), return 0
CyaSSL Leaving DoHandShakeMsg(), return 0
growing input buffer

received record layer msg
CyaSSL Entering DoHandShakeMsg()
CyaSSL Entering DoHandShakeMsgType
processing certificate
Loading peer's cert chain
    Put another cert into chain
    Put another cert into chain
CyaSSL Entering GetExplicitVersion
CyaSSL Entering GetMyVersion
CyaSSL Entering GetAlgoId
Getting Cert Name
Getting Cert Name
CyaSSL Entering GetAlgoId
CyaSSL Entering DecodeCertExtensions
CyaSSL Entering DecodeSubjKeyId
CyaSSL Entering DecodeAuthKeyId
CyaSSL Entering DecodeBasicCaConstraint
CyaSSL Leaving DecodeCertExtensions, return 0
CyaSSL Entering GetAlgoId
About to verify certificate signature
ECC Verify did match
Verified CA from chain and already had it
Verifying Peer's cert
CyaSSL Entering GetExplicitVersion
CyaSSL Entering GetMyVersion
CyaSSL Entering GetAlgoId
Getting Cert Name
Getting Cert Name
CyaSSL Entering GetAlgoId
CyaSSL Entering DecodeCertExtensions
CyaSSL Entering DecodeBasicCaConstraint
CyaSSL Entering DecodeAuthInfo
        Extension type not handled, skipping
CyaSSL Entering DecodeSubjKeyId
CyaSSL Entering DecodeAuthKeyId
CyaSSL Leaving DecodeCertExtensions, return 0
CyaSSL Entering GetAlgoId
About to verify certificate signature
ECC Verify did match
Verified Peer's cert
Add a new OCSP entry
CyaSSL Entering InitOCSP_Entry
CyaSSL Entering InitOcspRequest
CyaSSL Entering EncodeOcspRequest
CyaSSL Entering SetSerialNumber
CyaSSL Entering InitOcspResponse
CyaSSL Entering OcspResponseDecode
CyaSSL Entering GetEnumerated
CyaSSL Entering DecodeBasicOcspResponse
CyaSSL Entering DecodeResponseData
CyaSSL Entering GetBasicDate
CyaSSL Entering DecodeSingleResponse
CyaSSL Entering GetAlgoId
CyaSSL Entering GetBasicDate
CyaSSL Entering DecodeOcspRespExtensions
 >>> DZ: In OcspResponseDecode, ret = -140
CyaSSL Entering CompareOcspReqResp
CyaSSL Leaving DoHandShakeMsgType(), return 0
CyaSSL Leaving DoHandShakeMsg(), return 0
received record layer msg
CyaSSL Entering DoHandShakeMsg()
CyaSSL Entering DoHandShakeMsgType
processing server key exchange
CyaSSL Leaving DoHandShakeMsgType(), return 0
CyaSSL Leaving DoHandShakeMsg(), return 0
received record layer msg
CyaSSL Entering DoHandShakeMsg()
CyaSSL Entering DoHandShakeMsgType
processing server hello done
CyaSSL Leaving DoHandShakeMsgType(), return 0
CyaSSL Leaving DoHandShakeMsg(), return 0
connect state: HELLO_AGAIN
connect state: HELLO_AGAIN_REPLY
connect state: FIRST_REPLY_DONE
connect state: FIRST_REPLY_FIRST
growing output buffer

Shrinking output buffer

sent: client key exchange
connect state: FIRST_REPLY_SECOND
connect state: FIRST_REPLY_THIRD
growing output buffer

Shrinking output buffer

sent: change cipher spec
connect state: FIRST_REPLY_FOURTH
growing output buffer

Shrinking output buffer

sent: finished
connect state: FINISHED_DONE
received record layer msg
got CHANGE CIPHER SPEC
received record layer msg
CyaSSL Entering DoHandShakeMsg()
CyaSSL Entering DoHandShakeMsgType
processing finished
CyaSSL Leaving DoHandShakeMsgType(), return 0
CyaSSL Leaving DoHandShakeMsg(), return 0
connect state: SECOND_REPLY_DONE
Shrinking input buffer

CyaSSL Leaving SSL_connect(), return 1
CyaSSL Entering SSL_get_version
SSL version is TLSv1.2
CyaSSL Entering SSL_get_current_cipher
CyaSSL Entering SSL_CIPHER_get_name
SSL cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
CyaSSL Entering SSL_write()
growing output buffer

Shrinking output buffer

CyaSSL Leaving SSL_write(), return 13
CyaSSL Entering CyaSSL_read()
CyaSSL Entering CyaSSL_read_internal()
CyaSSL Entering ReceiveData()
growing input buffer

growing input buffer

received record layer msg
got app DATA
Shrinking input buffer

CyaSSL Leaving ReceiveData(), return 13
CyaSSL Leaving CyaSSL_read_internal(), return 13
Server response: I hear you!

CyaSSL Entering SSL_shutdown()
growing output buffer

Shrinking output buffer

CyaSSL Leaving SSL_shutdown(), return 0
CyaSSL Entering SSL_free
CTX ref count not 0 yet, no free
CyaSSL Leaving SSL_free, return 0
CyaSSL Entering SSL_CTX_free
CTX ref count down to 0, doing full free
CyaSSL Entering CyaSSL_CertManagerFree
CyaSSL Entering FreeOCSP_Entry
CyaSSL Leaving SSL_CTX_free, return 0
CyaSSL Entering CyaSSL_Cleanup

Best regards
- Daniel

Go to forum: wolfSSL

10 Reply by Zeddi

(2 replies, posted in wolfSSL)

Hi chrisc,

yes, I now know that adding those TLS extensions is on your roadmap and will be done sooner or later.

Regards
Daniel

Go to forum: wolfSSL

11 Topic by Zeddi

(1 replies, posted in wolfSSL)

I encountered a build error when using TLS extensions and especially the SNI extension with NO_FILESYSTEM defined at the same time.

The error is 

undefined reference to `test_CyaSSL_client_server'

while linking and occurs a couple of times with /tests/api.c.

The source of the problem seems to be that the function

void test_CyaSSL_client_server(callback_functions* client_callbacks,
                                          callback_functions* server_callbacks);

is within the following define:

#if !defined(NO_FILESYSTEM) && !defined(NO_CERTS)

whereas the function

void test_CyaSSL_UseSNI(void)

which calls test_CyaSSL_client_server multiple times is only within the following defines:

#ifdef HAVE_TLS_EXTENSIONS
#ifdef HAVE_SNI

Regards,
Daniel

Go to forum: wolfSSL

12 Topic by Zeddi

(2 replies, posted in wolfSSL)

I saw that wolfSSL embedded SSL doesn't seem to support all TLS extensions as defined in RFC 6066 [1].

From wolfssl/internal.h:

typedef enum {
    SERVER_NAME_INDICATION =  0,
    MAX_FRAGMENT_LENGTH    =  1,
  /*CLIENT_CERTIFICATE_URL =  2,
    TRUSTED_CA_KEYS        =  3,*/
    TRUNCATED_HMAC         =  4,
  /*STATUS_REQUEST         =  5,
    SIGNATURE_ALGORITHMS   = 13,*/
} TLSX_Type;

I saw that you added support for MAX_FRAGMENT_LENGTH and TRUNCATED_HMAC with the release of 2.8.0 which is very nice already.
Unfortunately I have the requirement to use TRUSTED_CA_KEYS as well as STATUS_REQUEST.

Are there plans to implement those TLS extensions in the (near) future?

What I'm wondering is that support for OCSP requests during TLS initialization is already implemented in wolfSSL (at least I thought so): Is this done via a stand-alone OCSP request and not via the TLS extension STATUS_REQUEST?

[1] http://tools.ietf.org/html/rfc6066

Regards,
Daniel

Go to forum: wolfSSL

13 Topic by Zeddi

(1 replies, posted in wolfSSL)

While trying to validate an OCSP response by an OpenSSL OCSP responder running on my laptop, I came across a problem with validation of the timestamps.

For example, the OCSP response contains the following timestamp:

Produced At: Dec 11 07:52:00 2013 GMT

The response arrives at the OCSP client (running wolfSSL embedded SSL 2.7.0) within <1 second, so that the system time on the OCSP client is still Dec 11 07:52:00 2013 GMT when the following code inside 'DecodeSingleResponse' function in ctaocrypt/src/asn.c is executed (note that the XVALIDATE_DATE define expands to the default ValidateDate-implementation using the complete <time.h> facility):

    if (!XVALIDATE_DATE(cs->thisDate, cs->thisDateFormat, BEFORE))
        return ASN_BEFORE_DATE_E;

This call yields an ASN_BEFORE_DATE_E error although I thought that the OCSP response should be treated as valid from the second on it says so - in my example Dec 11 07:52:00 2013 GMT.

RFC2560, chapter 2.4 says:

Responses can contain three times in them - thisUpdate, nextUpdate
   and producedAt. The semantics of these fields are:

   - thisUpdate: The time at which the status being indicated is known
                 to be correct
   - nextUpdate: The time at or before which newer information will be
                 available about the status of the certificate
   - producedAt: The time at which the OCSP responder signed this
                 response.

I understand that it's arguable whether to treat the exact same second as valid or invalid.
I am just wondering if this scenario may happen to a lot more people with OCSP responders which update the revocation status on demand and transmission/processing delays of <1 second.

I for myself changed the last if-statement in the DateGreaterThan-function from

    if (a->tm_year == b->tm_year && a->tm_mon == b->tm_mon &&
        a->tm_mday == b->tm_mday && a->tm_hour == b->tm_hour &&
        a->tm_min  == b->tm_min  && a->tm_sec > b->tm_sec)

to

    if (a->tm_year == b->tm_year && a->tm_mon == b->tm_mon &&
        a->tm_mday == b->tm_mday && a->tm_hour == b->tm_hour &&
        a->tm_min  == b->tm_min  && a->tm_sec >= b->tm_sec)

so that this "special" case works.

Any further thoughts on this?
- Daniel

Go to forum: wolfSSL

14 Reply by Zeddi

(3 replies, posted in wolfSSL)

Thanks for the clarification John,

that's already the way I tried the OCSP lookup.
As I wrote, it basically worked but I had no chance to validate the signature in the OCSP reply against a certificate stored on my OCSP client. Note that the OCSP responder intentionally DID NOT attach the certificate to the response.
Because there is no certificate attached to the OCSP response, the validation is not triggered (excerpt from function DecodeBasicOcspResponse inside ctaocrypt/src/asn.c):

    /*
     * Check the length of the BasicOcspResponse against the current index to
     * see if there are certificates, they are optional.
     */
    if (idx < end_index)
    {
        ...
        ret = ConfirmSignature(resp->response, resp->responseSz,
                            cert.publicKey, cert.pubKeySize, cert.keyOID,
                            resp->sig, resp->sigSz, resp->sigOID, NULL);
        ...
    }

So my question is:
Is there a way to trigger OCSP response signature verification against a certificate which I am loading from the file system on the OCSP client?

Go to forum: wolfSSL

15 Topic by Zeddi

(3 replies, posted in wolfSSL)

Hello,

for my work I need to query an OCSP responder to verify whether a certificate has been revoked or not.
I understand that wolfSSL embedded SSL brings OCSP functionality, but as I see it, it's intended to be used only in a way of "OCSP stapling" (meaning that the OCSP request/response is sent during the TLS handshake).

The only OCSP-related functions mentioned in the manual are:
wolfSSL_CTX_OCSP_set_options
wolfSSL_CTX_OCSP_set_override_url

Internally, wolfSSL uses a lot more OCSP-related functions to query a responder and verify the response. With the correct #includes, I was able to build a working OCSP request without a TLS handshake.

My problem now is that the signature of the OCSP response is only verified if the responder includes a/its certificate.
I want to verify the signature from a response against a certificate which is already on my 'client' and not packed with the response.
I know I could change the code for verification to be available inside my application, but I guess that's not what WolfSSL has intended.

Any suggestions or thoughts on this are welcome!

Regards,
- Daniel

Go to forum: wolfSSL

16 Reply by Zeddi

(2 replies, posted in wolfSSL)

Hi Menno,

from what I understand, wolfSSL provides an OpenSSL API 'wrapper' which simply provides the function names as used by OpenSSL, but internally remaps them to wolfSSL's own functions. I also read that this compatibility layer is by no means complete but rather wraps the most widely used OpenSSL functions.
Let's take the OpenSSL function DH_generate_key and look at the file you mentioned:

#define DH_generate_key wolfSSL_DH_generate_key

This maps this function to wolfSSL_DH_generate_key.
The source for this wolfSSL-specific function is then found inside /cyassl-2.8.0/src/ssl.c starting at line 9061:

    /* return SSL_SUCCESS on ok, else 0 */
    int CyaSSL_DH_generate_key(CYASSL_DH* dh)
    {

You should have a look into chapter 13 of the wolfSSL manual if you have not yet done so:
http://www.yassl.com/yaSSL/Docs-cyassl- … ility.html

I hope this helps, nevertheless someone from WolfSSL may give a better answer smile.

Regards,
- Daniel

Go to forum: wolfSSL

17 Reply by Zeddi

(3 replies, posted in wolfSSL)

Hi Chris,

thanks for the quick response.
In theory, I would need this quite soon as OCSP with IPv6 is one of the requirements I have for my application.
You don't have to rush onto this though, because I'm quite sure that I can tinker with the code to get it working myself and substitute the corresponding code with a clean fix from you guys later on.

Regards
- Daniel

Go to forum: wolfSSL

18 Topic by Zeddi

(3 replies, posted in wolfSSL)

Testing my work-in-progress port on eCos, I stumbled across a build error in src/io.c when TEST_IPV6 and HAVE_OCSP are defined together.

I verified this error on Cygwin x32 on my Windows 7 machine with wolfSSL 2.7.0 (got the same error with 2.8.0 as well):

src/io.c: In function 'tcp_connect':
src/io.c:513:5: warning: array subscript has type 'char' [-Wchar-subscripts]
src/io.c:536:9: error: 'SOCKADDR_IN_T' has no member named 'sin_family'
src/io.c:537:9: error: 'SOCKADDR_IN_T' has no member named 'sin_port'
src/io.c:539:13: error: 'SOCKADDR_IN_T' has no member named 'sin_addr'
src/io.c:541:13: error: 'SOCKADDR_IN_T' has no member named 'sin_addr'

The problem seems to be that the TEST_IPV6-define is tested and depending on this, the SOCKADDR_IN_T and AF_INET_V are set, but the remaining code is not fully IPv6-aware.

I saw that the IPv6 handling inside wolfssl/test.h looks more thorough which made me wonder why it's handled in two different ways.

Can you please confirm whether this is a bug and if/when it will be resolved (perhaps with 2.9.0)?

Kind regards
- Daniel

Go to forum: wolfSSL

19 Topic by Zeddi

(1 replies, posted in wolfSSL)

I noticed during testing with wolfSSL embedded SSL 2.8.0, that the ECC server test certificate server-ecc.pem expired recently.
From server-ecc.pem:

        Validity
            Not Before: Jan 25 20:09:20 2011 GMT
            Not After : Oct 21 20:09:20 2013 GMT

Is it possibly to provide an updated certificate or will the next release of wolfSSL (2.9.0?) feature a renewed certificate?

For now, I created my own server-ecc-new.pem with the instructions provided by your taoCert.txt-file (although I needed to add some extras to the openssl-calls to get a certificate as similar as possible to your server-ecc.pem).

Regards
- Daniel

Go to forum: wolfSSL

20 Reply by Zeddi

(2 replies, posted in wolfSSL)

Hi Chris,

thanks for the confirmation.

I already did what you were suggesting and so far it's working for my use-cases. Of course it's not a very nice solution as I hard-coded the hex-values of all the certificates in DER-format into some header-files.
I will provide the code with the remainder of the eCos-port once I'm done smile.

Regards
- Daniel

Go to forum: wolfSSL

21 Topic by Zeddi

(2 replies, posted in wolfSSL)

I'm trying to run the unit-tests on a WIP eCos port (based on wolfSSL embedded SSL 2.7.0), but stumbled over certificate loading with the example server and NO_FILESYSTEM defined.

This define helped during API tests, as the client certificates are then loaded directly from the certs_test.h header file, e.g.:

/* ./certs/1024/client-key.der, 1024-bit */
const unsigned char client_key_der_1024[] =
{
    0x30, 0x82, 0x02, 0x5C, 0x02, 0x01, 0x00, 0x02, 0x81, 0x81, 
[...]
};

I hoped that this will work the same way when I start the server itself (in my case through the SuiteTests-function in suites.c). Unfortunately, the server only loads certificates if a filesystem is available (examples/server/server.c):

#if !defined(NO_FILESYSTEM) && !defined(NO_CERTS)
    if (!usePsk) {
        if (SSL_CTX_use_certificate_file(ctx, ourCert, SSL_FILETYPE_PEM)
                                         != SSL_SUCCESS)
            err_sys("can't load server cert file, check file and run from"
                    " wolfSSL home dir");
    }
#endif

Then I saw that the echoserver (examples/echoserver/echoserver.c) on the other hand has code for the NO_FILESYSTEM case:

#ifndef NO_FILESYSTEM
[...]
#elif !defined(NO_CERTS)
    if (!doPSK) {
        load_buffer(ctx, svrCert, WOLFSSL_CERT);
        load_buffer(ctx, svrKey,  WOLFSSL_KEY);
    }
#endif

What made me sad in the end, was that the function load_buffer as defined in test.h again needs a filesystem to fill the buffer with contents of the file passed:

#if defined(NO_FILESYSTEM) && !defined(NO_CERTS)
[...]
static INLINE void load_buffer(WOLFSSL_CTX* ctx, const char* fname, int type)
{
        /* test buffer load */
        long  sz = 0;
        byte  buff[10000];
        FILE* file = fopen(fname, "rb");

        if (!file)
            err_sys("can't open file for buffer load "
                    "Please run from wolfSSL home directory if not");
[...]
#endif /* NO_FILESYSTEM */

So, do I have to make my own load_buffer-function which fills ctx directly from a char array, or is there any other intended way to do this which I'm missing?

Thanks!
- Daniel

Go to forum: wolfSSL

22 Reply by Zeddi

(2 replies, posted in wolfSSL)

Another update with a solution (at least as a work-around):

Initially, I executed all the CyaSSL API and Hash tests inside my main thread and did not start an individual one for the tests.
This seemed to be the source of all the trouble.
I now moved all the CyaSSL-related stuff into an individual thread, created with a call to the cyg_thread_create()-function from eCos, and the tests are now working!

Go to forum: wolfSSL

23 Reply by Zeddi

(2 replies, posted in wolfSSL)

Just as an update on this:
I also posted this issue onto the ecos-discuss mailing list now, including some further thoughts:
http://sourceware-org.1504.n7.nabble.co … 45720.html

Regards
- Daniel

Go to forum: wolfSSL

24 Topic by Zeddi

(2 replies, posted in wolfSSL)

Hi all,

I'm working on an eCos-port of the wolfSSL library (v 2.7.0) for embedded SSL. The target CPU we're using is a Freescale SPC5668.
So far a couple of the tests worked, but now I'm stuck in the "rsa_test" of the API tests.
I have USE_FAST_MATH defined, so memory allocations are used.

Inside this test, an RSA key is created:

RsaKey key;

Strangely, key points to an address in RAM instantly which has a couple of bytes 0ed (I assume unused), but after some dozen bytes, various variables used by eCos are stored (I especially found some bitmasks for strlen-function and a counter for malloc-function).

The system crashes when the function memset is called from within RsaPrivateKeyDecode -> GetInt -> mp_init with the following parameters:
s = 0x400033F4 (the target address of key)
c = 0
n = 552

This call overwrites 552 bytes of memory starting from address 0x400033F4. This results in various variables needed by eCos in being 0ed and thus corrupting the system context, causing a reboot of my hardware.

I'm not sure if this is a bug in wolfSSL or in eCos instead.
I am wondering though, why there is no previous malloc or similar for key to allocate free memory for the whole key.

Any help is greatly appreciated!
- Daniel

PS: The test worked when I had NOT defined USE_FAST_MATH. It crashed later, but this is another issue.

Go to forum: wolfSSL