HTTPS с использованием клиента TLS / SSL не работает

Согласно RFC 2818, раздел 2: http://www.ietf.org/rfc/rfc2818.txt

«Концептуально HTTP / TLS очень прост. Просто используйте HTTP через TLS точно так же, как если бы вы использовали HTTP через TCP».

У меня есть приложение, которое подключается к веб-серверу через порт 443 с помощью клиента TLS / SSL. После подключения клиент TLS отправляет заголовок HTTP и связанные с ним полезные данные HTTP (все они содержатся в виде полезных данных приложения для клиента TLS / SSL).

POST https://www.somehost.com/pubs/m_login HTTP / 1.0
Контент -Тип: application / x-www-form-urlencoded
Хост: www.somehost.com
Пользовательский агент: NativeHost
Длина содержимого: 50

имя пользователя = пользователь% 40example.com и пароль = пароль

Я получаю ответ 200 от сервера, указывающий, что он получил мой запрос. Однако тело ответа HTTP содержит фактический ответ серверного приложения, и это указывает на сбой.

HTTP / 1.1 200 OK
Дата: Вт, 18 марта 2014 г., 02:47:43 GMT
Сервер: Apache / 2.2.24 (FreeBSD) mod_fastcgi / 2.4.6 mod_ssl / 2.2.24 OpenSSL / 0.9.8e DAV / 2 mod_perl / 2.0.8 Perl / v5.12.5
Cache-Control: no-cache, max-age = 0
Pragma: no-cache0
Content-Length: 118
Set-Cookie : bcdb_session = cd12abe27a5c55e3a076763329cc0cd31e246751; путь = /; expires = Вт, 1 апреля 2014 г., 02:47:43 GMT; HttpOnly
Варианты: Accept-Encoding
Соединение: закрыть
Content-Type: text / xml; charset = UTF-8

‹? Xml version =" 1.0 "encoding =" UTF-8 "?›
‹appname›
‹error› not_logged_in ‹/error›
‹status› error ‹/status›
‹/ Название приложения>

Когда я использую клиент, поддерживающий HTTPS, и отправляю заголовки и тело запроса на отправку, я получаю успешный ответ (и ответ http 200, и тело ответа указывают на успех).

HTTP / 1.1 200 OK
Дата: Вт, 18 марта 2014 г., 03:04:22 GMT
Сервер: Apache / 2.2.24 (FreeBSD) mod_fastcgi / 2.4.6 mod_ssl / 2.2.24 OpenSSL / 0.9.8e DAV / 2 mod_perl / 2.0.8 Perl / v5.12.5
Cache-Control: no-cache, max-age = 0
Pragma: no-cache0
Content-Length: 84
Set-Cookie : bcdb_session = 9c0e22a54d7fc28dbd19b748c287d1b25166d78c; путь = /; expires = Вт, 1 апреля 2014 г., 03:04:22 GMT; HttpOnly
Варианты: Accept-Encoding
Соединение: закрыть
Content-Type: text / xml; charset = UTF-8

‹? Xml version =" 1.0 "encoding =" UTF-8 "?›
‹appname›
‹status› ok ‹/status›
‹/appname›

Я попытался захватить сетевые данные для двух сценариев и сравнить их. Я могу захватить клиент HTTPS, поскольку он поддерживает HTTP-прокси (и я использую Fiddler). Клиент SSL / TLS не может использовать прокси-сервер HTTP, но поддерживает прокси-сервер SOCKS.

Два вопроса:

1) Любая идея, почему при использовании клиента HTTPS может быть другой результат по сравнению с клиентом TLS / SSL?

2) Может ли кто-нибудь порекомендовать использовать прокси-сервер SOCKS, который будет обеспечивать такой же доступ к данным запроса / ответа, как и Fiddler?

Спасибо Майк


ssl proxy https socks
person Mike G    schedule 17.03.2014    source источник
comment
Пожалуйста, покажите актуальные запросы и ответы. Что на самом деле говорит неудача? Некоторые серверы действительно отправляют сообщения об ошибках, используя коды успешного ответа, такие как 2xx, вместо более подходящего кода ответа 4xx / 5xx. Тот факт, что вы вообще получаете действительный HTTP-ответ, означает, что часть TLS работает правильно.   -  person Remy Lebeau    schedule 18.03.2014
comment
За одним IP-адресом может быть несколько серверов HTTPS. Один клиент может использовать SNI (указание имени сервера), чтобы указать требуемое имя хоста и, таким образом, получить свой сертификат и данные сервера. Но если ваш клиент подключается без SNI, он, вероятно, получит другой сертификат (не обязательно) и будет подключен к другому виртуальному серверу.   -  person Steffen Ullrich    schedule 18.03.2014
comment
Спасибо, что посмотрели на мою проблему. Я обновил исходное сообщение, включив в него запрос и рабочий ответ, который я получаю при использовании клиента HTTPS, и ответ об ошибке при использовании клиента TLS.   -  person Mike G    schedule 18.03.2014
comment
Решение этой проблемы состояло в том, чтобы оставить схему протокола и имя хоста из команды POST и просто включить относительную часть URL-адреса.   -  person Mike G    schedule 18.03.2014

Ответы (1)


arrow_upward
0
arrow_downward

Вы уверены, что запрос одинаков в обоих случаях? Например. первая строка неверна для действительного HTTP-запроса. Если вы подключаетесь напрямую, строка запроса должна быть POST /pubs/m_login HTTP/1.0, а НЕ POST https://www.somehost.com/pubs/m_login HTTP/1.0.

К сожалению, сервер SOCKS не поможет вам сбросить запрос, потому что TLS-соединение защищено от этого. Сервер SOCKS предлагает непрозрачный туннель.

person Eugene Mayevski 'Callback    schedule 18.03.2014