• XSS.stack #1 – первый литературный журнал от юзеров форума

Проблема с curl proxy socks5|4/https

sleepknot

HDD-drive
Пользователь
Регистрация
30.01.2022
Сообщения
43
Реакции
18
Всем привет, делаю брут на Си + curl, сделал балванку, подрубил потоки. Все отлично работает, но когда пришло время подрубать прокси для обхода прокси и других блокировок, пошли проблемы.
Во-первых, socks5 отказывается работать, либо работает (что редко бывает) очень медленно. Я подумал что дело socks5, медленные и херовые купил. Купил другие - проблема та же.
Ошибка (Разные бывают, одна из них):
Bash:
*   Trying 72.195.34.60:27391...
* SOCKS5 connect to IPv4 51.195.232.168:443 (locally resolved)
* SOCKS5 request granted.
* Connected to 72.195.34.60 (72.195.34.60) port 27391 (#0)
* found 387 certificates in /etc/ssl/certs
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.3 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile: none CRLfile: none
* Closing connection 0
× curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK
Код:
C:
#include "curl/curl.h"

int main()
{

    const char URL[] = "https://ipcheck.com";
    char curl_fields[256];
    long response_code;

    CURL *curl;
    CURLcode res;

    curl_global_init(CURL_GLOBAL_ALL);
    curl = curl_easy_init();
    if (curl)
    {
        curl_easy_setopt(curl, CURLOPT_URL, URL);

        curl_easy_setopt(curl, CURLOPT_PROXY, "socks5://72.195.34.60:27391");

        curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1L);

        curl_easy_setopt(curl, CURLOPT_USERAGENT, "Mozilla/9.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0");

        curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);

        res = curl_easy_perform(curl);
        if (res != CURLE_OK)
        {
            fprintf(stderr, "× curl_easy_perform() failed: %s\n", curl_easy_strerror(res));
        }
        else
        {
            res = curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response_code);
            if ((res == CURLE_OK) && ((response_code / 100) != 3))
            {
                printf("- %ld\n", response_code);
            }
        }
    }
    curl_easy_cleanup(curl);

    curl_global_cleanup();

    return 0;
}
Я думал сертификат не может найти, или еще чтото с сертификатом, сгенерировал свой (openssl) вставил, но проблема не исчезла. Проверку сертификата тоже убирал.
Во-вторых, скорость. 30 запросов без прокси отправлялись за 3-4 секунды, подрубив прокси один запрос отправлялся +-32 сек. и как я думаю, это зависит всеже от прокси, и я вставил их в firefox.settings.network и у меня хоть и медленно, но всеже запросы в гугл быстро обрабатывались. Тестил уже многое, смотрел примеры на гитхабе - ничего помогло.

C https/socks4 прокси тоже самое, но вот с http чутка лучше по скорости и нет ошибок.

Надеюсь вы мне поможете. Заранее спасибо!
 
Сделай вывод с verbose может станет понятнее где стопорит.
Все что выводит
Bash:
*   Trying 169.57.1.85:8123...
* Connected to 169.57.1.85 (169.57.1.85) port 8123 (#0)
* found 387 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* gnutls_handshake() failed: An unexpected TLS packet was received.
* Closing connection 0
 
* gnutls_handshake() failed: An unexpected TLS packet was received.
Попробуй не чекать тлс "CURLOPT_SSL_VERIFYPEER". видать он пытается проверить то чего нет и из за этого долго думает.
 
Попробуй не чекать тлс "CURLOPT_SSL_VERIFYPEER". видать он пытается проверить то чего нет и из за этого долго думает.
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0);
Вот что получилось:
Bash:
TIME:
real    0m36.412s
user    0m0.059s
sys        0m0.025s

VERBOSE:
*   Trying 192.111.135.18:18301...
* SOCKS5 connect to IPv4 51.195.232.168:443 (locally resolved)
* SOCKS5 request granted.
* Connected to 192.111.135.18 (192.111.135.18) port 18301 (#0)
* found 387 certificates in /etc/ssl/certs
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.3 / ECDHE_RSA_AES_256_GCM_SHA384
*      server certificate verification SKIPPED
*      server certificate status verification SKIPPED
*      common name: www.ipcheck.com (matched)
*      server certificate expiration date OK
*      server certificate activation date OK
*      certificate public key: RSA
*      certificate version: #3
*      subject: CN=www.ipcheck.com
*      start date: Tue, 17 May 2022 04:06:50 GMT
*      expire date: Wed, 17 May 2023 04:06:50 GMT
*      issuer: C=US,ST=Texas,L=Dallas,O=None\, LLC,OU=NA,CN=None,EMAIL=none
* ALPN, server did not agree to a protocol
> GET / HTTP/1.1
Host: ipcheck.com
User-Agent: Mozilla/9.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: */*

* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Date: Wed, 18 May 2022 04:09:19 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
<
* Connection #0 to host 192.111.135.18 left intact
 
Are you sure you're not getting rate-limited? I may have missed something in translation, but did not see mention of if the setup was configured for rotating each request or not.
 
Are you sure you're not getting rate-limited? I may have missed something in translation, but did not see mention of if the setup was configured for rotating each request or not.
Maybe I also translated badly, but I didn't understand about the "rate-limited".
 
It is kind of like front end DoS mitigation that will only process a certain amount of web requests from a host before a limitation

EDIT: If TLS/Cert problem could this problem be solved with a wildcard?
 
It is kind of like front end DoS mitigation that will only process a certain amount of web requests from a host before a limitation

EDIT: If TLS/Cert problem could this problem be solved with a wildcard?
I don't know) I've only been familiar with curl for a week and I haven't worked with certificates before either.
 
I don't know) I've only been familiar with curl for a week and I haven't worked with certificates before either.
In that case I think the most simple solution would be to use a HTTPS reverse rotating proxy on each request
 
На сайте я прочел, что в консольной утилиты curl при работе с https проксями, нужно указывать не https, а протокол http и прокси-сервер будет правильно обрабатывать HTTPS-соединение и поддерживать сквозное шифрование.
Bash:
curl -v --proxy "http://129.159.148.238:3128" "https://ipcheck.com"
На удивление все сработало быстро, и без ошибок. Я пошел в код, и изменил строчку:
C:
curl_easy_setopt(curl, CURLOPT_PROXY, "https://129.159.148.238:3128");
на:
C:
curl_easy_setopt(curl, CURLOPT_PROXY, "http://129.159.148.238:3128");
Но мне выдало ошибку:
Bash:
* * * * Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Server: squid/5.5-EricomShield
< Mime-Version: 1.0
< Date: Thu, 19 May 2022 18:48:30 GMT
< Content-Type: text/html;charset=utf-8
< Content-Length: 1168
< X-Squid-Error: ERR_ICAP_FAILURE 0
< X-Cache: MISS from es-proxy-auth
< Connection: close
< < Set-Cookie: Shield-TenantID=07f68533-0b 62-4796-a210-25e2dddfa658; Max-Age=31536000; Path=/; Http Only


I read on the site that in the curl console utility when working with https proxies, you need to specify not https, but the http protocol and the proxy server will correctly process the HTTPS connection and support end-to-end encryption.
Bash:
curl -v --proxy "http://129.159.148.238:3128" "https://ipcheck.com"
Surprisingly, everything worked quickly, and without errors. I went to the code, and changed the line:
C:
curl_easy_setopt(curl, CURLOPT_PROXY, "https://129.159.148.238:3128");
on:
C:
curl_easy_setopt(curl, CURLOPT_PROXY, "http://129.159.148.238:3128");
But I got an error:
Bash:
* * * * Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Server: squid/5.5-EricomShield
< Mime-Version: 1.0
< Date: Thu, 19 May 2022 18:48:30 GMT
< Content-Type: text/html;charset=utf-8
< Content-Length: 1168
< X-Squid-Error: ERR_ICAP_FAILURE 0
< X-Cache: MISS from es-proxy-auth
< Connection: close
< < Set-Cookie: Shield-TenantID=07f68533-0b 62-4796-a210-25e2dddfa658; Max-Age=31536000; Path=/; Http Only
 
Maybe you will have better results with using proxychains instead of specifying it in cURL
 
Попробуй выставить тип через
Код:
CURLOPT_PROXYTYPE

C:
curl_easy_setopt(curl, CURLOPT_PROXY, "129.159.148.238:3128");
curl_easy_setopt(curl, CURLOPT_PROXYTYPE, CURLPROXY_HTTP);

Все возможные значения тут https://curl.se/libcurl/c/CURLOPT_PROXYTYPE.html
 
Попробуй выставить тип через
Код:
CURLOPT_PROXYTYPE

C:
curl_easy_setopt(curl, CURLOPT_PROXY, "129.159.148.238:3128");
curl_easy_setopt(curl, CURLOPT_PROXYTYPE, CURLPROXY_HTTP);

Все возможные значения тут https://curl.se/libcurl/c/CURLOPT_PROXYTYPE.html
Да я думал об этом, я читал документацию, но как я понял разницы нет. Но всеже попробую.
Я еще попробую на python с либой requests проверить, также подрублю proxy и посмотрю выдает ли ошибки.
 
Я потестил разные способы) И да я еще не решил проблему). Я решил тестить curl в консоли и потому уже перенести в код.

Bash:
#httpS
curl -k --socks5 192.111.135.18:18301 https://httpbin.org/ip
{
  "origin": "192.111.135.18"
}

real    0m26.728s
user    0m0.029s
sys        0m0.005s
#http
curl -k --socks5 192.111.135.18:18301 http://httpbin.org/ip
{
  "origin": "192.111.135.18"
}

real    0m1.336s
user    0m0.000s
sys    0m0.013s
После этого я понял что проблема не в скорости проксей, а именно в TLS, мб сертификат долго ищет и тд...
Но в голову мало что приходит.
 
попробуй отладить коннект утилитой openssl, узнаешь хотя бы на какой стадии tls-хендшейка обрывается. можешь им же дернуть сертификат, на который у тебя curl ругается (саму команду не подскажу, погугли)
команда по идее а-ля
openssl s_client -connect <api.telegram.org:443> -msg (может отличаться, сам давно отлаживал)
ну и насчет proxychains чел выше написал уже, я бы попробовал с ним, если в openssl нет родного ключа для использования прокси
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх