You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by raysatiro
Pages 1
I did make an attachment to the post but for whatever reason it isn't showing up, so I will try inlining a link with img:
Please be advised google search is indexing test.wolfssl.com, and those links appear to be inaccessible to the public at least today when I tried. The links are https and the CA is untrusted. Web debugger output in Windows:
The server (test.wolfssl.com) presented a certificate that did not validate, due to RemoteCertificateNameMismatch, RemoteCertificateChainErrors.
0 - A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
SUBJECT: E=testing@wolfssl.com, CN=https://192.168.1.109/jenkins/, OU=wolf_test_team, O=testing_wolfssl, L=Bozeman, S=Montana, C=US
ISSUER: E=testing@wolfssl.com, CN=https://192.168.1.109/jenkins/, OU=wolf_test_team, O=testing_wolfssl, L=Bozeman, S=Montana, C=USSee attached screenshot also
Thanks for the update Chris!
Thanks Chris, you're right it was the lack of AESNI.
I ran some upload speed tests recently using curl as a client to apache httpd on localhost and compared SSL backends OpenSSL 1.0.2g, WinSSL (Windows 7) and wolfSSL v3.9.0. wolfSSL was the slowest by a lot and I can't figure out why. I asked my colleague to test in Linux and he could not reproduce using v3.7.0. I tried v3.7.0 but I get the same speeds. I thought maybe it could be the options I was using so I recompiled wolfSSL v.3.9.0 in Visual Studio using nothing but OPENSSL_EXTRA. Still, the speeds are slower by comparison.
For example:
HTTPS: 'DLL Release - DLL OpenSSL' x64 - CURL_MAX_WRITE_SIZE 16384
Transfer rate: 224976 KB/sec (4000000000 bytes in 17 seconds)
HTTPS: 'DLL Release - DLL wolfSSL' x64 - CURL_MAX_WRITE_SIZE 16384
Transfer rate: 15148 KB/sec (4000000000 bytes in 258 seconds)
I did some profiling and GHASH was taking most of the time. Do you have any idea what would cause such a significant difference? Have you noticed a performance decrease in Windows at high speeds?
That sounds like it could help with performance if multiple threads are using wolfSSL. Is there any disadvantage to enabling it in Windows?
Ok. Some SSL libraries have done various mitigations as cited in that notice, for example Microsoft's schannel they disabled certificate changes and later went on to add extended master secret binding support. I thought maybe there was a similar mitigation in wolfSSL.
Secure renegotiation (RFC 5746) was indeed meant to fix the original or "insecure" renegotiation.
Our comments about attacks on Secure Renegotiation are instead directly related to the new "secure" version, specifically the 3SHAKE attack which takes advantage of an incorrect assumption made in the Secure Renegotiation spec:
If secure renegotiation is used in wolfSSL it is vulnerable to that attack?
I'm reading "CyaSSL Secure Renegotiation, Documentation and Users Guide, October 13th, 2014, version 3.2.2"
It says "CyaSSL now supports client side Secure Renegotiation. wolfSSL strongly discourages the use of Secure Renegotiation because of attacks that can exploit the lack of secret binding inherit in renegotiation."
Wasn't secure renegotiation in rfc5746 to fix what you're describing? Is there some other attack that makes it no longer secure, and can you please explain. Thanks
Do you need HAVE_THREAD_LS if you're building wolfSSL for Visual Studio? What happens if you don't use it?
Is there any way to get the version at runtime instead of compile-time?
Not at the moment, no. Is this a feature that you need?
I think it could be useful for when wolfSSL is a shared library to determine which version is loaded. There may be a time where the version that is compiled against is not the version that is loaded. Though I'd like it I don't think I need it. In the libcurl interface code for various SSL backends it looks to be standard practice that any SSL library version comparisons are done at compile-time not at runtime. Thanks again.
wolfSSL has never supported SSL 2.0. It was considered insecure at the time we began writing wolfSSL as a project, thus left it out.
In <wolfSSL/version.h>, you can find the version of wolfSSL installed with either the LIBWOLFSSL_VERSION_STRING or LIBWOLFSSL_VERSION_HEX define.
Thanks Chris.
I notice 3.3.0 has dropped the SSLv2 hello, did you have that for SSLv3 since SSLv2 was never supported?
Is there any way to get the version at runtime instead of compile-time?
Background:
Hello I am working on an option for libcurl called CURL_SSLVERSION_SSLv3_OR_LATER. The option will allow legacy behavior to mimic the way CURL_SSLVERSION_DEFAULT used to work, before SSLv3 was disabled by default due to POODLE. In other words the option will attempt to enable SSLv3 protocol in the respective SSL library if possible. The idea is to give some of the old compatibility.
To implement the option in the code that interfaces with wolfSSL I set the request method via SSLv23_client_method and then later in the code if wolfSSL >= 3.3.0 I set the minimum protocol version to the least of SSLv3, TLSv1.0, TLSv1.1, TLSv1.2.
Questions:
If wolfSSL < 3.3.0 I figured that SSLv23_client_method would always give a minimum of SSLv3 without any other calls, and that's how I implemented it. One of the other developers has pointed out that "this patch seems to enable SSLv2 for the wolfSSL back-end when the new option is used." Is that possible in some version <3.3.0? The documentation I read (3.2.0) says SSL3 - TLS 1.2 but I don't know if for some earlier version you allowed SSLv2.
I would like to know how in versions <3.3.0 I can ensure a minimum version of SSLv3, or as close to it as possible. For example if SSLv3 was disabled in wolfSSL at compile time and truly the plumbing isn't there, then I would use TLSv1.0, and if that's disabled then TLSv1.1, and so on.
Also, is there any way at runtime to get the version of the wolfSSL library? I did check the documentation but I don't see it. I'm thinking about shared libraries and the possibility if libcurl is compiled with one version of wolfSSL but then at runtime some other wolfSSL is loaded (by mistake, an upgrade, etc).
Thanks
Hello I am trying to understand better the OpenSSL compatibility. For example, ERR_error_string maps to CyaSSL_ERR_error_string, which has behavior different from OpenSSL's ERR_error_string. For example OpenSSL's version returns the error string in a static buffer in the case of a NULL pointer but the wolfSSL version does not. To me that doesn't seem compatble but that is what I'm here to figure out, just how compatible it actually is intended to be (not just for this case specifically but in general). If you know of any other compatibility functions that may have similar quirks please let me know so I can investigate. Thanks
Pages 1
wolfSSL - Embedded SSL Library → Posts by raysatiro
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.017 seconds (95% PHP - 5% DB) with 5 queries
