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.
Related
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 am searching for a client TLS connection example in C++. Best for Visual Studio, but honestly it can be any compiler. I found several C samples. But no one worked. I started with this sample in C:
https://wiki.openssl.org/index.php/SSL/TLS_Client
But it failes on
res = BIO_do_connect(web);
with "system library" if I want to connect to my own node.js server (using the direct ip address) or with "bad hostname lookup" using encrypted.google.com as url.
Both with libressl and Visual Studio 2013.
Next stop: http://fm4dd.com/openssl/sslconnect.htm
Here the program runs successful. But any attempt to write to the SSL connection at the end with:
std::string json = "{'test':'huhu'}";
char buff[1024];
sprintf(buff, "POST /test.de HTTP/1.1 \nHost: test.de\nContent-Type: application/json\nContent-Length: %d\n\n", json.length());
std::string post = buff;
int snd = SSL_write(ssl, post.data(), post.length());
snd = SSL_write(ssl, json.data(), json.length());
forces the server to close the connection (I do not see exactly what happend as I do not now how I can tell node.js to tell me more).
So I search for a working sample or how to get a TLS connection with own certificate running in C++
I am searching for a client TLS connection example in C++.
I think there are a couple of ports of OpenSSL to C++. They try to do the full class wrapper thing. See openssl++ class on Google.
When I use it in C++, I use unique pointers for cleanup. See, for example, How to properly print RSA* as string in C++?. I use it primarily to ensure cleanup. I think its similar to Resource Acquisition Is Initialization pattern.
OpenSSL also provides a page for similar libraries and frameworks. See the Related Links page on the OpenSSL wiki.
But it fails on
res = BIO_do_connect(web);
with "system library" if I want to connect to my own node.js server (using the > direct ip address) or with "bad hostname lookup"
My guess here would be the name in the certificate does not match the name used in the URL to connect.
You can make the names work by adding an entry in your host file. Effectively, this is your local DNS override. See Microsoft TCP/IP Host Name Resolution Order.
Or, you can generate a certificate with all the required names. For that, see How to create a self-signed certificate with openssl?
forces the server to close the connection (I do not see exactly what happend as I do not now how I can tell node.js to tell me more).
"POST /test.de HTTP/1.1 \nHost: test.de\nContent-Type:
application/json\nContent-Length: %d\n\n"
Since you lack the Connection: close request header, the server is probably following RFC 7230, HTTP/1.1 Message Syntax and Routing, Section 6.1:
A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not
have a 1xx (Informational) status code.
Also, that should probably be:
"POST /test.de HTTP/1.1\r\nHost: test.de\r\nContent-Type:
application/json\r\nContent-Length:%d\r\n\r\n"
\r\n is used as new line, not \r and not \n. A double \r\n is used to terminate the header. You can quickly verify be searching for "CRLF" in the standard. You will land in a discussion of the ABNF grammar.
So I search for a working sample or how to get a TLS connection with own certificate running in C++
The trick here is creating a well-formed certificate. For that, see How to create a self-signed certificate with openssl?
Here's an updated example for LibreSSL using pinned cert bundle: C++ libtls example on github
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).
I am trying to send messages from a windows client to a linux server using the REQ/REP pattern with ZeroMQ. The server side code is the hwserver.cpp code from the examples of the 0MQ guide. And for the client side I also use the example code hwclient.cpp.
Now the problem at hand is the following. If I use a Linux server and client I am able to send messages, receive them and send a reply back which is also received. When the server and client are both run in Windows I also can receive and send messages. If the server is running in Windows and the client is running in Linux it also works. These tests make me think I have at least the correct IP adresses.
When I try to use a Linux server and a Windows clien, the messages that are send do not arrive at the server. And I don't know what could cause this, since the reverse with a Windows server + Linux client works perfectly. I found a similar question but the solution posted there did not work.
I use Fedora 20 with g++ 4.8.3 and Windows 8 with Microsoft Visual Studio 2013.
Is there an option that has to be flagged when doing this kind of 0MQ connection ?
Once ZeroMQ version numbers match, there need not be any further "magic-switch" for Window$
n.b.:
socket.connect ("tcp://<_aUbuntuHOST_IpADRESS_>:5555"); // Do W8 allow outbound tcp:5555 connection in the security policy in effect?
May you proof that the Win integrated firewall policies ( explicit security settings permit exceptions ) do allow a process to request + use an outgoing tcp connection on the specified port number?
May reverse .bind() / .connect() on REQ/REP sides to remain on the same situation as that was working once you had Ubuntu.REQ ( with .connect() ) and the W8.REP ( with .bind() ) so the W8.REQ would again .bind() ( which you reported that worked fine ) & Ubuntu.REP would .connect()
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.