Злоумышленник, зарегистрировавший xyz.azurewebsites.net в Azure, не может провести MitM-атаку с использованием xyz.azurewebsites.net, так как не знает закрытый ключ. Только Azure знает значение закрытого ключа.
Таким образом, это не потому, что кто-то, зарегистрировавший xyz.azurewebsites.net, может перехватить связь между вашим приложением и abc.azurewebsites.net, чтобы он мог обмануть ваше приложение. Но обратите внимание, что это не имеет никакого отношения к закреплению сертификатов с открытым ключом.
Во-первых, давайте поговорим о закреплении открытого ключа сертификата, которым вы не владеете.
В таком случае будьте очень осторожны с тем фактом, что если бы вам приходилось управлять своим сертификатом сервера, вы могли бы повторно использовать один и тот же ключ каждый раз, когда вам приходилось запрашивать у ЦС выдачу нового сертификата для вас. Таким образом, вы можете избежать реализации того, что OWASP называет непрерывностью ключей (см. https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning). НО в вашем случае Microsoft разрешено использовать новый ключ при выпуске нового сертификата. В этом случае ваше приложение перестанет работать, а это не то, что вам нужно. Таким образом, вы должны реализовать непрерывность ключей при закреплении.
Итак, если вы хотели просто реализовать статически закрепленный ключ в своем приложении, я думаю, что это опасно. Microsoft может изменить открытый ключ, когда захочет. Например, если их закрытый ключ украден, они создадут новый сертификат с новым открытым ключом (и отзовут предыдущий сертификат). В таком случае ваше приложение увидит новый ключ, но не должно останавливать запрос.
Теперь давайте поговорим о закреплении открытого ключа с непрерывностью ключа подстановочного сертификата.
1- Во-первых, предположим, что кому-то удалось выпустить настоящий сертификат для *.azurewebsites.net. Поскольку ваше приложение использует закрепление открытого ключа сертификата с подстановочными знаками, ваше приложение увидит, что этот сертификат не содержит правильного открытого ключа. Таким образом, ваше приложение заблокирует запрос.
2- Теперь предположим, что кому-то удалось выпустить настоящий сертификат для xyz.azurewebsites.net. Таким образом, ваше приложение увидит, что сертификат не является ни abc.azurewebsites.net, ни *.azurewebsites.net. Таким образом, ваше приложение остановит запрос.
3- Наконец, предположим, что кому-то удалось выпустить настоящий сертификат для abc.azurewebsites.net. Ваше приложение увидит правильный сертификат для abc.azurewebsites.net. Итак, вам нужно закодировать ошибку в своем приложении, чтобы оно остановило запрос, потому что вы знаете, что Azure не выдает такие сертификаты.
person
Alexandre Fenyo
schedule
01.08.2017
