101 Reply by john

(5 replies, posted in wolfSSL)

  • authIn in a pointer to additional plaintext that is to be authenticated with the plaintext being encrypted

  • authTag is a pointer to the authentication tag output

The authTag is the "MAC" authentication tag output for the encrypt function, and it is the "MAC" authentication tag input to authenticate with for the decrypt function. The authIn in both encrypt and decrypt functions is the plaintext that included in the authentication tag with the encrypted data.

In TLS, the authentication tag is the MAC of the plaintext data being encrypted, with the sequence number, TLS record type, TLS record version, and record length.

In the function aesgcm_test(), p is the plain text, a is the additional data to authenticate, c is the expected cipher text, t is the expected authentication tag. t2, p2, c2 are the buffers capturing the output of the encrypt and decrypt functions.

Go to forum: wolfSSL

102 Reply by john

(1 replies, posted in wolfSSL)

On your build platform what are sizeof(cyassl_word), sizeof(long int), sizeof(long long), and sizeof(fp_digit)?

Go to forum: wolfSSL

103 Reply by john

(1 replies, posted in wolfSSL)

To do the handshake benchmark, you need to use the echoserver and the client with the -b option. And DTLS has to be disabled in the build. (Enabling DTLS forces the echoserver to be DTLS only.)

We don't support DTLS handshake benchmarking at the moment. (But it is on our list.) The problem is that the echoserver won't wait for a new incoming connection until it receives a "break" message from the existing session, or the socket is closed cold. In the TCP benchmark, the sockets are just closed and reopened.

Go to forum: wolfSSL

104 Reply by john

(2 replies, posted in wolfSSL)

pepelu wrote:

When trying to run the examples from version 3.0.0 with DTLS (option -u) I keep having:
yassl error: Bad SSL version.
When adding CYASSL_DTLS to the preprocessor options, VS cannot build as it encounters some errors:

error LNK2019: unresolved external symbol _CyaDTLSv1_server_method referenced in function _server_test@4
error LNK2019: unresolved external symbol _CyaDTLSv1_2_server_method referenced in function _server_test@4
error LNK2019: unresolved external symbol _CyaSSL_dtls_get_current_timeout referenced in function _NonBlockingSSL_Accept
error LNK2019: unresolved external symbol _CyaSSL_dtls_got_timeout referenced in function _NonBlockingSSL_Accept

Did you add CYASSL_DTLS to only the server's preprocessor options or to the server, client, and CyaSSL library's preprocessor options?

pepelu wrote:

Another problem I have encountered is that when doing the same exchange but without -u option, using TLS I can made the handshake and the output is good but Wireshark does not show the traffic as TLS but as TCP messages. Anyone had also have this problem?

Wireshark usually picks the protocol based on the port number, so it knows that 443 is HTTP over TLS and decodes it as expected. Our test server uses port 11111 so Wireshark isn’t assuming anything about it. You need to select one of the packets and bring up the pop-up menu selecting “Decode As…”, then select “SSL” from the list of protocols.

Go to forum: wolfSSL

105 Reply by john

(1 replies, posted in wolfSSL)

You have to load your own CA certificates. We do not distribute any beyond our own test certificates.

Go to forum: wolfSSL

106 Reply by john

(4 replies, posted in wolfSSL)

Some of the functions listed on that page require other features we normally disable. Adding --enable-sessioncerts should give you wolfSSL_X509_get_serial_number, wolfSSL_get_sessionID, and the chain functions. Adding --enable-certgen will add wolfSSL_PemCertToDer. The other functions listed on that webpage should be available to you, though.

Go to forum: wolfSSL

107 Reply by john

(4 replies, posted in wolfSSL)

Are you looking at just the exports from the library? Or is your application failing to build? Our compatibility layer is a set of #defines that map the OpenSSL function names to wolfSSL names, like "#define SSL_read wolfSSL_read".

Go to forum: wolfSSL

108 Reply by john

(1 replies, posted in wolfSSL)

They eventually expire, but they aren't deleted. If you use an expired saved session, the connection will perform a new handshake.

The functions CyaSSL_CTX_set_timeout() and CyaSSL_set_timeout() will adjust the expiry time in seconds.

Go to forum: wolfSSL

109 Reply by john

(1 replies, posted in wolfSSL)

Could you add a print statement to the EmbedReceive() function in file io.c, right after the RECV_FUNCTION() command to print out the value "recvd" and "errno"? (I'm pretty sure it should go into line 243.) It should be working like you expect. Knowing those values would help. Thanks!

Go to forum: wolfSSL

110 Reply by john

(3 replies, posted in wolfSSL)

We recently added many DHE-PSK cipher suites last week. The code specifies a new key-exchange algorithm, dhe_psk_kea, which is handled alongside the diffie_hellman_kea and psk_kea. So, you might want to check that out and see if solves your issue. The DHE-PSK key exchange doesn't sign the message like in ECDHE and regular DH(E).

Go to forum: wolfSSL

111 Topic by john

(0 replies, posted in Announcements)

Hot on the heels of the last release is the new version 3.0.0. It is now ready to download from: http://yassl.com/yaSSL/download/downloadForm.php.

New features include:

  • FIPS release candidate

  • X.509 improvements that address items reported by Suman Jana with security researchers at UT Austin and UC Davis

  • Small stack size improvements, --enable-smallstack. Offloads large local variables to the heap. (Note this is not complete.)

  • Updated AES-CCM-8 cipher suites to use approved suite numbers.

Please see the README and our on-line documentation for more information or feel free to contact us.

Go to forum: Announcements

112 Reply by john

(2 replies, posted in wolfSSL)

Our tutorial does not cover DTLS. You can take a look at our example echoserver and echoclient that comes with the wolfSSL library.

Go to forum: wolfSSL

113 Reply by john

(1 replies, posted in wolfSSL)

The echoserver tutorial will listen() on the TCP socket. When you are using UDP, you don't listen() on the socket ever. Normally on UDP, you just recvfrom() on the socket and process the datagrams as they arrive. If you look at the wolfSSL echoserver, it has this implemented. (Note, the wolfSSL example echoserver is more complicated than the tutorial version.)

Go to forum: wolfSSL

114 Reply by john

(1 replies, posted in wolfSSL)

The fact it doesn't compile is a bug. That was an oversight.

That variable hash is used to calculate the "finished" hash, which is an concatenation of the MD5 and SHA-1 hashes of the messages concatenated together and then encrypted. That hash array is of length FINISHED_SZ, or SHA_DIGEST_SIZE + MD5_DIGEST_SIZE. For TLSv1.2, they decided that just the specified hash should be used, and they added the ability to specify other hashes like SHA-256 and SHA-384, which we also support. The strange looking &hash[MD5_HASH_SIZE] is trying to set the pointer into the hash storage after the old MD5 portion. (Trying to do it the new way while letting the old way work.)

Unless you change the value of FINISHED_SZ, you are getting a buffer overflow with your patch.

Which configure settings are you using? I'm guessing you have at the least:

$ ./configure --disable-oldtls --disable-md5

Go to forum: wolfSSL

115 Reply by john

(1 replies, posted in wolfSSL)

The validate date function being used is the one for certificates that is checking for notBefore and notAfter in certificate validity. The one-second window is there for OCSP responses. This detail is on the list of things to address at some point.

Go to forum: wolfSSL

116 Reply by john

(3 replies, posted in wolfSSL)

To clarify "OCSP stapling", we do not support that yet. That involves a TLS Hello extension that we haven't added yet. We do the lookup when receiving the peer's certificate with the Certificates handshake message.

You've probably seen the change in our GitHub repository, but the OCSP interface has been changed to parallel the CRL interface. It no longer requires including the file internal.h.

The OCSP lookup currently only checks the signature against an attached CA certificate.

Go to forum: wolfSSL

117 Reply by john

(1 replies, posted in wolfSSL)

Thank you for the suggestion. I agree that should be changed. The newer OCSP configuration functions parallel the CRL configuration functions. I didn't think to move them outside the NO_FILESYSTEM fence. I have this on my list of things to change.

Go to forum: wolfSSL

118 Reply by john

(2 replies, posted in wolfSSL)

In commit 67b1b00a, there was a fix to allow a server to be missing a requested nonce, as they are supposed to be optional. There have been several other improvements to the OCSP code in the last few months. (Note, it has been tested against connections to the thawte.com and google.com webserver using SSL.)

Go to forum: wolfSSL

119 Topic by john

(0 replies, posted in Announcements)

The new release of CyaSSL, v2.9.0, is now ready to download from our website.  New features include:

- Freescale Kinetis RNGB support
- Freescale Kinetis mmCAU support
- TLS Hello extensions
  * ECC
  * Secure Renegotiation (null)
  * Truncated HMAC
- PKCS #7 Enveloped data and signed data
- PKCS #10 Certificate Signing Request generation
- DTLS sliding window
- OCSP Improvements
  * API change to integrate into Certificate Manager
  * IPv4/IPv6 agnostic
  * example client/server support for OCSP
  * OCSP nonces are optional
- GMAC hashing
- Microchip MPLAB Harmony support
- Additional X.509 inspection functions
- ECC encrypt/decrypt primitives
- ECC Certificate generation

Please see the README and our on-line documentation for more information or feel free to contact us.

http://www.wolfssl.com/

Go to forum: Announcements

120 Reply by john

(3 replies, posted in wolfSSL)

I have fixed this with commit fe4f104. It'll be rolled into the next embedded SSL release.

Go to forum: wolfSSL

121 Reply by john

(3 replies, posted in wolfSSL)

wolfSSL_CTX_OCSP_set_options() and wolfSSL_CTX_OCSP_set_override_url() are better seen as WOLFSSL_CTX functions supporting OCSP, not OCSP functions.

If you look in the header file ocsp.h, you'll see the standalone interface for OCSP. You'll need to include wolfssl/ocsp.h and wolfssl/internal.h (unfortunately, but there is an update planned to merge OCSP in with the stand-alone CertManager with CRL). You'd use it:

{
    int result = 0;
    WOLFSSL_OCSP ocsp;
    
    WOLFSSL_OCSP_init(&ocsp);
    WOLFSSL_OCSP_set_override_url(&ocsp, "http://otherResponder.example.com:8080");
    result = WOLFSSL_OCSP_Lookup_Cert(&ocsp, &dCert);
    WOLFSSL_OCSP_Cleanup(&ocsp);
}

Go to forum: wolfSSL

122 Reply by john

(3 replies, posted in wolfSSL)

geek-mx wrote:

Just in case somebody else has a similar problem, you have to disable
aes-ni, add the flag --disable-aesni to configure

raymundo

Just to clarify, does it work if you leave out both --disable-aesni and --enable-aesni? AES-NI support is disabled by default.

Go to forum: wolfSSL

123 Reply by john

(8 replies, posted in wolfSSL)

You're welcome.

They intentionally undocumented. ECB mode isn't very secure and we encourage use of the other modes.

Go to forum: wolfSSL

124 Reply by john

(8 replies, posted in wolfSSL)

Most projects don't use them directly. We try to wrap optional code with preprocessor switches to make the build smaller for resource constrained embedded systems.

Go to forum: wolfSSL

125 Reply by john

(8 replies, posted in wolfSSL)

Calling AesEncryptDirect() and AesDecryptDirect() provide AES-ECB mode.

Go to forum: wolfSSL