Comments 39
от же Let's Encrypt обновляется либо через http (не https!)
И что?
Если у сервера 80 порт вообще не предусмотрен, а DNS провайдер не имеет api для работы с DNS записями
Это проблемы Let's Encrypt или всё-таки конкретных веб- и DNS-хостингов?
а DNS провайдер не имеет api для работы с DNS записями
И в чем проблема? Куплен у меня домен на regru. API есть, но надо самому писать и обновляются записи у них очень медленно. Плюнул и перекинул на cloudflare, для которого, к тому же, готовые плагины у всех есть.
Вот это самое, что сейчас мне мешает автоматизировать…
В голосовалке нельзя одновременно выбрать и "раз в год" и "каждые 90 дней", в то время как я в разных задачах использую и годичные сертификаты и LE.
Я не могу сказать, что автоматизация LE доведена до какого-то нормального уровня, хотя по сравнению с тем, как всё начиналось при старте LE это конечно же очень удобно.
Однако мне всё равно в ряде задач проще раскатать годичный вайлдкард, чем использовать LE — и в процессе автоматизации именно wildcard до сих пор основная масса неудобств. Они может во многом психологические, но от этого не особо легче.
Думаю взять ACME клиент и через API Сpanel по крону настроить разворачивание новых сертификатов. Но такое сделать каждому не очень просто.
Числа 825 и 397 что-нибудь значат? Откуда такие нечеловечески некруглые величины?
Выглядит как ещё большая централизация интернета: если нет особого смысла работать не с LE, (почти) все будут работать с LE с образованием нового монополиста
На текущий момент альтернатива не открывается. И это пока при текущей политической ситуации. а что если все станет намного сложнее?
Сейчас еще есть zerossl.com с китайскими ушами, который в acme.sh даже поставили как default вместо Let's Encrypt. Так что тезис о большой централизации интернета за счет одного пригодного к использованию CA все равно опровергнут.
По поводу блокировки - спасибо за информацию. Меня это не касается, так как я переехал.
"Currently we are not able to issue certificates for this domain (learn more)." Вот такие дела. Так что кроме letsencrypt, выбора из бесплатных нет.
Не все так очевидно: https://stripe.ian.sh/
А Google молодец, просто так не болтает. Сам себе выдает сертификаты на 85 дней. Текущий сертификат выдан 29.07.2019, действует до 21.10.2019.
Специалисты по дизайну интерфейсов и безопасности (группа 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/регистратора больше не могли отличить эти страницы от настоящих и мои репорты на этот фишинг стали игнорироваться.
Но нет, видно борьба с иконками важнее обучения пользователей.
Ну если они продолжат идти нужной дорогой то почему бы и нет?
Нас ждёт тогда:
- TLS 1.3 по умолчанию и без возможности даунгрейда
- Около 99% на HTTPS
- DNS Over HTTPS
- eSNI
- HTTP /3 (QUIC)
Все изменения прекрасны и очень важны
1) смерть старых сайтов и\или устройств.
3) статистика о всех твоих посещениях сайтов у гугла
2)… включая видимо твои устройства «умного дома»
5) сейчас Гугл не спешит переходить на утверждённую стандартом версию… что означает возможность любых грязных хаков в пользу их сервисов.
2. Никто не мешает использовать сервисы не гугла, как и в случае с DNS Over HTTPS
3. каким образом IOT имеет к этому отношение?
5. Потому, что последняя версия HTTP использует именно гундосый стандарт (не http/2)
Если гугл будет навязывать 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. Может быть какие-то шаги по нему и принесут положительные решения. Но в целом путь опасный.
3) да, мне не мешает, у меня вообще свой правильный DNS, свой правильный VPN, свои сервера в Нидерландах и США, но сколько таких как я? Полтора анона?
2) устройство уже может быть куплено и работать, это может быть контроллер у бойлера, например. Надо менять бойлер раз в 3-4 года потому что опять новое шифрование, плохой путь, поэтому у производителей всё без шифрования максимально ибо это геморой для них, который разработчики «железа» не осиливают. Я вот тоже «бойлер» менять не буду — он работает и даёт себя настроить через веб морду по http, всё ^_^'
и для Scondo тоже.
Google предлагает уменьшить срок действия SSL-сертификатов, а сертификаты EV вообще похоронить