I've been developing an embedded system with wolfSSL inside. I have a test program to verify the wolfSSL. I used 'openurl https://www.microchip.com/' to test wolfSSL against the xxx company page.
I tried several other web pages other than www.microchip.com, but the result is the same.
Then I found the server rejected 'Client Hello' with 'handshake failure' (with error code = 40). My question is how I can know the cause of why the server rejected the connection negotiation. How can I know what I could miss before the rejection?
My test program is from Microchip's git hub: "https://github.com/Microchip-MPLAB-Harmony/net_apps_pic32mz/blob/master/docs/GUID-EAFAC274-BD06-4CB8-8797-15A853587DD8.md" and it's supposed to be trustable.
Related
I'm kinda at a loss here.
Trying to set up proton with SSL / TLS access, but after creating the certificates with the (modified) shell scripts
supplied by the AppDev-Pack and linking the keyring and everything in notes.ini, I always seem to get
the error "Handshake failed with fatal error SSL_ERROR_SSL: error: 100000f7:SSL routines:OPENSSL_internal:
WRONG_VERSION_NUMBER".
Tried both a windows and linux server, as well as using the accessing node.js app with and without
certificates - but with no success.
Also tried the troubleshoot section of https://doc.cwpcollaboration.com/appdevpack/docs/en/proton-admin.html and it connected just fine,
but won't if i connect with node.js.
Looks like the error is thrown before a certificate is even checked?
In this example the error is thrown after trying to get a document by UNID.
notes.ini (proton parts)
gRPC Client Error
If someone has an idea how to fix that issue or where to start - that would really help me.
Thanks in advance.
It appears that the client side does not have the secure flag set. At least I get a similar stack when I try to connect without TLS when the server expects TLS.
See the secure attribute when calling useServer() function, and you'll also need to provide the credentials attributes.
What we are trying to do is send an email from a pod (running Linux based on the image "microsoft/dotnet") on a client's Openshift environment using MailKit:
https://github.com/jstedfast/MailKit
We get an exception thrown when trying to set up the SSL Handshake:
MailKit.Security.SslHandshakeException: An error occurred while
attempting to establish an SSL or TLS connection.
System.Security.Cryptography.CryptographicException: Error occurred
during a cryptographic operation
We have tried using the.NET SMTP client as well and it worked (using a secure connection)! Unfortunately this component is now obsolete and Microsoft recommends to use MailKit.
Going through the .NET source code the exception raised is a generic catch all exception which looks like it comes from unexpected code returned from the OpenSSL library. Unfortunately I can't see how to get the error code (it is logged using "Debug.Fail", but I am unable to setup a trace to see it) so I am not sure what it is.
I have written a test just to build the X509Chain. When we have the Revocation Mode set to Online (the default) we get the exception. When the revocation is disabled it seems to build the chain OK.
When I run the test on our Test Openshift environment that is totally independent to the client's we get the following error, but do not see the exception: "unable to get certificate CRL"
The only thing I have noticed about the Revocation List is that there is a LDAP and HTTP URLs. Perhaps there is an issue processing the LDAP URL?
Any help on this would be appreciated!
This is something you should report to github.com/microsoft/dotnet
I have Data Virt running via the standalone.sh script, and can log in with my username and password. My next task is configuring it so that it automatically runs whenever the instance is up and running (without having to execute standalone.sh), and uses SSL (port 443) rather than my username and password to log me in. I added the vault.keystore, dv_keystore.jks, and dv_truststore.jks files, and modified both standalone.sh and standalone.xml, according to the JBoss and other online documentation, to account for using these files. I start the standalone.sh script, which runs without any errors. When I browse to:
http://<IP>:8443/dashboard
after starting standalone.sh, I get the following error:
This page can't be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://:8443 again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4, which is not considered secure. Please contact your site administrator.
The settings Use TLS-1.0-ON, Use TLS-1.1-ON, and Use TLS-1.2-ON are all checked in the Browser properties.
By contrast, when I browse to
http://<IP>:8443/dashboard
when standalone.sh is not running, I get the following:
This page can't be displayed
- Make sure the web address https://:8443 is correct.
- Look for the page with your search engine.
- Refresh the page in a few minutes.
It appears the browser is sensing something going on when standalone.sh is running, but something is not allowing the browser to access the dashboard.
What am I missing here?
Have you validated any other ssl access? Is it just an issue with the dashboard application?
We have seen much more SSL error than before when we move to a new server. The total SSL error rate is not high. Many of them are:
error:140943E8:SSL routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
We finally found these requests are actually successful requests. Why these error was generated is that openssl found these were fatal error. Add more debug info show that:
ssl_callback_info:SSL_CB_READ_ALERT fatal error close notify
But from rfc2246:
7.2.1. Closure alerts
The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack. Either party may
initiate the exchange of closing messages.
close_notify
This message notifies the recipient that the sender will not send
any more messages on this connection. The session becomes
unresumable if any connection is terminated without proper
close_notify messages with level equal to warning.
We are wondering if there some special clients send "alert 0" as fatal . Or this related some known issue of openssl. We are using openssl-1.0.1e now. Before migration we used openssl-1.0.0-25.
Any suggestions would be appreciated.
Update:
I investigated the access log and found almost all the "fatal alert 0" was sent by Safari on Apple devices(Mac, iPhone, iPad).
Through the code of libsecurity_ssl which the library of SSL engine. I found that this library would send "fatal alert 0" in sometimes that was totally different with other SSL libraries, for example openssl, NSS.
SSLFatalSessionAlert(SSL_AlertCloseNotify, ctx);
http://www.opensource.apple.com/source/libsecurity_ssl/libsecurity_ssl-32463/lib/sslRecord.c
This mostly occurred when Safari meet unexpected abort of the connection. As my server would not sent a "warning alert 0" to close the connection.
I am trying to monitor https traffic with Fiddler, using current newest version:2.4.4.5
I've successfully set up https, certificates and I can see the full https encrypted traffic for example browsing my bank's web site.
...however...
When I trying to monitor an other server I got this error message in the response window:
"Failed to secure existing connection for 77.87.178.160. A call to SSPI failed, see inner exception. InnerException: System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm"
For full Fiddler window see:
The client is not a in this case browser, but a custom client program, which communicates with its own server.
My question: Is this exception misleading and in reality some other error prevents the secure channel to set up?
...or...
We have still chance to monitor this https communication?
Thx in advance
What is the client program?
This error typically indicates that that client application is only offering certain HTTPS ciphers, and those ciphers are not supported by Fiddler.
However, in this case, the specific problem here is almost certainly this: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx
The client is trying to use AES with SSLv3, but that isn't one of the valid ciphers for SSL3. As a consequence, the connection fails.
You might be able to workaround this by clicking Rules > Customize Rules. Scroll down to the Main() function and add the following line within the function:
CONFIG.oAcceptedServerHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
Please let me know if this works.
NOTE Current versions of Fiddler offer a UI link for this: Look at the lis of enabled protocols on the HTTPS tab.
Unbelievably this issue is still present some 6 years later.
Just installed the latest version of Fiddle (v5.0.20194.41348), and sure enough on Win7 using Chrome or IE it keeps failing with the dreaded error:
"fiddler.network.https> HTTPS handshake to google.com (for #1) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm"
After some hours of testing, I found a middle ground solution which seems to work with virtually all websites. The aim was to get the highest possible security with no errors in the log. Without needing to add any code, simply changing this line under Tools > Options > HTTPS > Protocols is what worked for me (just copy and paste it):
<client>;ssl3;tls1.1;tls1.2
Basically removed the ssl2 and tls1.0 protocols which leaves us with some pretty decent security and no errors so far. Having spent hours of frustration with this error, hope someone out there might find this useful, and a big thanks to EricLaw who discovered the root of the problem.
Yes I too have seen this error when working outside of fiddler and it was connected with AuthenticateAsServer but only went wrong when using IE10 and not Chrome as the browser.
Odd thing is that it did not break all the time for IE10 using SslProtocols.Tls for the protocol so I will add a bit of code to switch the protocol if one fails
The protocol that can be used also seems to change on if you are using a proxy server like Fiddler or using an invisible server by hijacking the DNS via the hosts file to divert traffic to the server