Hello I'm trying to connect to a server:
argv[1] = "demo.demo.com"; // or httpbin.com
argv[2] = "39473"; // or 80
With this similar code:
http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/example/ssl/client.cpp
The problem I am getting is this:
Handshake failed: certificate verify failed
I have tried this:
boost::asio::ssl::context ctx(boost::asio::ssl::context::sslv23);
ctx.set_verify_mode(boost::asio::ssl::verify_none);
//ctx.set_default_verify_paths();
Is there a way to just connect without verifying certificate.
You could add a verification callback that returns true:
socket_.set_verify_callback(
boost::bind(&client::verify_certificate, this, _1, _2));
Where
bool verify_certificate(bool preverified,
boost::asio::ssl::verify_context& ctx)
{
return true;
}
So the error indicates that the returned certificate does not match the one that was loaded. In the example code, the loaded certificate occurs here:
ctx.load_verify_file("ca.pem");
As a test, you might try the following. Issue this command in a CMD shell (I'm assuming you have openssl installed):
openssl s_client -connect demo.demo.com:39473 -showcerts
Examine the returned output, and compare it to your ca.pem file. I bet they are different. You could even try replacing the content of your ca.pem file with the returned text from opensll, and hopefully that works.
Your mileage may vary.
Related
When attempting to securely connect to a remote IMAP server using Boost ASIO, the server handshake fails on every connection. The exception message reads:
handshake: unregistered scheme (STORE routines) [asio.ssl:369098857]
My code is below (url is a std::string_view containing the host URL):
using boost::asio::ip::tcp;
namespace ssl = boost::asio::ssl;
using SSLSocket = ssl::stream<tcp::socket>;
boost::asio::io_context context;
ssl::context ssl_context(ssl::context::tls);
SSLSocket socket(context, ssl_context);
ssl_context.set_default_verify_paths();
tcp::resolver resolver(context);
auto endpoints = resolver.resolve(url, "993");
boost::asio::connect(socket.next_layer(), endpoints);
socket.set_verify_mode(ssl::verify_peer);
socket.set_verify_callback(ssl::host_name_verification(url.data()));
socket.handshake(SSLSocket::client);
The code immediately throws an exception on the final line, which is a blocking synchronous handshake.
The prior two lines set up host name verification, similar to how it's done in the official ASIO tutorial. These checks seem to be causing an issue, however, because when they are removed the handshake succeeds. Obviously, this is not a good solution.
After stepping through some of ASIO's internals, I found that the last three lines of the above snippet could be replaced by:
SSL_set_verify(socket.native_handle(), SSL_VERIFY_PEER, nullptr);
socket.handshake(SSLSocket::client);
and the same error occurs. SSL_set_verify is an OpenSSL function, and the fact that setting a null callback directly causes the same issue makes me think that the issue is with my system's OpenSSL environment and not ASIO or the host name verification callback. However, I have not been able to determine what exactly the error means and what could be causing it.
Here is a list of things I have tried while troubleshooting:
Load the system's certificate (.pem) file explicitly Thinking maybe ASIO and/or OpenSSL's were not able to load the right certificates to do the validation, I found my system's (a Mac) certificate file at /private/etc/ssl/cert.pem. I then inserted the following line:
ssl_context.load_verify_file("/private/etc/ssl/cert.pem");
directly after set_default_verify_paths() is called. My program loads this certificate file without complaining, but it doesn't fix the handshake error.
Use a different version of OpenSSL At first I was using Apple's system version of OpenSSL (which is really LibreSSL 2.8.3). I then rebuilt my code using the Homebrew package manager's version of OpenSSL (OpenSSL 3.0.4). This also did not fix the issue, even when I tried calling load_verify_file as in point 1.
Sanity check using the OpenSSL command-line tool To make sure my network connection and URL/port number were correct, I tried connecting to the IMAP server over SSL using the following command:
openssl s_client -connect my.url.com:993 -crlf -verify 1
and it worked fine, connecting to the IMAP server and enabling me to send/receive IMAP responses.
Has anyone encountered similar issues when using OpenSSL and ASIO? I'm not very familiar with setting up an SSL/TLS connection, but I don't see what could be causing the problem.
Thanks for your help!
Given that openssl s_client -connect my.url.com:993 -crlf -verify 1 succeeds there is not a lot that seems wrong. One thing catches my eye: I'd configure the context before constructing an SSL stream from it:
ssl::context ssl_context(ssl::context::tls);
ssl_context.set_default_verify_paths();
SSLSocket socket(context, ssl_context);
Also, openssl likely uses SNI extensions:
// Set SNI Hostname (many hosts need this to handshake successfully)
if(! SSL_set_tlsext_host_name(socket.native_handle(), hostname.c_str()))
{
throw boost::system::system_error(
::ERR_get_error(), boost::asio::error::get_ssl_category());
}
Finally, make sure the url string view contains correct data, notably that it's a valid hostname and null-terminated string. In this case I'd prefer to use a string representation that guarantees null-termination:
Summary
#include <boost/asio.hpp>
#include <boost/asio/ssl.hpp>
using boost::asio::ip::tcp;
namespace ssl = boost::asio::ssl;
using SSLSocket = ssl::stream<tcp::socket>;
int main() {
boost::asio::io_context context;
ssl::context ssl_context(ssl::context::tls);
ssl_context.set_default_verify_paths();
SSLSocket socket(context, ssl_context);
tcp::resolver r(context);
std::string hostname = "www.example.com";
auto endpoints = r.resolve(hostname, "443");
boost::asio::connect(socket.next_layer(), endpoints);
socket.set_verify_mode(ssl::verify_peer);
socket.set_verify_callback(ssl::host_name_verification(hostname));
// Set SNI Hostname (many hosts need this to handshake successfully)
if(! SSL_set_tlsext_host_name(socket.native_handle(), hostname.c_str()))
{
throw boost::system::system_error(
::ERR_get_error(), boost::asio::error::get_ssl_category());
}
socket.handshake(SSLSocket::client);
}
In my case I manged to make it work with this:
ssl_context.load_verify_file("/etc/ssl/certs/ca-bundle.crt");
so pointing to the ca-bundle file instead of the cert file.
I'm on Windows 10, VS2019, 64-bit grpc v1.23.1-1 installed via vcpkg.
Using grpc's ServerBuilder class. From the examples provided, the server code should look similar to this:
const std::string server_address = "0.0.0.0:12345";
int tcp_port;
grpc::ServerBuilder builder;
builder.AddListeningPort(server_address, grpc::InsecureServerCredentials(), &tcp_port);
builder.RegisterService(&myservice);
auto server(builder.BuildAndStart());
std::cout << "port=" << tcp_port << std::endl;
server->Wait();
No matter what I try to use for server_address, the resulting tcp_port is always zero, and calling netstat to view all listening ports confirms my application isn't listening anywhere.
The AddListeningPort() API is documented here.
Examples of addresses I've tried so far:
[::1]:54321
dns:///[::1]43210
dns:///::1:
::1
::1:
0.0.0.0:12345
localhost
localhost:7525
127.0.0.1
127.0.0.1:9876
(I've tried dozens of random port numbers, not just the ones here, and netstat confirms I don't have anything bound to those ports.)
Is there any way to get more information from grpc? There doesn't seem to be any API to call within grpc::Server nor grpc::ServerBuilder to get an error code, status message, etc.
EDIT:
For people googling things related to grpc in the future, I've edited the example code to move the std::cout line further down, since the port isn't valid until after the call to BuildAndStart() (Thanks #Botje.)
Also determined why netstat on Windows wasn't showing me my application. I was using this command:
netstat -q -b -n -p tcp
But to see IPv6/TCPv6, I needed this:
netstat -q -b -n -p tcpv6
Since the address was similar to this ipv6 loopback: [::1]:12345.
Note that you can call this more than once, so now I'm using something similar to these lines:
builder.AddListeningPort("127.0.0.1:12345", grpc::InsecureServerCredentials(), &tcp4_port);
builder.AddListeningPort("[::1]:12345", grpc::InsecureServerCredentials(), &tcp6_port);
The documentation has this to say about selected_port:
If not nullptr, gets populated with the port number bound to the grpc::Server for the corresponding endpoint after it is successfully bound by BuildAndStart(), 0 otherwise. AddListeningPort does not modify this pointer.
And for addr_uri:
To bind to any address, please use IPv6 any, i.e., [::]:<port>, which also accepts IPv4 connections.
Try passing "[::]:12345" as addr_uri and only checking the value of tcp_port after calling BuildAndStart.
I'm trying to implement OpenSSL into my application which uses raw C sockets and the only issue I'm having is the SSL_accept / SSL_connect part of the code which starts the KeyExchange phase but does not seem to complete it on the serverside.
I've had a look at countless websites and Q&A's here on StackOverflow to get myself through the OpenSSL API since this is basically the first time I'm attempting to implement SSL into an application but the only thing I could not find yet was how to properly manage failed handshakes.
Basically, running process A which serves as a server will listen for incoming connections. Once I run process B, which acts as a client, it will successfully connect to process A but SSL_accept (on the server) fails with error code -2 SSL_ERROR_WANT_READ.
According to openssl handshake failed, the problem is "easily" worked around by calling SSL_accept within a loop until it finally returns 1 (It successfully connects and completes the handshake). However, I do not believe that this is the proper way of doing things as it looks like a dirty trick. The reason for why I believe it is a dirty trick is because I tried to run a small application I found on https://www.cs.utah.edu/~swalton/listings/articles/ (ssl_client and ssl_server) and magically, everything works just fine. There are no multiple calls to SSL_accept and the handshake is completed right away.
Here's some code where I'm accepting the SSL connection on the server:
if (SSL_accept(conn.ssl) == -1)
{
fprintf(stderr, "Connection failed.\n");
fprintf(stderr, "SSL State: %s [%d]\n", SSL_state_string_long(conn.ssl), SSL_state(conn.ssl));
ERR_print_errors_fp(stderr);
PrintSSLError(conn.ssl, -1, "SSL_accept");
return -1;
}
else
{
fprintf(stderr, "Connection accepted.\n");
fprintf(stderr, "Server -> Client handshake completed");
}
This is the output of PrintSSLError:
SSL State: SSLv3 read client hello B [8465]
[DEBUG] SSL_accept : Failed with return -1
[DEBUG] SSL_get_error() returned : 2
[DEBUG] Error string : error:00000002:lib(0):func(0):system lib
[DEBUG] ERR_get_error() returned : 0
[DEBUG] errno returned : Resource temporarily unavailable
And here's the client side snippet which connects to the server:
if (SSL_connect(conn.ssl) == -1)
{
fprintf(stderr, "Connection failed.\n");
ERR_print_errors_fp(stderr);
PrintSSLError(conn.ssl, -1, "SSL_connect");
return -1;
}
else
{
fprintf(stderr, "Connection established.\n");
fprintf(stderr, "Client -> Server handshake completed");
PrintSSLInfo(conn.ssl);
}
The connection is successfully enstablished client-side (SSL_connect does not return -1) and PrintSSLInfo outputs:
Connection established.
Cipher: DHE-RSA-AES256-GCM-SHA384
SSL State: SSL negotiation finished successfully [3]
And this is how I wrap the C Socket into SSL:
SSLConnection conn;
conn.fd = fd;
conn.ctx = sslContext;
conn.ssl = SSL_new(conn.ctx);
SSL_set_fd(conn.ssl, conn.fd);
The code snippet here resides within a function that takes a file-descriptor of the accepted incoming connection on the raw socket and the SSL Context to use.
To initialize the SSL Contexts I use TLSv1_2_server_method() and TLSv1_2_client_method(). Yes, I know that this will prevent clients from connecting if they do not support TLS 1.2 but this is exactly what I want. Whoever connects to my application will have to do it through my client anyway.
Either way, what am I doing wrong? I'd like to avoid loops in the authentication phase to avoid possible hang ups/slow downs of the application due to unexpected infinite loops since OpenSSL does not specify how many attempts it might take.
The workaround that worked, but that I'd like to avoid, is this:
while ((accept = SSL_accept(conn.ssl)) != 1)
And inside the while loop I check for the return code stored inside accept.
Things I've tried to workaround the SSL_ERROR_WANT_READ error:
Added usleep(50) inside the while loop (still takes several cycles to complete)
Added SSL_do_handshake(conn.ssl) after SSL_connect and SSL_accept (didn't change anything on the end-result)
Had a look at the code shown on roxlu.com (search on Google for "Using OpenSSL with memory BIOs - Roxlu") to guide me through the handshaking phase but since I'm new to this, and I don't directly use BIOs in my code but simply wrap my native C sockets into SSL, it was kind of confusing. I'm also unable to re-write the Networking part of the application as it'd would be too much work for me right now.
I've done some tests with the openssl command-line as well to troubleshoot the issue but it gives no error. The handshake appears to be successful as no errors such as:
24069864:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656
appear. Here's the whole output of the command
openssl s_client -connect IP:Port -tls1_2 -prexit -msg
http://pastebin.com/9u1bfuf4
Things to note:
1. I'm using the latest OpenSSL version 1.0.2h
2. Application runs on a Unix system
3. Using self-signed certificates to encrypt the network traffic
Thanks everyone who's going to help me out.
Edit:
I forgot to mention that the sockets are in non-blocking mode since the application serves multiple clients in one-go. Though, client-side they are in blocking mode.
Edit2:
Leaving this here for future reference: jmarshall.com/stuff/handling-nbio-errors-in-openssl.html
You have clarified that the socket question is non-blocking.
Well, that's your answer. Obviously, when the socket is in a non-blocking mode, the handshake cannot be immediately completed. The handshake involves an exchange of protocol packets between the client and the server, with each one having to wait to receive the response from its peer. This works fine when the socket is in its default blocking mode. The library simply read()s and write()s, which blocks and waits until the message gets succesfully read or written. This obviously can't happen when the socket is in the non-blocking mode. Either the read() or write() immediately succeeds, or fails, if there's nothing to read or if the socket's output buffer is full.
The manual pages for SSL_accept() and SSL-connect() explain the procedure you must implement to execute the SSL handshake when the underlying socket is in a non-blocking mode. Rather than repeating the whole thing here, you should read the manual pages yourself. The capsule summary is to use SSL_get_error() to determine if the handshake actually failed, or if the library wants to read or write to/from the socket; and in that eventuality call poll() or select(), accordingly, then call SSL_accept() and SSL_connect() again.
Any other approach, like sprinkling silly sleep() calls, here and there, will result in an unreliable house of cards, that will fail randomly.
I wrote a class to handle SSL connections that I use to communicate with Paypal.
It worked just fine for about a year and now it fails right away. From the error I get, it would seem that this happens because they (finally) turned off the SSLv3 cipher. Yet, I thought it was turned off on my end already.
There is the error I get when attempting my connection with my code:
139673112286976:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1262:SSL alert number 40
I get the exact same error if I try to connect with -ssl3 using the command line tool:
openssl s_client -connect api.sandbox.paypal.com:443 -ssl3
Note that the command line without the -ssl3 option works as expected.
And I have seen a couple of posts that say that the error means there is a problem with the cipher used, leading me to think that is the problem I'm running into.
For those interested, the whole class is found in our snapcpp git (go up one to get the .h and other files from the snapwebsites library).
There is the relevant code. I removed the error checking happening before the one that triggers the current failure:
std::shared_ptr<SSL_CTX> ssl_ctx(SSL_CTX_new(TLSv1_client_method()), ssl_ctx_deleter);
SSL_CTX_set_verify_depth(ssl_ctx.get(), 4);
SSL_CTX_set_options(ssl_ctx.get(), SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 | SSL_OP_NO_COMPRESSION);
SSL_CTX_set_cipher_list(ssl_ctx.get(), "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4");
SSL_CTX_load_verify_locations(ssl_ctx.get(), NULL, "/etc/ssl/certs");
std::shared_ptr<BIO> bio(BIO_new_ssl_connect(ssl_ctx.get()), bio_deleter);
SSL * ssl(nullptr);
BIO_get_ssl(bio.get(), &ssl);
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);
BIO_set_conn_hostname(bio.get(), const_cast<char *>(addr.c_str()));
BIO_set_conn_int_port(bio.get(), &port);
if(BIO_do_connect(bio.get()) <= 0)
{
ERR_print_errors_fp(stderr);
throw tcp_client_server_initialization_error("failed connecting BIO object to server");
}
So my class throws because the BIO_do_connect() gets the error I mentioned earlier. Yet I would think that these options:
SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1
would be enough to avoid SSLv3.
What else could be the culprit?
You stated SSL_OP_NO_TLSv1 yet you use TLSv1 method.
Try changing TLSv1_client_method() to SSLv23_client_method(). This will alow usage of any method (in fact it will negotiate the highest available SSL/TLS version). You can limit it with SSL_CTX_set_options as you did in your code.
For some reasons the documentation says that SSLv23_method() is deprecated and one should use TLS_method(). Howerer, there isn't such thing in their newest (OpenSSL 1.0.2e) code.
I am trying to load CA certificate from memory instead of file. But I keep getting handshake error while connecting. The file loading works perfectly, memory loading fails. What am I missing?
std::ifstream file("message_server_ca.crt");
std::vector<char> fileContents((std::istreambuf_iterator<char>(file)), std::istreambuf_iterator<char>());
boost::asio::const_buffer buffer(&fileContents.at(0),fileContents.size());
bool useFile = false; // switch between file and memory loading.
boost::asio::ssl::context ctx(io_service, boost::asio::ssl::context::sslv23);
ctx.set_verify_mode(boost::asio::ssl::context::verify_peer);
if(useFile)
{
// This works perfectly!
ctx.load_verify_file("message_server_ca.crt");
}
else
{
// This fails the handshake (asio.ssl:336134278)
ctx.use_certificate(buffer,boost::asio::ssl::context_base::pem);
}
client c(io_service, ctx, iterator);
io_service.run();
It appears that you want add_certificate_authority():
This function is used to add one trusted certification authority from
a memory buffer.
use_certificate() and use_certificate_file() are for the server or client certificate presented in the handshake, i.e. not the CA used to test those certificates.
These functions (load_verify_file() and add_certificate_authority()) are not consistently named. I guess it is because the memory buffer versions were added relatively recently.