Comments 16
если вы в этом разбираетесь , подскажите как так вышло что все домены .app по умолчанию имеют ssl сертификаты?
No, this doesn’t include an SSL certificate - domains.google/tld/app/
По ссылке человека выше, видим, что домены .app включены в HSTS список, из-за этого SSL требуется.
Но, в комплект не входит.
В аналогичном эксперименте для домашней сети я использовал (что бы упростить жизнь) хашикорп vault
на самом деле тут не помешает рассказать о том какие опции бывают у сертификатов кроме клиентских и серверных.
Как вводная статья очень хорошо
Вот тут есть подробности: ToB:fRSA
Строго говоря, тут пишут что не надо реализовывать RSA руками и использовать левые параметры. Если использовать TLS и OpenSSL последних версий, то всё должно быть ок.
TLS всё это сделает за нас. Просто надо поставить ограничение на минимальную версию.
4096-и битные ключи действительно медленнее чем 2048-и битные и не нужны. Но настолько ли это большая проблема при современном развитии компьютерной техники? По-моему, не очень большая.
CA управляет ключами не только для TLS.
теоретически да. На практике, сертификаты наиболее массово используются именно в www и openvpn. Там TLS. Без TLS сертификаты используются в IKE, всяких EAP и других системах аутентификации. Но если вы не корпоративный сетевой инженер, вероятность столкнуться с этими технологиями исчезающе мала.
4096 ключи - большая проблема, потому, что компьютеры становятся не только больше, но и меньше, и в странных местах
Эти ключи не используются для потокового шифрования. Тот факт что аутентификация соединения занимает не 10 мкс, а 30 из-за использования ключа длиннее, чем надо является проблемой только в очень специфических и редких сценариях.
То есть, всё население сталкивается с этим, вероятно, каждый день
Столкнуться, как разработчик естественно. Разработчик решает какие алгоритмы выравнивания использовать и какая длина ключа.
Не аутентификация, а ещё и выработка ключа. И не 30 микросекунд, а единицы секунд.
Выработка ключа вообще происходит раз в миллион лет. Даже во всех перечисленных вами специальных приложениях
Проверка подписи - это не редкий, а что ни на есть распространённый сценарий
А кто же спорит? Но вы же не станете утверждать, что проверка подписи занимает секунды.
Короче, я не знаю, зачем вы решили поспорить
а вы?
Тот факт что аутентификация соединения занимает не 10 мкс, а 30 из-за использования ключа длиннее, чем надо является проблемой только в очень специфических и редких сценариях.
Для пропуска разница очень заметная, вот значения для Рутокена:
RSA-2048: от 0.21 сек. (NFC), 0.19 сек. (ISO)
RSA-4096: от 1.12 сек. (NFC), 1.08 сек. (ISO)
ECDSA-256 (secp256k1): от 0.14 сек. (NFC), 0.13 сек. (ISO)
ECDSA-256 (secp256r1): от 0.10 сек. (NFC), 0.08 сек. (ISO)
Хотя каких-то 5-10 лет назад поддержки ECC почти нигде не было и даже в библиотеках производительность в разы уступала RSA.
Ещё один важнейший аспект работы с сертификатами — это их отзыв. Для этого используется команда openssl ca -config openssl.conf -revoke <certpath>
Собственно, простота отзыва это одно из самых важных преимуществ PKI над паролями
Опыты с сертификатами — клиентскими и серверными