Удалёнка: опыт и лайфхаки
Реклама
Комментарии 34
+5
С автоматизацией пока все плохо. Тот же Let's Encrypt обновляется либо через http (не https!), либо через DNS. Если у сервера 80 порт вообще не предусмотрен, а DNS провайдер не имеет api для работы с DNS записями, то добро пожаловать в ручной режим обновления.
0
от же Let's Encrypt обновляется либо через http (не https!)

И что?

Если у сервера 80 порт вообще не предусмотрен, а DNS провайдер не имеет api для работы с DNS записями

Это проблемы Let's Encrypt или всё-таки конкретных веб- и DNS-хостингов?
0
а DNS провайдер не имеет api для работы с DNS записями

И в чем проблема? Куплен у меня домен на regru. API есть, но надо самому писать и обновляются записи у них очень медленно. Плюнул и перекинул на cloudflare, для которого, к тому же, готовые плагины у всех есть.
0
Я тоже написал, это то меньшая из проблем, но при отладке обнаружил, что TXT записи очень долго обновляются. Иногда вообще не появляются. Тут уже вопрос использования регру отпал сам собой. Cloudflare же работает моментально, плюс скрипты уже написаны и отлажены.
0
Покупать домен на regru было уже достаточно странным решением, лучше на Cloudflare сделать трансфер всего домена…
-1
> DNS провайдер не имеет api для работы с DNS записями
Вот это самое, что сейчас мне мешает автоматизировать…
+2

Перекиньте на бесплатный cloudflare. Можно даже без проксирования трафика настроить, просто как dns сервер.

0

В голосовалке нельзя одновременно выбрать и "раз в год" и "каждые 90 дней", в то время как я в разных задачах использую и годичные сертификаты и LE.

+1

Я не могу сказать, что автоматизация LE доведена до какого-то нормального уровня, хотя по сравнению с тем, как всё начиналось при старте LE это конечно же очень удобно.


Однако мне всё равно в ряде задач проще раскатать годичный вайлдкард, чем использовать LE — и в процессе автоматизации именно wildcard до сих пор основная масса неудобств. Они может во многом психологические, но от этого не особо легче.

0
Автоматизация хороша, когда имеется свой хостинг и возможность всё настроить, но для многих сайтов проще использовать shared хостинг и там уже начинаются проблемы. Только сегодня думал, как автоматизировать получение сeртификатов на таком хостинге с Cpanel, встроенная получалка сертификатов настроена только на какой-то платный сервис.
Думаю взять ACME клиент и через API Сpanel по крону настроить разворачивание новых сертификатов. Но такое сделать каждому не очень просто.
НЛО прилетело и опубликовало эту надпись здесь
0

Числа 825 и 397 что-нибудь значат? Откуда такие нечеловечески некруглые величины?

0

397=366+31
825=366×2+31x3


К сожалению, товарищ Юлий Ц. предложил календарь именно таким, поэтому и приходится пользоваться нечеловеческими единицами измерения, например, годами и месяцами.

+2

Выглядит как ещё большая централизация интернета: если нет особого смысла работать не с LE, (почти) все будут работать с LE с образованием нового монополиста

0
Ждём от них Wildcard-а (они его вроде пока тестируют), и совсем хорошо будет =)
+1
если голосование CABF не примет предложенные изменения, компания намерена реализовать их де-факто в браузере

Суть современного интернета.

0

И это хорошо, альтернативный вариант — 60% пользователей на IE, это намного хуже.

НЛО прилетело и опубликовало эту надпись здесь
+1
Индикацию EV зря выпиливают, сейчас сразу видно куда попал (не на фишинг ли), по крайней мере при посещении серьезных контор. А вообще все эти аналитики гуглов живут в какой-то своей отдельной реальности.
0

А Google молодец, просто так не болтает. Сам себе выдает сертификаты на 85 дней. Текущий сертификат выдан 29.07.2019, действует до 21.10.2019.

+1
Специалисты по дизайну интерфейсов и безопасности (группа 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/регистратора больше не могли отличить эти страницы от настоящих и мои репорты на этот фишинг стали игнорироваться.


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

0
В FF очень неинформативно сделано. Не понятно, почему сразу не показать информацию пот второму клику, а нужно открывать окошко и уже там открывать сертификат: 4 клика и +2 окошка.
0

Пару месяцев назад сталкивался с еще одним шедевром UI от Firefox: на сайте с "битым" TLS нельзя было посмотреть информацию о сертификате. Потом вроде это пофиксили.

+1
Что мне действительно не нравится в этой истории: что гугл продавливает фактически своё единоличное решение пользуясь околомонопольным положением на рынке как средством угрозы.
-1

Ну если они продолжат идти нужной дорогой то почему бы и нет?


Нас ждёт тогда:


  1. TLS 1.3 по умолчанию и без возможности даунгрейда
  2. Около 99% на HTTPS
  3. DNS Over HTTPS
  4. eSNI
  5. HTTP /3 (QUIC)

Все изменения прекрасны и очень важны

+1
Эти изменения могут обернуться тёмной стороной, если будут происходить из одного источника в форме навязывания:
1) смерть старых сайтов и\или устройств.
3) статистика о всех твоих посещениях сайтов у гугла
2)… включая видимо твои устройства «умного дома»
5) сейчас Гугл не спешит переходить на утверждённую стандартом версию… что означает возможность любых грязных хаков в пользу их сервисов.
-1
1. Это не проблема гугла, сайты и устройства нужно обновлять
2. Никто не мешает использовать сервисы не гугла, как и в случае с DNS Over HTTPS

3. каким образом IOT имеет к этому отношение?
5. Потому, что последняя версия HTTP использует именно гундосый стандарт (не http/2)
0
Ещё раз: мы говорим о том, насколько гугл будет навязывать своё решение.

Если гугл будет навязывать 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. Может быть какие-то шаги по нему и принесут положительные решения. Но в целом путь опасный.
0
Самое идиотское решение от Google — как можно убрать зеленую строку и дать «зеленый свет» фишингу? Ну как???
Только полноправные пользователи могут оставлять комментарии.  , пожалуйста.