Закрепление SSL и истечение срока действия сертификата

примечание: Я больше знаком с браузером для закрепления сервера (http Public Key Pinning-HPKP), а не с приложением для закрепления сервера, но я предполагаю, что принципал тот же. В HPKP политика закрепления предоставляется сервером в качестве HTTP-заголовка, но поймите, что это часто встроено в приложение, а не читается из HTTP-ответа. Итак, читайте ниже, Ответ Со всем, что в ум:

закрепление обычно против ключа не сертификат и может быть несколько уровней. Итак, у вас есть несколько выбор:

1. Повторно используйте тот же ключ / crt для создания нового сертификата. Некоторые (справедливо на мой взгляд!) рекомендуется генерировать новый ключ каждый раз при обновлении сертификата, но это сложно при использовании pinning. Таким образом, закрепление поощряет плохие привычки безопасности, такие как повторное использование ключей?

2. имейте несколько резервных ключей в вашей политике закрепления и вращайте их вокруг при обновлении сертификата, отбрасывая самый старый и добавляя новый с большим количеством времени и обновлений, чтобы никогда не быть поймал короткое. Лично я предпочитаю генерировать ключ во время обновления сертификата, а не иметь некоторые резервные копии, вокруг которых могут или могли быть скомпрометированы, поэтому я не являюсь особым поклонником этого. И сколько резервных копий у вас должно быть? Например. Если вам нужно переиздать сертификат из-за компромисса вокруг обновления, а также испортить его? Так 2? 3? 100?

3. Pin дальше вверх. Скажем, первый промежуточный или корневой сертификат CA. Таким образом, любому недавно выпущенному сертификату все еще доверяют (при условии, что это обратная сторона этого в четыре раза: i) Вы все еще оставляете себя открытыми для пропущенных сертификатов, выпущенных этим закрепленным сертификатом (не массивная сделка IMHO, поскольку вы все еще массово уменьшили свою поверхность атаки, но все еще беспокоитесь о некоторых людях), ii) вы не можете гарантировать, что клиент будет использовать этот промежуточный сертификат, поскольку иногда существует несколько допустимых путей. Этот второй гораздо важнее. Вы думаете, что предоставление промежуточного сертификата гарантирует, что это будет использоваться, но это не так (множество примеров sha-1 этого). iii) нет никакой гарантии, что новый сертификат будет выдан тем же промежуточным или корневым (особенно, когда технологии меняются, например, введение sha2), поэтому для меня весь этот вариант не является стартовым iv) он связывает вас с использованием того же поставщика сертификатов (возможно, не большое дело, но мне нравится свобода перемещения). Не уверен, что приложения поддерживают эту функцию изначально, но браузеры, безусловно, делают.

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

в конечном счете, поскольку сертификаты требуют обновления,я не большой поклонник закрепления. Я не думаю, что делать что-то, что is при условии периодического обновления, полупостоянный является правильным ответом. И есть даже некоторые разговоры о предварительной загрузке политики закрепления в браузерах, что просто делает меня содрогаться.

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

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

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