Ability to react to SSL handshake errors

[trueqbit]

I have recently discovered "RFC 2817 - Upgrading to TLS within HTTP/1.1".

While this idea is unimplemented by today's browsers, I'd still like to see basic support for a virtual ssl handshake error handler:

1. Not all tcp/http clients might be browsers
2. Possibility for friendlier and human-readable HTTP response in case of unencrypted http requests (http protocol)

Such a handler for a human-readable response would look like (note the check for SSL_R_HTTP_REQUEST originating from the ssl library):

void handle_ssl_handshake_error(const tcp::connection_ptr& tcp_conn,
                                const boost::system::error_code& handshake_error)
{
    tcp_conn->set_lifecycle(tcp::connection::LIFECYCLE_CLOSE);

    if (ERR_GET_LIB(handshake_error.value()) == ERR_LIB_SSL &&
        ERR_GET_REASON(handshake_error.value()) == SSL_R_HTTP_REQUEST)
    {
        http::response msg;
        msg.set_status_code(426);
        msg.set_status_message("Upgrade Required");
        msg.add_header("Connection", "Upgrade, close");
        msg.add_header("Upgrade", "TLS/1.2, HTTP/1.1");
        msg.set_content_type(http::types::CONTENT_TYPE_TEXT_UTF8);
        msg.set_content("Please connect using HTTPS.");

        // special send method:
        // 1) reset Connection header, which has been modified by message::prepare_buffers_for_send()
        // 2) directly write to unsecured socket - tcp::connection would check for its ssl flag
        {
            http::message::write_buffers_t buffers;
            msg.prepare_buffers_for_send(buffers, tcp_conn->get_keep_alive(), false);
            msg.change_header("Connection", "Upgrade, close");

            buffers.push_back(boost::asio::buffer(msg.get_content(), msg.get_content_length()));
            boost::system::error_code ec;
            boost::asio::write(tcp_conn->get_socket(), buffers, boost::asio::transfer_all(), ec);
        }
    }

    tcp_conn->finish();
}

[rimmartin]

Hi @trueqbit, I'm wanting to revive the master branch as the main one hopefully it won't effect the current PR's. The master is now eq to develop

[trueqbit]

Ok... Can we handle it this way this time: If you are taking look at the two PRs (#8, #6) and agree to incorporate them, can you merge them into develop? This way I don't have to redo the PRs.

[rimmartin]

I got #6. For #8 I resolved the conflict; you may need to pull it to your issues/#7 ?

[rimmartin]

The splunk people removed a private key Jan 30. I made a pull request from it at https://github.com/rimmartin/pion-ng/pull/10

Do we want it?

[rimmartin]

I still couldn't get an old windows dev box working; I'll try again

[trueqbit]

I got #6. For #8 I resolved the conflict; you may need to pull it to your issues/#7 ?

Looks like you tried and committed code from PR #8 with commit f408703a3676... So I'm gonna merge and close my PR, then.