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.
Related
I developed a SSLProxy as a man in the middle between client and server. Handshaking between client-proxy and proxy-server doing well. I receive a message from client and decrypt it with client_side SSL. Then encrypt it with server_side SSL. All thing is good except on thing: OpenSSL received all the message data in one SSL record but it sent them in 2 SSL records.
Question: How can I force OpenSSL to send data in 1 SSL record, because server configured only to use 1 SSL record?
Wireshark Screen:
192.168.2.127 is client.
192.168.0.230 is server.
Update: I need something like this. I tried to use them but I faced with this error:
error: ‘SSL_CTX_set_split_send_fragment’ was not declared in this scope
With SQL Server 2008 R2 SP3 and update KB3144114 to support TLSv1.2 my problem solved. But In SQL Server 2008 R2 (with TLSv1) problem still remain same as before and I couldn't find any solution for it.
You must use OpenSSL 1.1.X series for using "SSL_CTX_set_split_send_fragment function", that function is not available in older versions.
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);
I've been looking through the poco samples and documentation, but I couldn't find out how to use poco's websockets and SSL combined. I successfully connected a non-SSL websocket (based on the WebSocket class) to a server (the echoserver sample from Qt5.4, running on Ubuntu), but how to add SSL to the client eludes me. Poco's NetSSL_OpenSSL samples aren't all that helpful, because I don't need to know how to download, tweet, mail or write a time server. Also the latter is the only one that uses "SecureStreamSocket" objects at all (which is probably the class I need). But that sample just accesses the socket from the request object, it doesn't show how to create and configure one properly.
I just want an SSL websocket client to send and receive some simple messages, like "Hello World". Can anyone help me please?
I use Windows 7 64 Bit for the client's OS and Ubuntu 64 Bit on VirtualBox for the server's OS, but the server side is no problem. My poco version is 1.6.0 and I compiled it with Visual Studio 2013 Express. Also I use OpenSSL 1.0.1j.
Cheers
Alex
Look at WebSocket testcase. Use HTTPSClientSession (instead of HTTPClientSession).
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.
Quite new to boost and asio, need help:
connect to proxy
asio::ip::tcp::socket socket_;
send CONNECT host: ssl server to the proxy
receive response 200
asio::ssl::context ctx(io_service, asio::ssl::context::sslv23);
sslsocket_(socket_,context)
try handshake
sslsocket_.async_handshake(asio::ssl::stream_base::client, boost::bind(&client::handle_handshake, this, asio::placeholders::error));
and get asio.ssl error
Wireshark: host sends FIN after 1st message of handshake
Direct async connection to ssl server works fine, same through Proxifier
You'll probably need to examine the OpenSSL error stack in step 5, which isn't terribly easy since Boost.Asio doesn't map it into the normal system_error codes that it uses. There was a post by Guy Sirton recently on the asio mailing list describing how to modify the source to accomplish this.
Forgot to mention that was running the application in VMplayer with NAT network; bridged removed the problem with initial handshake but sometimes after reconnect saw the same message;
using the method in Sam's link got to "unexpected record" during handshake - google said on this error about renegotiations but that was not the case; digging into sources of OpenSSL: the new connection used the same BIO for reading and recevied application data from previous connection
Don't know how to reset the SSL structure with asio, so made dynamic socket allocation with new|delete