HTTPS-эндпоинт прокси

Каждый HTTP-эндпоинт прокси Litport также принимает TLS на том же хосте и порту. Замените схему в URL прокси с http:// на https://, и соединение между вашим клиентом и хабом будет зашифровано. Данные для подключения, порт и целевые сайты остаются прежними. Накладные расходы TLS учитываются как трафик (см. чего это стоит), а неудачное рукопожатие закрывает соединение без X-Proxy-Error-Code для проверки (см. как проверить, что TLS действительно используется).

PORT — это порт HTTP-прокси, указанный для вашего токена в личном кабинете (по умолчанию 1337 и 31337; см. Вход в прокси). У SOCKS5-эндпоинтов нет варианта с TLS.

Выберите уровень безопасности#

К прокси можно обращаться тремя способами. Выберите тот, который соответствует среде, где работает ваш клиент; дальше на этой странице показано, как настроить каждый из них.

Рекомендация: используйте уровень 2. Для него нужны один публичный файл и один параметр, и это единственный уровень, который защищает данные для подключения, по которым можно тратить средства, от обоих видов атакующих. Скачайте корневой сертификат один раз и храните его рядом с кодом:

curl --fail --remote-name https://litport.net/certificates/litport-cache-root.crt

Уровень 1 — разумный шаг вперёд по сравнению с открытым текстом для быстрой ручной проверки или для клиента, которому нельзя передать файл. Уровень 0 используется по умолчанию только потому, что его поддерживает любой клиент; уходите с него везде, где сеть между вами и хабом вам не принадлежит.

Две разные вещи, которые называют «HTTPS-прокси»#

• Проксирование HTTPS-цели — это то, что HTTP-прокси делал всегда: клиент отправляет CONNECT example.com:443, хаб открывает туннель, и ваша TLS-сессия проходит внутри него от клиента до целевого сайта. Эндпоинт прокси http:// это поддерживает; содержимое туннеля для Litport непрозрачно, если только вы не включили режим кеша.
• HTTPS-эндпоинт прокси шифрует участок между вашим клиентом и самим хабом. Всё, что вы отправляете прокси, включая строку CONNECT и ваши данные для подключения, передаётся внутри этой TLS-сессии.

Эта страница — о втором. Они независимы: любую схему можно использовать для любой цели.

Что раскрывает эндпоинт без шифрования (уровень 0)#

При http:// всё, что находится на пути между вашим клиентом и хабом, может прочитать:

«На пути» — это локальная сеть, в которой вы находитесь, ваш провайдер, общая облачная сеть, корпоративный исходящий прокси и любой узел, который логирует трафик. Целевой сайт в обоих случаях видит одно и то же: выбранный выходной IP, но никогда не ваш.

Когда использовать https://#

Используйте HTTPS-эндпоинт, когда:

• Клиент находится в сети, которую вы не контролируете. Ноутбуки в публичном Wi-Fi, общие офисы, сети отелей и аэропортов и любая среда с прозрачным устройством инспекции трафика.
• Клиент работает на общей или сторонней инфраструктуре. CI-раннеры, бессерверные функции, общие облачные VPC и контейнеры на хостах, которыми вы не управляете. Перехват данных для подключения там остаётся тихим и долговременным.
• Сам список адресов назначения конфиденциален. Строки CONNECT показывают, какие хосты вы исследуете, даже когда содержимое зашифровано.
• Вы обращаетесь к целям по обычному http://. Иначе эти тела читаются целиком уже на первом участке.
• Обычный прокси-трафик блокируется или замедляется. Некоторые сети помечают CONNECT на нестандартных портах; TLS к имени хоста выглядит как обычный HTTPS.

Оставайтесь на http://, когда:

• У клиента и хаба уже есть частный зашифрованный путь, например VPN в сеть, которую вы контролируете, и вы хотите минимальных накладных расходов на соединение.
• Клиентская библиотека вообще не умеет согласовывать TLS с прокси (см. заметки по клиентам ниже).
• Вы открываете очень много коротких соединений, и дополнительное рукопожатие на каждое соединение важнее, чем риск раскрытия данных.

Чего это стоит#

• Одно дополнительное TLS-рукопожатие на соединение. Клиенты с keep-alive платят его один раз на соединение, а не на запрос.
• Накладные расходы TLS учитываются как трафик. Обрамление записей и рукопожатие — это байты, проходящие через хаб, поэтому обычные запросы (не в режиме кеша) учитываются чуть больше: обычно на несколько процентов для небольших запросов и пренебрежимо мало для крупных передач. Учёт в режиме кеша не меняется.
• Ваш клиент должен доверять корневому сертификату Litport для соединения с прокси. Этому посвящён следующий раздел, и именно поэтому curl -k не помогает.

Сертификат хаба и почему -k не работает#

Уровень 2 означает проверку сертификата хаба. Хаб предъявляет сертификат для собственного имени хоста (например, hub-eu-1.litport.net), выданный корневым сертификатом кеша Litport. Этого корневого сертификата нет в хранилищах доверенных сертификатов операционных систем, поэтому клиент, который проверяет сертификат прокси по набору по умолчанию, завершается ошибкой:

curl: (60) SSL certificate problem: unable to get local issuer certificate

curl -k это не исправляет. У клиентов два отдельных TLS-участка с отдельными настройками:

-k ослабляет проверку только на участке до целевого сайта. Участок до прокси по-прежнему проверяется по системному набору сертификатов и обрывается. Вместо этого укажите для участка до прокси корневой сертификат Litport:

curl --fail --remote-name https://litport.net/certificates/litport-cache-root.crt
curl --proxy-cacert litport-cache-root.crt \
  -x 'https://USER:[email protected]:PORT' \
  'https://example.com/'

Два момента, которые стоит знать, прежде чем устанавливать этот корневой сертификат шире:

• Доверие к корневому сертификату на участке до прокси не включает режим кеша. Для режима кеша нужен суффикс пароля _cache- в данных для подключения; без него туннель остаётся непрозрачным.
• Тот же корневой сертификат может выпускать сертификаты для перехвата в режиме кеша. Если вы не хотите добавлять его в общесистемное хранилище, ограничьте его областью процесса или контейнера, который использует прокси, как делает каждый пример ниже.

Всегда используйте имя хоста хаба, а не его IP-адрес. Сертификат выдан для имени хоста.

Уровень 2: примеры клиентов с проверкой#

Замените USER, PASSWORD и PORT; зарезервированные символы в данных для подключения кодируйте по правилам percent-encoding. Во всех примерах сертификат прокси проверяется по litport-cache-root.crt, а для целевого сайта сохраняется обычная проверка по публичным CA. Каждый раздел заканчивается переключателем уровня 1, который отключает проверку только на участке до прокси; прежде чем его использовать, прочтите Уровень 1, чтобы узнать, чего это стоит.

curl#

С проверкой (рекомендуется):

curl --proxy-cacert litport-cache-root.crt \
  -x 'https://hub-eu-1.litport.net:PORT' --proxy-user 'USER:PASSWORD' \
  'https://example.com/'

Добавьте --verbose, чтобы увидеть два рукопожатия: первое с прокси (hub-eu-1.litport.net), затем CONNECT внутри него, затем рукопожатие с целевым сайтом.

Без проверки, только для разового теста (данные для подключения по-прежнему зашифрованы, но клиент не отличит настоящий хаб от подставного):

curl --proxy-insecure -x 'https://USER:[email protected]:PORT' 'https://example.com/'

Для --proxy-cacert нужен curl 7.52 или новее; он есть в каждом современном дистрибутиве.

Python Requests#

Requests использует один набор CA для обоих участков, а verify= заменяет набор по умолчанию. Один раз соберите объединённый набор, чтобы для целевого сайта сохранялась проверка по публичным CA:

cat "$(python -c 'import certifi; print(certifi.where())')" litport-cache-root.crt > litport-bundle.pem

import requests

proxy = 'https://USER:[email protected]:PORT'
response = requests.get(
    'https://example.com/',
    proxies={'http': proxy, 'https': proxy},
    verify='litport-bundle.pem',
    timeout=30,
)

Укажите прокси и под ключом http, и под ключом https; Requests выбирает запись по схеме целевого сайта. Для TLS внутри TLS через прокси https:// нужен urllib3 1.26 или новее, от которого зависит Requests 2.26 и новее.

У Requests нет переключателя только для прокси: verify=False отключает проверку обоих участков — хаба и целевого сайта — и выводит предупреждение при каждом запросе. Используйте его только для разовых тестов.

response = requests.get('https://example.com/', proxies={'http': proxy, 'https': proxy}, verify=False, timeout=30)

Python httpx#

httpx разделяет настройки TLS для прокси и для целевого сайта:

import ssl
import httpx

context = ssl.create_default_context()
context.load_verify_locations(cafile='litport-cache-root.crt')
proxy = httpx.Proxy('https://USER:[email protected]:PORT', ssl_context=context)
with httpx.Client(proxy=proxy, timeout=30) as client:
    response = client.get('https://example.com/')

ssl_context у Proxy проверяет только хаб; контекст клиента по умолчанию по-прежнему проверяет целевой сайт. Чтобы пропустить проверку участка до прокси, сохранив проверку целевого сайта, передайте Proxy контекст с отключённой проверкой:

insecure = ssl.create_default_context()
insecure.check_hostname = False
insecure.verify_mode = ssl.CERT_NONE
proxy = httpx.Proxy('https://USER:[email protected]:PORT', ssl_context=insecure)

Node#

https-proxy-agent принимает URL прокси https:// и проверяет хаб по хранилищу доверенных сертификатов Node, поэтому добавьте корневой сертификат через NODE_EXTRA_CA_CERTS. Проверка нигде не отключается.

npm install https-proxy-agent
NODE_EXTRA_CA_CERTS=./litport-cache-root.crt node fetch.mjs

import https from 'node:https'
import { HttpsProxyAgent } from 'https-proxy-agent'

const agent = new HttpsProxyAgent('https://USER:[email protected]:PORT')
https.get('https://example.com/', { agent }, response => response.resume())

В undici (это же движок глобального fetch в Node 18 и новее) у участка до прокси есть собственные параметры TLS, поэтому переменная окружения не нужна:

import { readFileSync } from 'node:fs'
import { ProxyAgent, fetch } from 'undici'

const dispatcher = new ProxyAgent({
  uri: 'https://hub-eu-1.litport.net:PORT',
  token: 'Basic ' + Buffer.from('USER:PASSWORD').toString('base64'),
  proxyTls: { ca: [readFileSync('litport-cache-root.crt')] },
})
const response = await fetch('https://example.com/', { dispatcher })

Обе библиотеки умеют пропускать проверку только на участке до прокси. В https-proxy-agent второй аргумент передаётся в TLS-соединение с хабом; в undici это proxyTls. Проверка целевого сайта остаётся включённой. Не используйте NODE_TLS_REJECT_UNAUTHORIZED=0: он отключает проверку везде в процессе.

const agent = new HttpsProxyAgent('https://USER:[email protected]:PORT', { rejectUnauthorized: false })
const dispatcher = new ProxyAgent({ uri: 'https://hub-eu-1.litport.net:PORT', token, proxyTls: { rejectUnauthorized: false } })

Go#

http.Transport в Go подключается к прокси https:// с тем же TLSClientConfig, который использует для целевых сайтов, поэтому добавьте корневой сертификат в системный пул сертификатов, а не заменяйте его:

pool, err := x509.SystemCertPool()
if err != nil || pool == nil { pool = x509.NewCertPool() }
pem, err := os.ReadFile("litport-cache-root.crt")
if err != nil || !pool.AppendCertsFromPEM(pem) { log.Fatal("could not add Litport root") }
proxyURL, err := url.Parse("https://USER:[email protected]:PORT")
if err != nil { log.Fatal(err) }
client := &http.Client{Transport: &http.Transport{
  Proxy: http.ProxyURL(proxyURL),
  TLSClientConfig: &tls.Config{RootCAs: pool, MinVersion: tls.VersionTLS12},
}}
response, err := client.Get("https://example.com/")

Go применяет TLSClientConfig к обоим участкам, поэтому InsecureSkipVerify: true перестанет проверять и целевой сайт. Переключателя только для прокси нет; вместо этого держите корневой сертификат в пуле.

PHP#

Расширение curl предоставляет те же параметры для участка до прокси, что и командная строка:

$ch = curl_init('https://example.com/');
curl_setopt_array($ch, [
    CURLOPT_PROXY => 'https://hub-eu-1.litport.net:PORT',
    CURLOPT_PROXYUSERPWD => 'USER:PASSWORD',
    CURLOPT_PROXY_CAINFO => __DIR__ . '/litport-cache-root.crt',
    CURLOPT_RETURNTRANSFER => true,
]);
$body = curl_exec($ch);

Чтобы пропустить проверку только на участке до прокси, замените CURLOPT_PROXY_CAINFO на CURLOPT_PROXY_SSL_VERIFYPEER => false и CURLOPT_PROXY_SSL_VERIFYHOST => 0; параметр целевого сайта CURLOPT_SSL_VERIFYPEER остаётся по умолчанию.

Java#

Встроенный в JDK java.net.http.HttpClient поддерживает только прокси без шифрования. Используйте Apache HttpClient 5, который принимает хост прокси по https, и передайте JVM truststore, содержащий корневой сертификат Litport вместе с корневыми сертификатами по умолчанию:

keytool -importcert -noprompt -alias litport-cache -file litport-cache-root.crt \
  -keystore ./litport-truststore.p12 -storetype PKCS12 -storepass changeit
java -Djavax.net.ssl.trustStore=./litport-truststore.p12 \
  -Djavax.net.ssl.trustStoreType=PKCS12 -Djavax.net.ssl.trustStorePassword=changeit App

HttpHost proxy = new HttpHost("https", "hub-eu-1.litport.net", PORT);
BasicCredentialsProvider credentials = new BasicCredentialsProvider();
credentials.setCredentials(new AuthScope(proxy), new UsernamePasswordCredentials("USER", "PASSWORD".toCharArray()));
try (CloseableHttpClient client = HttpClients.custom()
        .setProxy(proxy)
        .setDefaultCredentialsProvider(credentials)
        .build()) {
    client.execute(new HttpGet("https://example.com/"), response -> EntityUtils.toString(response.getEntity()));
}

Отдельный truststore заменяет набор JVM по умолчанию, поэтому импортируйте в него и нужные вам публичные корневые сертификаты либо импортируйте корневой сертификат Litport в копию cacerts из JVM. Переключателя только для прокси в Java нет: TrustManager, который доверяет всем, перестанет проверять и целевые сайты, поэтому используйте truststore.

Браузеры и автоматизация браузеров#

Браузеры проверяют сертификат прокси по хранилищу операционной системы (Firefox — по собственному хранилищу). Установите корневой сертификат туда для профиля, который вы используете, затем укажите браузеру HTTPS-прокси:

• Chrome и Edge: запустите с --proxy-server="https://hub-eu-1.litport.net:PORT" или используйте PAC-файл, возвращающий HTTPS hub-eu-1.litport.net:PORT. Браузер запросит данные для подключения к прокси.
• Firefox: используйте PAC-файл с той же директивой HTTPS host:port или задайте тип прокси HTTPS в настройках соединения.
• Playwright и Puppeteer: передайте server: 'https://hub-eu-1.litport.net:PORT' вместе с логином и паролем. Браузеру по-прежнему нужен корневой сертификат в его хранилище; ignoreHTTPSErrors и --ignore-certificate-errors влияют только на сертификаты целевых сайтов. Браузеры никогда не пропускают проверку сертификата прокси, поэтому установка корневого сертификата — единственный вариант.

Инструкции для хранилища каждой операционной системы и для Firefox есть на странице сертификата.

Клиенты без поддержки TLS до прокси#

Загрузчик Scrapy по умолчанию, HttpClient из JDK и многие старые HTTP-библиотеки могут работать только с прокси без шифрования. Для них оставьте http:// либо запустите небольшой локальный форвардер на 127.0.0.1, который принимает открытый текст и подключается к хабу по TLS; тогда чувствительный участок остаётся на вашей машине.

Уровень 1: шифрование без проверки#

У каждого примера с проверкой выше есть вариант без проверки. Если пропустить проверку, участок остаётся зашифрованным, так что пассивный наблюдатель в сети по-прежнему ничего не видит. При этом пропадает гарантия, что вы общаетесь с хабом Litport: активный атакующий, способный перенаправить ваше соединение, может предъявить любой сертификат и перехватить ваши данные для подключения. Это тот же риск, что у уровня 0 против активного атакующего, поэтому считайте уровень 1 шагом вперёд относительно http://, а не равным уровню 2.

Для всего, что работает без присмотра, предпочитайте уровень 2. Проверка стоит одного файла и одного параметра; защищаемые ею данные для подключения позволяют тратить средства.

Как проверить, что TLS действительно используется#

• curl --verbose выводит рукопожатие с прокси до строки CONNECT, включая субъект сертификата CN=hub-eu-1.litport.net.
• Неверный пароль по https:// по-прежнему возвращает 407 с X-Proxy-Error-Code: 4, точно так же, как по http://; заголовки ошибок передаются внутри TLS.
• Если соединение сразу закрывается без HTTP-ответа, хаб не смог завершить TLS-рукопожатие. Проверьте, что вы использовали имя хоста, а не IP-адрес, что схема https:// указана для HTTP-порта, а не для порта SOCKS5, и что ваш клиент доверяет корневому сертификату Litport на участке до прокси. См. справочник ошибок прокси.

Связанные страницы#

• Токены, прокси-продукты и хабы — о портах и данных для подключения.
• Настройка сертификата кеша — об идентичности корневого сертификата, отпечатках и установке в каждое хранилище.
• Кеш статических ответов — если вы также хотите, чтобы повторные статические ответы отдавались бесплатно.