SLL/TLS клиент и сервер наобарот

SSL_set_connect_state, SSL_set_accept_state у соответствующих сторон не?

Спасибо. Пока правда них не понятно, но есть направление.

То есть как в OpenSSL выполнить хендшейк наоборот

Это не хендшейк наоборот, это расширенный хендшейк. И серверный сертификат по прежнему нужен (ну в 99.9 % случаях).

Я даже не знаю как такое загуглить.

SSL/OpenSSL client authentication.

И серверный сертификат по прежнему нужен (ну в 99.9 % случаях).

м? Сертификат ты имеешь в виду тот самый? приватный который? Вот как раз в моем случае его нет и не должно быть. Клиент (который открыл сервер) получает только 1 публичный сертификат, которым потом верифицирует того, кто к нему подцепился.

то есть вот при нормальной работе клиент начинает диалог, а мне нужно, чтоб его начал сервер.

SSL/OpenSSL client authentication.

нашел разборки на SO по теме. тоже почитаю, спасибо.

Сертификат ты имеешь в виду тот самый? приватный который?

Я имею ввиду, что клиент по-прежнему должен производить аутентификацию сервера, т.е. у сервера должен быть свой приватный ключ и сертификат, а на клиенте должен быть установлен соответствующий корневой сертификат. Иначе любой может вклинится посередине и притвориться сервером.

то есть вот при нормальной работе клиент начинает диалог, а мне нужно, чтоб его начал сервер

SSL так не работает - диалог начинает клиент и аутентификация клиента это необязательная часть хендшейка.

SSL так не работает

сдается мне, что ТС говорит о том, что у него сервер TCP должен исполнять роль клиента SSL и наоборот. то есть сам механизм SSL запускается ж после того, как TCP закончил свой хендшейк. И с чегоб вдруг SSL не смог бы сделать хендшейк в обратную сторону?

Я вообще делал, чтоб по 1 соединению, могло идти несколько SSL сеансов (хендшейкался через BIO_s_mem). Но там свой протокол был, да.

а TC: почитай

Network Security with OpenSSL
By Pravir Chandra, Matt Messier, John Viega

хоть и старенькая, но годная. Хотя может кто актуальнее что назовет?

сдается мне, что ТС говорит о том, что у него сервер TCP должен исполнять роль клиента SSL и наоборот. то есть сам механизм SSL запускается ж после того, как TCP закончил свой хендшейк

Сдается мне, что этот вариант очень странный и не решает проблемы подмены сервера.

И с чегоб вдруг SSL не смог бы сделать хендшейк в обратную сторону?

Если самому чтением/записью через сокет рулить, то можно. Но это не так же удобно, как если бы OpenSSL это сделал за тебя. И, опять же, очень странно.

Спасибо, парни. Инфу кой-какую нарыл, пока разбираюсь.

И, опять же, очень странно.

У меня своя песочница. Проектик небольшой просто для интереса.