JWT RS256: безопасно ли получать открытый ключ по протоколу https?

Некоторые понятия часто путаются, возможно, не для вас, но позвольте мне попытаться объяснить некоторые вещи в этом ответе.

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

Но тогда вопрос в том, как вы распространяете свой открытый ключ, или в вашем примере jwt, как клиенты получают его. Как вы правильно указали в вопросе, простая загрузка открытого ключа по небезопасному каналу недостаточно хороша, поскольку злоумышленник может заменить его своим собственным, в результате чего злоумышленник сможет подписывать токены.

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

Введите сертификаты.

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

И Вы тоже должны проверить открытый ключ с сертификатом таким же образом. для этого вам даже не нужно бремя SSL (https) транспорта, проверка того, что открытый ключ принадлежит конкретному субъекту, является основной целью сертификатов.

Таким образом, все, что вам нужно сделать, это не просто получить открытый ключ от API, но получить его вместе с сертификатом. Вы, вероятно, уже делаете это, голый открытые ключи используются очень редко. Скорее всего, вы уже получаете pfx, cer, crt или что-то еще от сервера. В зависимости от технологического стека, который вы разрабатываете, вы можете наверняка использовать встроенные механизмы для полной проверки сертификата и убедиться, что он действителен. Пожалуйста, не внедряйте свою собственную проверку, поскольку это сложный бизнес и довольно трудно получить правильный результат. Если сертификат прошел проверку, вы можете быть уверены, что открытый ключ, полученный от API, является подлинным и принадлежит к тому, к чему он претендует принадлежать. Однако могут быть предостережения (например, убедитесь, что помимо базовой проверки вы проверяете комбинацию полей из сертификата, которую другие не могут иметь).

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

Edit (какие поля проверять в сертификате после того, как он прошел общую проверку истечения срока действия и т. д.):

В общем случае это зависит от того, кто подписал сертификат и какой это сертификат.

Сертификат сервера, подписанный реальным центром сертификации (CA), может иметь только домен сервера в качестве поля общего имени (CN), реальный CA обычно не подписывает ничего другого, и они также не подписывают сертификат для yourdomain.com разве что ты ... может доказать, что вы контролируете yourdomain.com поэтому в этом случае может быть достаточно проверить CN после того, как сертификат прошел валидацию. Вам нужно проверить CN, хотя, поскольку у любого может быть действительный сертификат от say GlobalSign или Thawte или другого доверенного CAs, это просто стоит денег. Чего они не могут иметь, так это сертификата на yourdomain.com.

Если вы подписываете свои собственные сертификаты, вы также не будете подписывать ничего ни для кого, так что в этом случае может быть достаточно проверить эмитента (что вы подписали его) и CN (для кого). Если сертификат в противном случае прошел проверку (имеется в виду доверенный корневой сертификат, подписавший его), он должен быть в порядке, поскольку злоумышленник обычно не сможет иметь свой сертификат CA как доверенный на вашем компьютере.

Суть в том, что вы хотите проверить то, что другие не могут иметь. Это проще, если вы полагаетесь на реальный CAs, и обычно лучше всего проверить отпечаток пальца.