My case is different. I've written an SSL client using boost::asio::ssl
but presently have no server to test against as it's being developed by other group. So the present server only accepts plain TCP (insecure) connections. When i used my ssl client against the server, the blocking handshake()
hangs/never returns. I've searched over the net and got that Mozilla also had similar issues - it hung when initiating SSL connection to a non-ssl supporting server, but their bug stands fixed. I'll just put explanations to parts of my code to make sure there's no coding error:
in ctor
:
SecuredConnectionPolicy<ThreadPolicy>::SecuredConnectionPolicy() :
m_sslContext(boost::asio::ssl::context::sslv23),
m_socket(m_ioService, m_sslContext) //ssl::stream<tcp::socket>
{
}
then when my "connect
(...)" is called:
m_sslContext.set_options(boost::asio::ssl::context::default_workarounds);
m_sslContext.set_verify_mode(
boost::asio::ssl::context::verify_none,
errorCode
);
if(!errorCode)
{
/*m_sslContext.set_verify_callback(
[this](bool bIsPreverificationSuccessful, boost::asio::ssl::verify_context &context){return this->verificationHandler(bIsPreverificationSuccessful, context);},
errorCode
);*/
if(!errorCode)
{
m_sslContext.load_verify_file("newcert.pem", errorCode);
if(!errorCode)
{
m_socket.lowest_layer().connect(remoteEndpoint, errorCode);
if(!errorCode)
{ // ########### Following NEVER RETURNS #############
m_socket.handshake(boost::asio::ssl::stream_base::client, errorCode);
if(errorCode)
{
std::cerr << "Secured Connection Handshake Failed! " << errorCode.message() << std::endl;
}
}
else
{
std::cerr << "Secured Connection Failed! " << errorCode.message() << std::endl;
}
}
else
{
std::cerr << "Secured Connection loading certificate files from default paths Failed! " << errorCode.message() << std::endl;
}
}
else
{
std::cerr << "Registering Verification callback failed! " << errorCode.message() << std::endl;
}
}
else
{
std::cerr << "Secured Connection verify mode Failed! " << errorCode.message() << std::endl;
}
What could be the reason? Am i doing anything wrong?
I'm not providing any verify_callback handler because i am assuming that preverification done by OpenSSL (because everywhere in boost it says it's calling OpenSSL equivalent function) should be enough. Is there any downside to it or could this affect <1>?
This is a trivial one but just to make sure it does not cause problems: Generally examples in boost show that ssl context object has been set before giving it in ctor of
ssl::stream<tcp::socket>
. I however am giving it before (in the ctor above) and later changing properties inconnect()
. Would these be reflected in the behaviour of constructed ssl::stream (because it takes by reference and i hope it does not make any copies)?
On a side note (if it's useful), I created a CA rootKey, CA self-signed PEM certificate, Server certificate signed by CA certificate. CA certificate is what i'm giving to load_verify_file(...)
.