Можно ли проверить источник отправителя HTTP-запроса с использованием TLS - PullRequest
Новая
       37

Можно ли проверить источник отправителя HTTP-запроса с использованием TLS

0 голосов
/ 28 октября 2019

Я создал конечную точку API, у меня есть пользователь этой конечной точки, запрашивающий у серверов на stackoverflow.com. Я хочу убедиться, что запрос был сделан с stackoverflow.com серверов. Один из способов убедиться, что он получен из stackoverflow.com, - попросить разработчика подписать запрос с помощью своего зашифрованного закрытого ключа домена. Затем я могу использовать их открытый ключ для расшифровки сообщения.

Я не совсем уверен, что смогу расшифровать зашифрованное сообщение с помощью их открытого ключа, но даже если бы я мог, я бы хотел, чтобы разработчик не делаллюбой специальный тип шифрования. Могу ли я использовать TLS для проверки домена происхождения?

Ответы [ 2 ]

3 голосов
/ 28 октября 2019

TLS поддерживает аутентификацию клиента , также называемую «двухсторонней» или «взаимной» аутентификацией. (SSL3 также сделал, но вы не должны использовать SSL3.) См., Например, TLS1.2 «обновлено» для ECC и TLS1.3 .

Как это использовать, зависит от программного обеспечения (обычно библиотеки или промежуточного программного обеспечения), используемого для TLS, которое вы не указали;даже возможно, что какой-то стек TLS его вообще не поддерживает, хотя я никогда о нем не слышал. Некоторые стеки или варианты использования позволяют вызывать аутентификацию клиента без какого-либо изменения кода, а другие - только с минимальным или локальным изменением кода.

Некоторые подробности, которые могут иметь или не иметь значение:

  • это не подписывает запрос . Он аутентифицирует соединение TLS (если быть точным, обычно подписывает расшифровку рукопожатия), а затем данные, передаваемые по соединению, MAC-адресами (а также шифруются) с использованием ключей, созданных (и, таким образом, аутентифицированных) посредствомрукопожатиеЭто обеспечивает аутентификацию, но не неотказность данных; вы получатель может достоверно определить, что он получен от отправителя, но вы не можете достоверно доказать это третьей стороне. Для тесно связанного случая «проверки» сервера см. Многочисленные перекрестные дубликаты, связанные в https://security.stackexchange.com/questions/205074/is-it-possible-to-save-a-verifiable-log-of-a-tls-session.

  • , это подтверждает, что данные были отправлено идентифицированным клиентом;он ничего не говорит о происхождении , которое, как указывает Сэм Джейсон, часто отличается.

  • клиент не обязательно идентифицируется доменным именем;это может быть человек, организация или что-то еще. Тем не менее, многие ЦС выдают один сертификат для аутентификации сервера TLS и аутентификации клиента (посмотрите расширение ExtendedKeyUsage в вашем собственном или любом примере сертификатов, чтобы увидеть) и в этомВ случае, за некоторыми исключениями, субъект идентифицируется по доменному имени или имени (ам) или по крайней мере по подстановочным знакам (символам).

1 голос
/ 28 октября 2019

Я почти уверен, что вы должны использовать какой-то ключ API или что-то похожее на то, как twilio подписывает свои запросы

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

...