26 Reply by todd

(1 replies, posted in wolfSSL)

Thanks for the suggestion.  I added wolfSSL_peek() to wolfSSL embedded ssl instead to make it clear the user is requesting a peek instead of a potential programming error: https://github.com/cyassl/cyassl/commit … bb013faeb8

Go to forum: wolfSSL

27 Reply by todd

(1 replies, posted in wolfSSL)

Thanks for the suggestion.  When we add support for small frame MTUs in a coming version of wolfSSL embedded ssl we'll make sure this works.

Go to forum: wolfSSL

28 Reply by todd

(1 replies, posted in wolfSSL)

Thanks for the question.  Currently wolfSSL embedded SSL only defragments received messages.  A client would normally never need to send fragmented messages unless it's using large client certificates, which is unusual.  Next on the feature list is sending fragmented messages which will allow servers and clients using certificates to work as well.

Go to forum: wolfSSL

29 Reply by todd

(3 replies, posted in wolfSSL)

Thanks for the reports.

1) How did you get our embedded SSL source?  The downloadable 2.4.0 should have cyassl/version.h in the .zip.  Our github tree also has it checked in although there was a day where it was missing in the last couple weeks.

2) The latest github tree now has fixes for all of these warnings on Windows x64 except for...

3) The 64 bit shift warning.  Using i64 isn't portable.  We do have a somewhat portable 64bit macro W64LIT except for platforms that don't have 64bit types available of course.  It doesn't make any sense to me to have the index of the array use a 64 bit type, especially since it isn't portable to many of our platforms.  We could explicitly cast the shift to 32 bits but that just makes the code harder to read there.  I'm going to leave that warning for now.  We'll discuss it at our next meeting.

Thanks again for the reports.

Go to forum: wolfSSL

30 Reply by todd

(1 replies, posted in wolfSSL)

Thanks for the report!  I just pushed a fix for this to our embedded SSL library.  Specs are now initialized on creation, the client key exchange state is checked before processing, and a specific error for bad kea type was added.  I'll have to check whether the same thing can now happen with an out of order finished or app data message.

Go to forum: wolfSSL

31 Reply by todd

(9 replies, posted in wolfSSL)

Just commited a fix.

You can always remove -Werror from the Makefile to get past these warning errors as we're testing all compilers/versions/systems with the recent decision to treats warnings as errors in the source tree.  The release versions won't have this restriction.

Go to forum: wolfSSL

32 Reply by todd

(5 replies, posted in wolfSSL)

Thanks for the excellent report!  wolfSSL embedded ssl 2.4.0 will have a different memory allocation system whereby it will release memory handshake memory when done with the handshake.  In this case, the ciphers weren't being properly allocated because the client was assuming the resumption worked even when it didn't.  I've checked in a fix for this and other related problems by adding a cipher setup flag.

Thanks again for the report and let us know if you run into anything else.

Go to forum: wolfSSL

33 Reply by todd

(12 replies, posted in wolfSSL)

ripemd and hc128 aren't used by browsers.  aesni is a way to process AES in hardware on a compatible Intel chipset, but it's still just normal AES to the browser.  aesgcm is starting to be used by browsers.

Go to forum: wolfSSL

34 Reply by todd

(12 replies, posted in wolfSSL)

It looks like you're adding options, at least --enable-aesni.  What else are you adding?

I've checked in a fix for the new warning system with aesni.

Go to forum: wolfSSL

35 Reply by todd

(12 replies, posted in wolfSSL)

Can you do a git pull

./autogen.sh
./configure
make clean
make
?

I just checked in some changes for the new build warnings/errors for linux64.

Go to forum: wolfSSL

36 Reply by todd

(8 replies, posted in wolfSSL)

Everything you note seems correct.  If I was a browser though I would disallow renegotiation completely unless it was secure.  Seems pretty simple.  Same on the server.

That said, we do want to be compliant with the major implementations, both client and server.  And because of that, secure renegotiation is on our roadmap for the end of the year.

Thanks for the informative post and links.  We'll post back when it's done or if we have other ideas.

Go to forum: wolfSSL

37 Reply by todd

(4 replies, posted in wolfSSL)

You can see the commit here: https://github.com/cyassl/cyassl/commit … ec657b859e

Go to forum: wolfSSL

38 Reply by todd

(4 replies, posted in wolfSSL)

Thanks antoxa!

I've pushed your fix for corrupted or malicious change cipher spec messages along with a debug message for that case to our embedded SSL repo.  I've also added protection against multiple in-place decryptions of the same record for malicious or corrupted messages.  Thanks again for the help and patch.  What are you working on if you don't mind me asking?

-Todd

Go to forum: wolfSSL

39 Reply by todd

(3 replies, posted in wolfSSL)

Thanks Joe!

We've added the feature but in the current wolfSSL ASN framework.  It's now available on github.

Go to forum: wolfSSL

40 Reply by todd

(3 replies, posted in wolfSSL)

You are correct, wolfSSL doesn't currently have the equivalent Alt Names processing except to get the raw names.  It is on our feature list.

Go to forum: wolfSSL

41 Reply by todd

(3 replies, posted in wolfSSL)

No replacement is on the map yet.

If you --enable-yassl-testing the same ParseCert() is called with the same arguments.  Also, SSL_connect() calls ParseCert().  I've never seen this stack problem in those instances.  Is it possible something else is damaging the stack and you're just seeing it then?

Go to forum: wolfSSL

42 Reply by todd

(1 replies, posted in wolfSSL)

Hi Stéphane,

Thanks for the report.  There was a bug where the hiLen in bits was using the already shifted value of loLen.  I checked in a patch on our github tree.  Thanks again for the report.

-Todd

Go to forum: wolfSSL

43 Reply by todd

(8 replies, posted in wolfSSL)

Yes.  wolfSSL is good to use for the SSL handshake.  See the echoserver example for maximum browser compatibility.

Go to forum: wolfSSL

44 Reply by todd

(8 replies, posted in wolfSSL)

Hard to say.  Wireshark will provide more info about what's happening at the handshake level and if you're actually getting that far.  Could be a protocol version problem.

Go to forum: wolfSSL

45 Reply by todd

(8 replies, posted in wolfSSL)

No, after the client gets a "Connection established" it starts a SSL/TLS handshake.  After that is complete it will issue a GET or whatever it wants.

The easiest way to monitor this is to put Wireshark between the browser and proxy.  Make sure what you think is happening is happening.

The browser is not going to like having wolfSSL pretend to be the server.  The hostname of the certificate won't match and it won't be signed by a trusted authority.  This is not a simple task.  Read up on the relevant RFCs for HTTP,SSL, proxies.

Go to forum: wolfSSL

46 Reply by todd

(8 replies, posted in wolfSSL)

wolfSSL handles SSL/TLS encrypted traffic only.

wolfSSL doesn't "know" protocols that sit on top SSL/TLS.  Though wolfSSL can certainly be used to implement them.

Shouldn't the proxy send back "HTTP/1.0 200 Connection established" to a CONNECT request after doing a TCP connect to the server?  Also, CONNECT is an SSL tunnel meaning the browser is the SSL client and the web server is the SSL server.  The proxy just passes the tunneled info back and forth.  How is wolfSSL fitting into this?

How do you pass unencrypted traffic to wolfSSL?  If you issue a wolfSSL_accept() it should return with an error.

Go to forum: wolfSSL

47 Reply by todd

(14 replies, posted in wolfSSL)

Part of the problem is probably that sites often use redirection, sometimes multiple, depending on the address used, current login status, etc.  For example, hotmail may take you to the login which has a different certificate and chain than the actual mail certificate and chain.  When you connect directly with CyaSSL you are first having to go through the login process I'm guessing.  Maybe you should start with some simpler fixed certificate sites?  The CyaSSL example echoserver is a verify simple https web server.

Go to forum: wolfSSL

48 Reply by todd

(14 replies, posted in wolfSSL)

"I tried exporting all of these, none work, again PEM format."

What do you mean by none work?  The export failed, if so, how?  The CyaSSL CTX load in PEM failed, if so, how?  The SSL connect failed, if so, how?

In your example, only the Root certificate, the one starting with "Builtin Object" will need to be loaded.  In my Firefox I can export a certificate with the Format "X.509 Certificate (PEM)" which CyaSSL should have no trouble loading.

Go to forum: wolfSSL

49 Reply by todd

(15 replies, posted in wolfSSL)

Hi Nitin,

Thanks for sending the CA (rootcert) and generated certs.  wolfSSL is setting the correct issuer information but in a different order than the OpenSSL generated one.  I've never seen OpenSSL do this before (with that order that is), what version are you using?  My understanding is that the name information should go

C (Country)
ST (State)
L (Locality)
O (Organization)
OU (O Unit)
CN (Common Name)
/optional like email

In the short term I guess you'll have to use the same SSL package to do the CA and issued certificates, which is pretty common I suppose.  If we can confirm that OpenSSL is correct in varying the order of the issuer information we'll have to patch wolfSSL to copy the issuer information verbatim instead of trying to interpret it and reorder it.

Thanks for the report. 

-Todd

Go to forum: wolfSSL

50 Reply by todd

(15 replies, posted in wolfSSL)

Nitin,

I've tested code generated keys and certs on our end and they're working fine here.

Notes:  your uploaded certs differ in another major way.  The openssl one is self-signed, look at the issuer and subject, they match.  You can look at the metadata of a certificate by adding -text to the openssl command.  The wolfSSL one is not self signed, it's issued by:

Issuer: C=US, ST=Arizona, L=Tucson, O=Root Certification Authority, OU=UA, CN=Root CA/emailAddress=ca@provenance.edu

Which is not the same as wolfSSL's test ca-cert.pem.  I have a feeling that the CA certificate you're trying to tell echoserver to load_verify with isn't the right one (either because of naming, working directory, many different iterations, etc...  It's hard to know exactly)  Can you give it another look?

-Todd

Go to forum: wolfSSL