I'm developing a client and a Threaded server in C++ but I'm facing problems with OpenSSL/TLS integration.
So far, I've followed the ThriftServer.cpp and ThriftClient.cpp but I'm getting random errors which cause the crash of my application.
Specifically, the crash happens when a client tries to call the defined thrift interface on the server (already live)
/* server init with PEM public/private certificates
* and trusted certificates, socketFactory->accept(true),
* transport->open() */
myServer->start(); //running on separated thread, calling thriftserver->serve();
/* client init with PEM public/private certificates
* and trusted certificates, socketFactory->accept(true),
* transport->open() */
myClient->beginSession(); //Thrift API call - crash
The crashes are really generic: sometimes it gives me
TConnectedClient died: SSL_accept: error 0
and sometimes
TConnectedClient died: SSL_accept: parse tlsext
and both ending with SIGSEV.
I am running a Debian 8.1 x64 with latest OpenSSL 1.0.2d compiled from sources and flag enable-tlsext, thrift from github/trunk and libevent from github/trunk.
I've tried my custom self-signed certificates and the testing certificates shipped with Thrift: in both cases it doesn't work, but they are working with openssl s_client and openssl s_server
Any idea about the cause of these errors?
EDIT
I've compiled OpenSSL with Thread support (threads flag on ./configure) and now my application triggers always the error
SSL_shutdown: broken pipe
when the client tries to contact the server. Digging more in details, the openssl s_client triggers a
sslv3 alert handshake failure
using TLSv1.2 as protocol. I've checked this other Stackoverflow question but it didn't help, as long as I'm using the latest OpenSSL snapshot already
Regarding the SSL_shutdown problem, according to this document, you are supposed ignore the SIGPIPE signal to avoid server crashes:
SIGPIPE signal
Applications running OpenSSL over network connections may crash if SIGPIPE is not ignored. This happens when they receive a connection reset by remote peer exception, which somehow triggers a SIGPIPE signal. If not handled, this signal would kill the application.
This can be done with:
#include <csignal>
// ...
signal(SIGPIPE, SIG_IGN);
Related
I am building an HTTP(S) server on Intel SGX, using mbedtls as my TLS library.
I can serve content as expected using HTTP, but when switching over to TLS/SSL using mbedtls I am getting some more complex issues and the error messages are difficult to understand.
Concretely, when I access my site using the “https://” prefix, I can tell that mongoose/mbedtls goes out and reads cert.pem and key.pem, and then makes a recv call on “/”. During that recv call it coughs up the following error:
mg_ssl_if_mbed_err 0x7f9e8c023060 mbedTLS error: -0x7780
From mbedtls src I can read this slightly not so useful explanation:
#define MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE -0x7780 /**< A fatal alert message was received from our peer. */
My starting point is the simplest_web_server_ssl.
Questions:
How do I enable mg and mbedtls debug logging?
How do I interpret these errors (or even; what can be some reasons for this error)?
Sincerely grateful for any hints!
See https://github.com/cesanta/mongoose/blob/6.16/mongoose.c#L5161
and https://github.com/cesanta/mongoose/blob/6.16/mongoose.c#L5075
Thus you can increase debug log level by calling cs_log_set_level(LL_VERBOSE_DEBUG)
The error you see is most probably due to the invalid cert your client does not accept.
Try to access your server by curl -k https://IPADDR
-k option disables cert verification. If that curl command works, then just fix your cert - your C code works fine.
I came to you today because I've got a problem with my Client+Server app. I built a server and client app which were working fine with QTcpSocket but I thought about adding some security and going for QSslSocket with delayed handshake. The problem is that my client is acting really weirdly. Here is the situation :
If I use connectToHostEncrypted() in my Client and call startServerEncryption() just after geting the socket in my incomingConnection slot it works fine.
But if I delay the handshake (by doing some read/write in the socket) and call later startServerEncryption(), I got the error : Error during SSL handshake: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number on server side. I've also tried to use startClientEncryption() on client side but I get the same error.
The certificate is self-signed and loaded and applied to the socket correctly on server (I checked by testing the first situation with openssl s_client and the server accept all the protocol that I can test with (SSLv3, TLSv1, TLSv1.1, TLSv1.2).I cannot test with SSLv2 : on the Client, using this protocol with QSslSocket::setProtocol(QSsl::SslV2) show the error unsupported protocol and openssl s_client won't connect with the -ssl2 argument, it just show the available arguments.
I'm using Qt 5.9.1 and I've installed OpenSSL-Win32 v1.0.2L to get the dlls. I'm also compiling with msvc2015 32bit on Windows 7 64bit.
I hope that you can help me (and sorry for my bad english), Nicolas.
I've just found my error : I was using a readyRead slot which was using socket->readAll() and that prevented the SSL handshake ! I've also discovered that you need to call both startClientEncryption and startServerEncryption to make a SSL handshake.
I'm writing server application which uses boost::asio, and libssl via its integration with boost::asio. When there is incoming connection, the first time the handshake succeeded, but after the connection is dropped and the client tries to connect again, the handshake fails with the error:
session id context uninitialized
Here has proposed solution with using SSL_OP_NO_TICKET option when the SSL context is initialized. I'm using it the following way:
m_sslContext.set_options(SSL_OP_NO_TICKET);
In the beginning this resolves the problem, but now despite the option is still set the error appears again. Does anybody has an idea what other can be done with this problem?
I found that when the problem arises I still have an old connection to the same remote endpoint which tries to connect again. When I dropped the old connection properly the problem gone.
I got exactly the same error with client certificate verification enabled.
The solution was to create separate ssl_context for every connection, unlike in boost.asio examples.
One thing to note, SSL stream shutdown never completed in my case, it just would hang indefinitely. Perhaps, because the client didn't implement it correctly.
I'm testing out using DBus for inter process communication for an QT C++ project (Linux).
I'm not using the bus daemon and i'm using unix paths / sockets.
After navigating my way through the mysterious world that is QT DBUS all seemed to be going well, until i wanted to test the robustness of one of my interfaces.
After killing the server process en restarting it, the connection times out.. i cleanup the connection objects (client-side) and i try to re-connect to the server.
The client does not seem to be able to reconnect and i get the following errors:
errName: org.freedesktop.DBus.Error.NoServer
errMesage: Failed to connect to socket /tmp/abcd: Connection refused
Ive tried:
- QDBusConnection::disconnectFromPeer(addr);
- cleaning up all related object, so no references to the connection exist.
When i restart the client, it has no problems connecting to the (restarted) server.
Problem found!
Seems to be a bug in Qt 4.8.x:
https://bugreports.qt.io/browse/QTBUG-27973
https://codereview.qt-project.org/#/c/60709/
QDBusConnection::disconnectFromBus and QDBusConnection::disconnectFromPeer does not remove invalid connection
There is a client/server application written using Boost's ASIO (Boost v.1.48) + OpenSSL (v.1.0.0d). Complete OpenSSL (dynamic/static libraries and binaries) is custom built, the after-build tests are passed correctly and it links to the client and the server statically. ASIO code works in asynchronous mode. All ASIO's SSL contexts use the boost::asio::ssl::context::sslv23
method. The problem description is the following.
Configuration 0
The server: works under Win7 Prof SP1 (Comp0). It uses a self-signed private key (PK0) and a public certificate (PC0) generated by the custom built OpenSSL binaries mentioned above. The server has a infinite timeout.
The client: works under WinXP Prof SP3 (Comp1). It uses the servers public certificate (PC0). The client has 20 secs timeout.
The clients connects successfully to the server but closes the connection by the 20 secs timeout in the SSL's handshake method (boost::asio::ssl::stream::async_handshake). FAIL.
Configuration 1
Both the server and the client run on the same Win7 Prof SP1 (Comp0), use the same ethernet interface and the same PK0/PC0 as in the configuration 0.
The clients successfully connects handshakes, sends/receives data and closes the connection. SUCCESS.
Configuration 2
The server: works under Win7 Prof SP1 (Comp0). It uses a self-signed private key (PK1) and a public certificate (PC1) generated by the custom built OpenSSL binaries BUT the PK1 and PC1 are generated a half of a year ago. PK0/PC0 are generated today. All the keys are generated by the same OpenSSL binaries (v.1.0.0d).
The client: works under WinXP Prof SP3 (Comp1). It uses the servers public certificate (PC1).
The clients successfully connects handshakes, sends/receives data and closes the connection. SUCCESS.
Configuration 3
Both the server and the client run on the same Win7 Prof SP1 (Comp0), use the same ethernet interface and the same PK1/PC1 as in the configuration 2.
The clients successfully connects handshakes, sends/receives data and closes the connection. Obviousely SUCCESS.
Changing the OpenSSL version to the latest stable release (v.1.0.0g) gives the same results.
The problem is not working configuration 0. Has anyone ever had such problem? Are there any ideas where can be the problem cause? In which direction is necessary to move to fix the problem?
Update #1. The code compiled using the tlsv1 method instead of the sslv23 one does not work in the Configuration 0 also.
Final Update. The problem is fixed. The cause is that the Comp1's system date was in the past, i.e. the PK0/PC0 are issued in future for this computer and OpenSSL fails in the handshake procedure. PC1 is issued in the past for the Comp1 and it works with it without problems. To diagnose the problem cause I used the following command executed on the client computer:openssl s_client -connect server_ip:server_port, where server_ip is the server address and server_port is the the server listening port. Now a task is to find a reason why handshake times out rather than returns an error. But it is another story. I hope my post will help someone in future.
The problem is fixed. The cause is that the Comp1's system date was in the past, i.e. the PK0/PC0 are issued in future for this computer and OpenSSL fails in the handshake procedure. PC1 is issued in the past for the Comp1 and it works with it without problems. To diagnose the problem cause I used the following command executed on the client computer:openssl s_client -connect server_ip:server_port
, where server_ip is the server address and server_port is the the server listening port. Now a task is to find a reason why handshake times out rather than returns an error. But it is another story. I hope my post will help someone in future.