Потрясающая технология ssl pinning. В двух словах - вы зашиваете отпечаток вашего ssl сертификата в ваш клиент (ios, android, whatever). И ваше приложение каждый раз, помимо стандартной проверки сертификата, будет так же проверять, что зашитый отпечаток сертификата совпадает с тем что отдал сервер.

Зачем это нужно? Все это стало достаточно актуально в сфере последних событий, когда крупные центры сертификации лажали и давали выпускать сертификаты даже тем, кому этого сделать нельзя. Или вообще теряли свой приватный ключ. В общем основная идея - сделать так, чтобы при компроментации CA, атака man-in-the-middle была невозможна.

Данная технология очень активно применяется в интернет банкинге, потому что ребята могут потерять много денег, если вдруг кто-то выпишет себе сертификаты на их домены.

А теперь пара слов про HSTS. Эта технология применяется браузерами для сохранения настроек ssl для конкретного сайта, а так же возможности сделать pinning публичного ключа. В общем то же самое что и для не-браузерных приложений, как описано выше.

Для указания срока действия сертификатов и пина публичных ключей используются http хедеры:
1. Strict-Transport-Security
2. Public-Key-Pins

Первый задает политику и время принудительной работы по https, а второй собственно пинит сертификат.

И тут у меня возникает логичный вопрос. Вот раньше, если кто-то ломанул мой сервер и дропнул базу (ну или стащил базу), то восстановить работоспособность и закрыть дыру достаточно плевое дело. Бекапы и вот это вот все. А сейчас? Хакеру достаточно добавить в ответы nginx'а хедеры, указанные выше, max age выставить в 1 год и прописать левые отпечатки сертификатов. И все - се ля ви. Все браузеры, которые словили этот хедер, будут уже не в состоянии зайти на сайт, выкидывая окно с предупреждением. Единственный вариант в данном случае - сбросить hsts сторадж на стороне клиента. А если их у вас 10к? Нехилый такой удар по конкурентам.