«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2019/08/16 18:00:00  №1454677 1
Пытаюсь загрузить файл на telegra.ph/upload через curl, ошибка то Failure when receiving data from the peer, то SSL connect error.
Попробовал на imgur грузить - без проблем, любые страницы (и сам файл) получаю тоже. А на телеграфе проблема. Что делать?
Ответы: >>1454814
Аноним 2019/08/17 01:12:49  №1454814 2
>>1454677

Тебе надо разобраться, в чем может быть проблема. Цепочка тут довольно сложная: твоя программа использует расширение php_curl, а это расширение является прокладкой между php и сишной библиотекой curl (файл libcurl.dll или libcurl.so).

Соответственно, один из способов диагностировать проблему - это попробовать отправить тот же запрос утилитой командной строки curl, которая обычно идет в комплекте с библиотекой curl. У утилиты есть флаг -v, который заставляет ее писать подробности, например, вот команда для выполнения GET запроса:

curl -v https://example.com

Она выводит в том числе подробности установки зашифрованного SSL-соединения, и этап, на котором произошла ошибка.

Если ты используешь Линукс, то утилита curl может быть уже установлена, или ее надо будет установить менеджером пакетов. Если WIndows, то она скорее всего есть в том архиве, в котором была библиотека libcurl.dll.

Также, попробуй открыть https://telegra.ph из браузера - если он не открывается, то возможно, поработал Роскомнадзор, можешь обратиться к ним за решением.

Если сайт открывается в браузере, с большой вероятностью дело в том, что библиотека curl не содержит корневого сертификата для проверки сертификата telegra.ph. Некоторые в таких случаях отключают проверку сертификатов, но гораздо правильнее скачать/установить набор корневых сертификатов и в опциях curl в твоей программе указать путь к ним. В композере, например, есть библиотека https://packagist.org/packages/composer/ca-bundle которая автоматически скачивает набор сертификатов от Мозиллы, а в ридми написано, как ее подключить.

Ты мог бы тут заметить, что в той же Windows уже есть корневые сертификаты, почему curl их не использует? В мануале написано, что для этого нужна сборка curl с поддержкой библиотеки schannel: https://curl.haxx.se/docs/sslcerts.html

Ответы: >>1454989
Аноним 2019/08/17 11:25:18  №1454989 3
>>1454814
>библиотека https://packagist.org/packages/composer/ca-bundle
Установил, подключил, результат тот же.
>Роскомнадзор
Прокси есть.
api.telegra.ph и api.telegram.org открываются. telegram.org/ открывается, telegra.ph/ - SSL ошибка.
>Некоторые в таких случаях отключают проверку сертификатов
CURLOPT_SSL_VERIFYPEER, 0 cтавил - всё равно Failure when receiving data from the peer или SSL connect error. Откуда вообще SSL error, если я отключил проверку? Снова пробовал telegram.org/ и telegra.ph/ открывать - всё так же.
>используешь Линукс
Винда.

Что делать дальше, мастер? Думал на imgur перейти, разобрался с api, а там, оказывается, ограничение на кол-во загрузок.
Ответы: >>1455010 >>1455024
Аноним 2019/08/17 11:52:16  №1455010 4
>>1454989

Нужно проверять утилитой curl. Как ты устанавливал библиотеку curl? Если скачивал какой-то архив, то там наверняка есть утилита curl.exe. Ее надо поместить в одну папку с libcurl.dll и выполнить команду

curl -v https://telegra.ph/

Вот гайд по использованию консоли: https://github.com/codedokode/pasta/blob/master/soft/cli.md

Также, в PHP можно попробовать включить опцию для отладки:

curl_setopt($curlhandle, CURLOPT_VERBOSE, true);

Она пишет данные в поток ошибок (stderr), потому PHP скрипт надо запускать из консоли (командой вроде php myscript.php), а не через веб-сервер. Если запускать из-под веб-сервера, это либо пойдет в лог ошибок, либо неизвестно куда.

Если вдруг она ничего не выведет, то ты можешь попробовать перенаправить отладочную информацию в файл:

$verbose = fopen('c:/tmp/debug.txt', 'w+');
curl_setopt($handle, CURLOPT_STDERR, $verbose);

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

Ответы: >>1455063
Аноним 2019/08/17 12:13:20  №1455024 5
>>1454989

Дополню еще. Если ты никак не можешь найти curl.exe (что плохо), просто скачай архив отсюда https://curl.haxx.se/windows/ , распакуй в отдельную папку, зайди в нее из консоли и запускай curl.exe из нее.

Если ты хочешь заставить курл использовать прокси, добавь опцию -proxy, например:

curl.exe -v -proxy http://1.2.3.4:12345 https://telegra.ph

Если что, полный список опций доступен при выполнении curl --help, или описан тут: https://curl.haxx.se/docs/manpage.html

Возможно, что курл не выведет особых подробностей, а просто напишет что не удалось установить SSL-соединение. Тогда нам нужен инструмент для тестирования SSL соединений, он тебе может пригодиться и в других случаях. Иди сюда https://indy.fulgan.com/SSL/ и скачай там один из архивов, например, openssl-1.0.2s-i386-win32.zip

Раскакуй его в новую папку, зайди в нее из консоли. Далее набери команду тестирования SSL соединения:

openssl.exe s_client -debug -connect telegra.ph:443

Заметь, что openssl просто проверяет установку SSL соединения, он не будет слать HTTP запрос. Если соединение успешно установилось, то набери что-нибудь, например,

GET / HTTP/1.0 (Enter)
Host: telegra.ph (Enter)
(Enter)
(Ctrl + Z, Enter чтобы завершить ввод)

Если что-то непонятно, то скидывай, что выведут эти утилиты. Увы, openssl прокси не использует.
Ответы: >>1455063
Аноним 2019/08/17 13:00:23  №1455063 6
Screenshot9.jpg (117, 816x245)
245x816
Screenshot10.jpg (221, 525x654)
654x525
extension=php_openssl.dll в php.ini включено.
>>1455024
Вот вывод после как я понял авторизации проксей.
И вывод openssl s_client -connect telegra.ph:443 -msg

>>1455010
Тут немного иначе:

successfully set certificate verify locations:
CAfile: D:\------------------\composer\ca-bundle\src/../res/cacert.pem
CApath: none
Unknown SSL protocol error in connection to telegra.ph:443
Curl_http_done: called premature == 1
* Closing connection 0
Ответы: >>1455073
Аноним 2019/08/17 13:35:26  №1455073 7
>>1455063

Скорее всего дело в РКН. Вот как у меня выглядит соединение без VPN:

wine /d/tmp/openssl.exe s_client -debug -connect telegra.ph:443

CONNECTED(00000048)
write to 0x4afff0 [0x4b0778] (307 bytes => 307 (0x133))
0000 - 16 03 01 01 2e 01 00 01-2a 03 03 cc 01 5a f5 0d ........*....Z..
....
read from 0x4afff0 [0x4b5cd8] (7 bytes => 7 (0x7))
0000 - 48 54 54 50 2f 31 2e HTTP/1.
9:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:.\ssl\s23_clnt.c:827:

Видно, что в ответ на HTTPS соединение вместо блока ServerHello приходит кусок HTTP-данных (скорее всего редирект на заглушку), то есть соединение перехватывается.

А с VPN - соединение устанавливается.

У тебя curl успевает отправить один пакет (ClientHello), после чего получает, что соединение было закрыто. Тут может быть несколько причин:

- серверу telegra.ph ты не нравишься и он тебя банит (хотя тогда он бы наверно не давал даже установить соединение)
- прокси прочитал твой пакет ClientHello и решил закрыть соединение
- DPI прочитал пакет ClientHello и решил закрыть соединение

То, что соединение сначала устанавливается и дается возможность отправить ClientHello, указывает на то, что вероятнее всего 2 или 3 вариант. Если банят, то обычно не дают даже соединиться с сервером.

На дампе видны байты 74 65 6C 65. Это коды символов "tele" (таблица http://www.asciitable.com/ ), у тебя в пакете ClientHello указано имя telegra.ph (видимо это поле SNI - Server name indication), и это позволяет блокировать соединение. Надо переходить на TLS1.3 и ESNI, где имя сервера шифруется. Правда, для ESNI нужна поддержка со стороны сервера.

Что касается прокси - если это HTTP-прокси, то в нем обмен идет в открытом виде (примеры есть тут https://stackoverflow.com/questions/7577917/how-does-a-http-proxy-utilize-the-http-protocol-a-proxy-rfc). Клиент посылает к прокси HTTP-запрос вроде CONNECT 1.2.3.4:1234 или даже CONNECT telegra.ph:1234 и DPI может его перехватить, как и пересылаемый через прокси пакет ClientHello.

Ты можешь попробовать соединиться с другим сервером, например, https://example.com, и увидишь, как должен выглядеть трафик при успешном соединении.

Вообще, я тут вспомнил, что есть более удобное средство просмотра трафика - wireshark. Его освоить тоже полезно на случай анализа каких-то сетевых проблем. Он дампит весь трафик с сетевой карты и представляет его в удобном разноцветном виде. Это уже не консольная, а GUI программа. Правда, кроме нужного тебе трафика там будет еще куча мусора от других программ и соседей по локалке.

Отфильтровать лишний трафик можно, указав фильтр, вроде такого ip.addr == 1.2.3.4 (адрес прокси), про фильтры написано тут: https://wiki.wireshark.org/DisplayFilters

Также, DPI может перехватывать твои DNS запросы, когда ты делаешь запрос на разрешение адреса telegra.ph, он может подменять ответ и присылать IP сервера-заглушки (в твоем случае это не происходит, IP правильный).

Если я прав, то Wireshark должен тебе показать, как твоя программа соединяется с прокси, как она щлет запрос CONNECT, и что в ответ присылает DPI. Можешь глянуть, если интересно. Ты можешь так убедиться, что моя версия правильная и проблема не в твоем коде, а в сетевых проблемах.

Ответы: >>1455082
Аноним 2019/08/17 13:58:50  №1455082 8
Screenshot9.jpg (126, 967x230)
230x967
>>1455073
>Скорее всего дело в РКН.
Но почему любые другие заблокированные сайты открываются без проблем? Через эти же прокси. Вот сейчас для теста рутрекер открыл.

>Wireshark
Понятнее не становится.
Попробовал установить curl_setopt($curl, CURLOPT_SSLVERSION, 'CURL_SSLVERSION_TLSv1_3'); - Wireshark всё еще показывает соединение по TLSv1. Открыл опять рутрекер - там уже TLSv1.2. Кажется, ничего не меняется от этой опции.
Ответы: >>1455094 >>1455114
Аноним 2019/08/17 14:38:39  №1455114 9
>>1455082

В Wireshark ты можешь нажать на пакет, и внизу будет выведено его содержимое. У тебя явно видно, что происходит:

- программа устанавливает TCP-соединение с HTTP-прокси (пакеты SYN/ACK)
- программа шлет запрос CONNECT, прося прокси соединиться с сервером, сервер отвечает 200 Ok
- программа шлет пакет ClientHello для установки соединения
- приходит в ответ TCP-пакет ACK (подтверждение), а затем FIN (закрытие соединения)

Следовательно это либо прокси (но странно что он отправил 200 Ok), либо DPI работает. Причем заметь, что для DPI тут нет разницы, используешь ты прокси или нет, так как в любом случае пакет ClientHello шлется одинаковый.

Что касается браузера - браузер и рутрекер могут использовать другие протоколы. Например. может они используют TLS1.3 и ESNI, что позволяет скрыть имя сервера. Или какой-то трюк для обхода блокировки, а telegra.ph не использует это.

TLS1.3 должен поддерживаться с обоих сторон, для ESNI тоже нужна поддержка с обоих сторон.

> А вот через socks5 прокси получается. Какой вывод делать-то?

А ты посмотри трафик. В socks5 по идее нет шифрования.

Тебе нужен либо VPN, либо прокси, к которому ты подключаешься по HTTPS.

Ответы: >>1455130
Аноним 2019/08/17 15:01:12  №1455130 10
Screenshot10.jpg (69, 554x343)
343x554
>>1455114
Но прокси вроде https. Вон, зашифровано же, нет? Я в это разбираюсь еще меньше, чем во всем остальном.
Ответы: >>1455197
Аноним 2019/08/17 16:26:13  №1455197 11
>>1455130

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

Протокол IP - он определяет понятия вроде IP-адресов и передачу пакетов через промежуточные узлы-маршрутизации. В википедии есть формат IP-пакета
В IP пакет мы кладем в качестве нагрузки TCP-пакет. Этот протокол добавляет номера портов для различения приложений, повторную отправку при ошибке и понятие "соединения" с процессом установки и разрыва.

HTTP протокол - работает поверх TCP в открытом виде. HTTPS - это HTTP внутри SSL-канала. То сеть клиент делает TCP-соединение, поверх него устанавливает SSL/TLS соединение (там клиент и сервер обмениваются списком поддерживаемых шифров, генерируют ключи, проверяют сертификаты друг друга и наконец устанавливают зашифрованный канал).

У тебя HTTP-прокси. Ты по протоколу HTTP (в отрытую) соединяешься с прокси, шлешь ему в открытую запрос CONNECT с открытым именем сервера и портом, он устанавливает TCP-соединение с запрошенным сервером и ты шлешь по нему что хочешь (в данном случае - пакеты SSL, внутри которых спрятан HTTP).

Так как прокси использует HTTP, данные передаются в открытом виде и начальный SSL-пакет ClientHello, содержащий имя сервера telegraph, передается в открытую. Так как на этом этапе SSL-канал еще не установлен. На твоем дампе это имя сервера видно.

Тебе надо HTTPS-прокси, то есть прокси, к которому ты подключаешься по HTTPS (SSL), делаешь не видимый снаружи запрос CONNECT, и внутри SSL-канала устанавливаешь второе SSL-соединение к telegraph.