Компания Google выступила с предложением уменьшить максимальный срок действия серверных сертификатов SSL/TLS с нынешних 825 дней (примерно 27 месяцев) до 397 дней (около 13 месяцев), то есть примерно вдвое.
Google предлагает поставить этот вопрос на голосование в организации CA/Browser Forum (CABF), которая устанавливает требования к SSL/TLS-сертификатам, в том числе к максимальному сроку действия. Если члены CABF проголосуют за это предложение, то изменение будет применяться ко всем новым сертификатам, выданным 1 марта 2020 года или после этой даты.
Кроме того, в сентябре-октябре выйдут новые версии Chrome 77 и Firefox 70, которые лишат EV-сертификаты особого места в адресной строке браузера, как показано на КДПВ.
Зачем сокращать срок действия сертификатов?
Ранее Google заявляла, что стремится сократить максимальный срок действия SSL-сертификатов до целевого показателя в 90 дней. Такое сокращение потребует от владельцев веб-сайтов полной автоматизации выдачи, переоформления и продления сертификатов. Нынешнее сокращение максимального срока — шаг в этом направлении.
Google считает, что только полная автоматизация действий с сертификатами позволит избавиться от нынешних проблем с безопасностью, которые часто объясняются человеческим фактором, например, администраторы забывают продлевать сертификаты.
Полная автоматизация — один из принципов на котором основана работа некоммерческого центра сертификации Let's Encrypt. Он выдаёт бесплатные сертификаты всем желающим, но максимальный срок жизни сертификата ограничен 90 днями. Это сделано специально. Короткие времена жизни сертификатов имеют два главных преимущества:
- ограничение ущерба от компрометированных ключей и неверно выпущенных сертификатов, так как они используются на меньшем промежутке времени;
- короткоживущие сертификаты поддерживают и поощряют автоматизацию, которая абсолютно необходима для простоты использования HTTPS. Если мы собираемся мигрировать всю Всемирную паутину на HTTPS, то вовсе нельзя ожидать ручного обновления сертификатов от администратора каждого существующего сайта. Как только выпуск и обновления сертификатов станет полностью автоматизированным, более короткие времена жизни сертификатов наоборот станут более удобными и практичными.
Google поддерживает такую позицию и даёт понять: даже если голосование CABF не примет предложенные изменения, компания намерена реализовать их де-факто в браузере. Вполне вероятно, что Chrome не будет принимать сертификаты со сроком действия больше 13 месяцев. Ранее компания уже продемонстрировала подобный пример «насаживания» стандартов, внедрив протокол Certificate Transparency.
Если такое произойдёт, то удостоверяющие центры могут продолжать выдачу 825-дневных SSL-сертификатов, которые совместимы со стандартом и будут приниматься во всех браузерах, кроме Chrome.
Наверное, не все владельцы доменов ещё готовы к внедрению 90-дневных сертификатов, поэтому Google действует постепенно. Уменьшение срока действия с 825 до 397 дней — вероятно, только начало.
Вы можете оставить свой голос за или против предлагаемых изменений в опросе по ссылке: https://www.surveymonkey.co.uk/r/SZ56V83
Скрытие EV-сертификатов
Кроме сокращения времени жизни сертификатов, Google вводит ещё одно изменение, которое касается сертификатов EV (Extended Validation). Начиная с версии Chrome 77 в сентябре 2019 года EV-сертификаты лишат дополнительного места в адресной строке браузера для отображения информации о компании. Похожее изменение планируется в десктопной версии Firefox 70, которая выйдет в октябре 2019 года.
Было:
Будет:
Дополнительная информация о владельце сертификата EV будет выводиться по нажатию на пиктограмму с замочком, но не в адресной строке.
Специалисты по дизайну интерфейсов и безопасности (группа Chrome Security UX) пришли к выводу, что «EV UI не обеспечивает защиту пользователей должным образом». Другими словами, пользователи не обращают внимания на информацию из EV-сертификатов. В результате ряд крупнейших сайтов интернета их вообще не используют, включая Google, YouTube, Twitter и Facebook.
Google отмечает, что «значок EV занимает ценное пространство экрана, может показывать поддельные названия компаний в пользовательском интерфейсе и мешает Chrome двигаться к нейтральной, а не положительной индикации защищённых соединений».
По логике специалистов Chrome Security UX, строка с EV-сертификатом — это положительная индикация TLS, в то время как более действенной с точки зрения воздействия на пользователей является нейтральная индикация. Поэтому в перспективе сайты с HTTPS будут лишены пиктограммы «замочка», а для сайтов без HTTPS будет отображаться предупреждение безопасности. Это подтолкнёт все сайты к установке SSL-сертификатов.
По мнению специалиста по безопасности Троя Ханта, удаление информации EV из адресной строки браузеров фактически хоронит данный тип сертификатов.
Комментарии (33)
questor
19.08.2019 12:33В голосовалке нельзя одновременно выбрать и "раз в год" и "каждые 90 дней", в то время как я в разных задачах использую и годичные сертификаты и LE.
questor
19.08.2019 12:35+1Я не могу сказать, что автоматизация LE доведена до какого-то нормального уровня, хотя по сравнению с тем, как всё начиналось при старте LE это конечно же очень удобно.
Однако мне всё равно в ряде задач проще раскатать годичный вайлдкард, чем использовать LE — и в процессе автоматизации именно wildcard до сих пор основная масса неудобств. Они может во многом психологические, но от этого не особо легче.
tmin10
19.08.2019 12:42Автоматизация хороша, когда имеется свой хостинг и возможность всё настроить, но для многих сайтов проще использовать shared хостинг и там уже начинаются проблемы. Только сегодня думал, как автоматизировать получение сeртификатов на таком хостинге с Cpanel, встроенная получалка сертификатов настроена только на какой-то платный сервис.
Думаю взять ACME клиент и через API Сpanel по крону настроить разворачивание новых сертификатов. Но такое сделать каждому не очень просто.balexa
19.08.2019 13:59Если это будет принято — все шаред хостинги очень быстро сделают возможность автоматического получения сертификатов, либо начнут так же быстро терять клиентов. Хотя какое-то время интернет полихорадит, да. Впрочем, крупных сервисов это не коснется.
Squoworode
19.08.2019 12:50Числа 825 и 397 что-нибудь значат? Откуда такие нечеловечески некруглые величины?
gudvinr
19.08.2019 13:04397=366+31
825=366?2+31x3
К сожалению, товарищ Юлий Ц. предложил календарь именно таким, поэтому и приходится пользоваться нечеловеческими единицами измерения, например, годами и месяцами.
DerRotBaron
19.08.2019 13:05+1Выглядит как ещё большая централизация интернета: если нет особого смысла работать не с LE, (почти) все будут работать с LE с образованием нового монополиста
AEP
20.08.2019 16:06Я тоже когда-то так говорил. Потом меня ткнули носом в альтернативу: www.buypass.com/ssl/products/acme
Evengard
22.08.2019 15:55Ждём от них Wildcard-а (они его вроде пока тестируют), и совсем хорошо будет =)
ReklatsMasters
19.08.2019 13:42если голосование CABF не примет предложенные изменения, компания намерена реализовать их де-факто в браузере
Суть современного интернета.
shifttstas
21.08.2019 09:53И это хорошо, альтернативный вариант — 60% пользователей на IE, это намного хуже.
balexa
21.08.2019 16:50Я не уверен, что текущий вариант (90% пользователей на гуглохроме) сильно лучше. Тем более в перспективе.
dmitry_dvm
19.08.2019 14:12+1Индикацию EV зря выпиливают, сейчас сразу видно куда попал (не на фишинг ли), по крайней мере при посещении серьезных контор. А вообще все эти аналитики гуглов живут в какой-то своей отдельной реальности.
goldfine
19.08.2019 15:21А Google молодец, просто так не болтает. Сам себе выдает сертификаты на 85 дней. Текущий сертификат выдан 29.07.2019, действует до 21.10.2019.
VADemon
19.08.2019 15:52Специалисты по дизайну интерфейсов и безопасности (группа Chrome Security UX) пришли к выводу, что «EV UI не обеспечивает защиту пользователей должным образом». Другими словами, пользователи не обращают внимания на информацию из EV-сертификатов.
Это — пять! Сначала пользователей не научили пользоваться адресной строкой (вбивать и переходить по домену), а потом, с выходом Chrome, целеноправленно от этого отучивали (по мотивам цитаты "мама заходит на Яндекс, чтобы вбить в поиск Гугл и только тогда начать поиск"). Какая выгода от перенаправления всего трафика из адресной строки на поисковики — объяснять не надо.
значок EV занимает ценное пространство экрана, может показывать поддельные названия компаний
Так можно доаргументироваться до "корневые сертификаты могут быть украдены, не надо им доверять. Вот, православные сертификаты от Google"
По UX части — Firefox с давнишнего обновления НЕ показывает по одному клику КЕМ был выдан сертификат. То что серт. от Lets Encrypt/Cloudflare (ssl/cdn) парни уже давно используют для фишинга и так понятно. Чтобы посмотреть информацию о сертификате надо сделать 2 щелчка+открывается окно.
Картинка, как сейчас в FF: "Security-based" UX https://cheapsslsecurity.com/blog/wp-content/uploads/2017/07/ssl-certificate-authority-info-in-firefox.png
Реальный случай тоже есть. Фишинговая страница подменяла логин по OpenID на свой. Благо был виден и неправильный адрес в адресной строке и как раз НЕ светилось имя EV-Cert (пользовались бесплатным LE). Не надо никуда лезть — всё видно, если обратить внимание
Абузы отрабатывали как надо — писал, что домен не тот и отправляются данные на какой-то адрес. Блокировали.
EV-name при всём этом просто ещё одна зацепка для пользователя заметить, что что-то не так. Так ли просто зарегистрировать EV с уже существующим или хотя бы похожим именем? В любом случае это очередной барьер, который не каждый фишер пересечёт.
У моей истории выше есть и продолжение. Инструменты разработчика в FF заблокировали скриптом с вечным вызовом брейкпоинта дебаггера (почему-то нельзя игнорировать в FF). Далее парни стали отрисовывать ненастоящее окно браузера прямо у себя на странице, с дизайном окна Windows 10. Там тебе и адрес правильный написан, и иконка зелёная с EV-именем. Очень смешно смотрелось на виртуалке с Ubuntu.
Но итог получился грустный: мальчики-девочки саппорта Google Safebrowing/Cloudflare/регистратора больше не могли отличить эти страницы от настоящих и мои репорты на этот фишинг стали игнорироваться.
Но нет, видно борьба с иконками важнее обучения пользователей.
tmin10
19.08.2019 17:02В FF очень неинформативно сделано. Не понятно, почему сразу не показать информацию пот второму клику, а нужно открывать окошко и уже там открывать сертификат: 4 клика и +2 окошка.
DerRotBaron
19.08.2019 18:23Пару месяцев назад сталкивался с еще одним шедевром UI от Firefox: на сайте с "битым" TLS нельзя было посмотреть информацию о сертификате. Потом вроде это пофиксили.
Scondo
20.08.2019 07:07Что мне действительно не нравится в этой истории: что гугл продавливает фактически своё единоличное решение пользуясь околомонопольным положением на рынке как средством угрозы.
shifttstas
21.08.2019 09:57Ну если они продолжат идти нужной дорогой то почему бы и нет?
Нас ждёт тогда:
- TLS 1.3 по умолчанию и без возможности даунгрейда
- Около 99% на HTTPS
- DNS Over HTTPS
- eSNI
- HTTP /3 (QUIC)
Все изменения прекрасны и очень важны
Scondo
21.08.2019 11:24Эти изменения могут обернуться тёмной стороной, если будут происходить из одного источника в форме навязывания:
1) смерть старых сайтов и\или устройств.
3) статистика о всех твоих посещениях сайтов у гугла
2)… включая видимо твои устройства «умного дома»
5) сейчас Гугл не спешит переходить на утверждённую стандартом версию… что означает возможность любых грязных хаков в пользу их сервисов.shifttstas
21.08.2019 13:261. Это не проблема гугла, сайты и устройства нужно обновлять
2. Никто не мешает использовать сервисы не гугла, как и в случае с DNS Over HTTPS
3. каким образом IOT имеет к этому отношение?
5. Потому, что последняя версия HTTP использует именно гундосый стандарт (не http/2)Scondo
21.08.2019 13:57Ещё раз: мы говорим о том, насколько гугл будет навязывать своё решение.
Если гугл будет навязывать DoH — то у вас будет один захардкоженный сервер, который некоторые продвинутые пользователи возможно смогут поменять на другой… а может и нет.
IoT при внедрении HTTPS как обязательного не сможет управляться из веб-браузера без присвоения имени: выпуск сертификатов на IP крайне ограничен. Вкупе с предыдущим пунктом это приведёт к тому, что гугл узнаёт когда вы подключаетесь к teapot.shiftstas_home.ru
HTTP/3 использует стандарт IETF QUIC который (насколько я знаю) пока не получил сколько-нибудь заметной поддержки. Гугл использует HTTP/2 поверх gQUIC, который отличается от IETF QUIC и служил основой для разработки IETF QUIC. При этом планы Гугла по переходу на HTTP/3 мне пока неизвестны…
Это некие частные случаи на самом деле. И гипотетические, да. Потому что Гугл ещё длительное время может идти преимущественно в нужном направлении.
Тем не менее длительное время в нужном направлении шёл и MS — именно ActiveX в IE родил AJAX как мы его теперь все знаем… а потом IE6 стал символом деградации.
Что я хотел отметить: это надо постоянно иметь ввиду, что мы стоим на таком же пути, как путь к IE6. Может быть какие-то шаги по нему и принесут положительные решения. Но в целом путь опасный.
Loki3000
С автоматизацией пока все плохо. Тот же Let's Encrypt обновляется либо через http (не https!), либо через DNS. Если у сервера 80 порт вообще не предусмотрен, а DNS провайдер не имеет api для работы с DNS записями, то добро пожаловать в ручной режим обновления.
ky0
И что?
Это проблемы Let's Encrypt или всё-таки конкретных веб- и DNS-хостингов?
creker
И в чем проблема? Куплен у меня домен на regru. API есть, но надо самому писать и обновляются записи у них очень медленно. Плюнул и перекинул на cloudflare, для которого, к тому же, готовые плагины у всех есть.
Loggus66
В комментарии речь про reg.ru, мой комментарий не в тему.
creker
Я тоже написал, это то меньшая из проблем, но при отладке обнаружил, что TXT записи очень долго обновляются. Иногда вообще не появляются. Тут уже вопрос использования регру отпал сам собой. Cloudflare же работает моментально, плюс скрипты уже написаны и отлажены.
shifttstas
Покупать домен на regru было уже достаточно странным решением, лучше на Cloudflare сделать трансфер всего домена…