openssl принимать подключение использовать мой буфер

Question

В обычном режиме: браузер отправить в мой прокси: «CONNECT ... \ r \ n \ r \ n», прокси отправить «200 OK \ r \ n \ r \ n», отправить браузер зашифрованный запрос, прокси-вызов SSL_accept (сокет). ОК.

Проблема: браузер отправит на мой прокси-сервер: «CONNECT ... \ r \ n \ r \ n» + следующий зашифрованный запрос. Прокси отправит «200 OK \ r \ n \ r \ n», вызовет SSL_accept (socket), возвращенный SSL_ERROR_SSL или SSL_ERROR_SYSCALL, потому что прокси-сервер читает в буферной части зашифрованного запроса.

Решение:

1. Использование RECV (носок, ЬиЙ, buffer_size, MSG_PEEK) и RECV (носок, ЬиЙ, used_size, 0). Проблема: все данные будут считаны или бесконечный сигнал в пуле().

2. Как позвонить SSL_accept() использовать мой буфер с частью зашифрованных данных?

3. Любые решения?

Answer 1

Проблема с вашим прокси-сервером, а не с клиентом.

Согласно разделу 3.3 CONNECT specification:

3.3. Данные Конвейеризация

Допустимо, что клиент отправил некоторые данные, предназначенные для сервера, до получения «Установленного соединения 200» (или любого другого кода успеха или ошибки). Это позволяет уменьшить латентность и повысить эффективность, если любые данные рукопожатия, предназначенные для удаленного сервера, могут быть отправлены в том же пакете TCP, что и запрос прокси. Это позволяет прокси-серверу немедленно перенаправлять данные после установления соединения с удаленным сервером, не дожидаясь двух раз в два раза для клиента (отправка 200 на клиент, ожидающая следующего пакета от клиента).

Это означает, что прокси-сервер не может считать, что чтение из дескриптора сокета клиента приведет только к возврату запроса прокси.) Скорее, может быть любое количество непрозрачных данных после запроса прокси-сервера, который должен быть перенаправлен на сервер после установления соединения. Однако, если соединение с удаленным сервером выходит из строя или если он запрещен прокси-сервером, данные, предназначенные для удаленного сервера, будут отброшены прокси-сервером.

Реальная ошибка состоит в том, что ваш HTTP прокси не называть SSL_accept(), чтобы начать с, так как это не цель TLS рукопожатие клиента. Запрошенный сервер является целью, и, следовательно, только он может правильно ответить на рукопожатие. Ваш прокси не должен отвечать на рукопожатие. Вероятно, это приведет к сбою на стороне клиента (особенно если клиент правильно выполняет свою работу, чтобы проверить ответ не от человека в середине).

Ваш прокси должен установить нормальный незашифрованном подключение к запрашиваемому серверу, а затем передавать любые исходные данные как есть назад и вперед. Ваш прокси-сервер не является участником сеанса шифрования клиент/сервер, это просто сквозной способ облегчения обмена данными между клиентом и сервером, не более того.

Do not Попытка интерпретировать данные клиента или сервера каким-либо образом, это не ваши данные для обработки. Все после первоначального запроса CONNECT составляет opaque прокси и должен быть перенаправлен как есть. Вы не знаете, как и не можете делать какие-либо предположения о том, как клиент и сервер общаются друг с другом.