Ставить - да, хотя если не светит доход в виде штрафа за отсутствие самостоятельной фильтрации, то и РКНу уже не так интересно этого "ревизора" держать :)
В законе не сказано, что ТСПУ должны стоять именно в сети оператора связи - сказано, что они должны использоваться для ограничения доступа к информации должны использоваться ТСПУ.
Если ТСПУ поставили в сеть оператора связи, то по дефолту это означается, что трафик в сети этого оператора контролируется ТСПУ и соответствующие подтверждающие (или, как говорят в бухгалтерии - "оправдательные") документы имеются.
Если ТСПУ стоит в другом месте - то оправдательных документов нет. И или надо их родить совместно с аплинками и РКН, или "ой" и надо ограничивать по-старинке.
Если у вас нет ТСПУ, то это не тот случай, о котором я говорю - т.к. я отвечал на утверждение, что "установка тспу никак не отменяет обязанность провайдера самостоятельно блокировать ресурсы". Как раз отменяет.
В вашем же случае убрать свою систему блокировки можно только по согласованию с вашими аплинками и РКН.
Старые - это до принятия поправок в закон "Об информации...", когда вообще по предписаниям прокуратуры блокировали. По нынешним временам - это очень давно.
В данном случае блокировали на основании закона по реестру, и на основании изменений в этот же закон - сняли ответственность (вообще любую, в т.ч. перед абонентами) с провайдеров в случае установки ТСПУ. Но зато наказывается самовольный пропуск трафика мимо ТСПУ.
Но изменение не запретило блокировать собственными силами провайдеров, потому продолжает работать у некоторых провайдеров.
установка тспу никак не отменяет обязанность провайдера самостоятельно блокировать
Отменяет, и обязанность, и ответственность за неблокировку. В закон было внесено соответствующее изменение, и (по нашим временам) - достаточно давно уже.
Но некоторые провайдеры сохраняют существующую систему в дополнение к ТСПУ.
Сильно не согласна. Для меня критерий профессиональности - качественно и со знанием дела решать возникающие передо мной проблемы.
Просто у них определение КПД отличается от вашего.
Будет в нормативном акте написано, что в таких-то случаях надо поступать по-другому - они и будут поступать по-другому.
Потому что вы смотрите с ИТшной точки зрения, а с их точки зрения - это неэффективно, т.к. пока они будут переписываться - подозреваемый может узнать сам факт того, что он подозреваемый, что лишит смысла проводимые ОРМ (включая уже понесённые затраты на них).
Понял, спасибо. Проблема только в реализации POP3, выходит. Майки должны были для него скопировать настройку от IMAP'а, а они, похоже, забыли, и получилась фигня...
Вот тут достаточно хорошо помню, что не выкладывали, максимум "напишите запрос, может быть дадим, но не факт". И относительно недавно, насколько отложилось в памяти, таки переиграли этот момент, наверное, всё-таки добившись разрешения на это.
А вот тут можно пояснить? Вроде была новость некоторое время назад, что с сорсами ядра решили эту проблему. Или какие-то подводные камни всё равно остались?
Исторически - implicit encryption появилось раньше. Можно было через wrapper на другом порту терминировать SSL (тогда еще не TLS) соединение и перебросить в расшифрованном виде в порт "обычного" серверного демона без всякой модификации оного (даже для поддержки тогда еще SSL).
Ну а когда уже в сами серверы всё проинтегрировали - разницы уже нет, STARTTLS explicit encryption нынче стандарт. Да и балансировщики такое тоже обработают - если не терминировать на них TLS, то вообще без разницы, legacy SSL там схема или STARTTLS, а если терминировать - то всё равно уже у приличных балансировщиков есть поддержка соответствующих протоколов на прикладном уровне.
У всех этих людей галочка «Использовать TLS/SSL» была включена
Кстати, Use the following type of encrypted connections - не галочка, а выпадающий список с 4-мя значениями, из которых два - разные виды инициации TLS/SSL.
Так какой там всё-таки способ воспроизведения-то проблемы, что куда выставить в настройках Outlook для этого надо?
Я уже запутался, кто же всё-таки написал фразу "Не могу понять зачем использовать англицизмы, которые итак понятно звучат в виде русских слов."? Т.к. она сразу в двух сообщениях у разных пользователей и не как цитата в обоих.
Начнём с того, что для "обычных" портов у Outlook должна быть не «Использовать TLS/SSL» (который legacy implicit encryption), а "Использовать STARTTLS", который explicit encryption (в аглицком варианте Outlook (classic) настройка называется "Use the following type of encrypted connections"), который нынче актуален (не надо новый порт для существующего протокола придумывать, есть почти для всех протоколов, включая POP3, IMAP, SMTP, FTP... Кроме HTTP) и которые именно и преобразует нешифрованное соединение в шифрованное.
Ну и да, на стороне сервера надо запрещать обмен полезной нагрузкой (включая аутентификацию) до прохождения команды протокола STARTTLS.
Странно, если Dovecot этого не умел до недавнего времени...
Не могу понять зачем использовать англицизмы, которые итак понятно звучат в виде русских слов.
Затем, что с ними проще читать англоязычную документацию и работать с англоязычным интерфейсом - не надо "переводить" в голове, достаточно транслитерировать, это менее "энергозатратно".
А все первоисточники информации - к сожалению, не на русском. И к неменьшему сожалению - источники на русском не поспевают за текущей ситуацией.
Да, ИИ-перевод, которого 30 лет назад еще не было (а что было - с того было смешно, в духе "трудности стрельбы по гидам" вместо troubleshooting guide), может со временем поменять ситуацию. Но если работать приходится с англоязычным интерфейсом - то термины всё равно удобнее транслитерировать, а не переводить - потом проще в интерфейсе опознавать знакомые слова.
А вот кстати заинтересовало: по Kafka есть нормальная литература на русском, чтобы можно было "втянуться" в тему?
Ставить - да, хотя если не светит доход в виде штрафа за отсутствие самостоятельной фильтрации, то и РКНу уже не так интересно этого "ревизора" держать :)
Тут рядом уже подсказали - ФЗ «О связи», п.5.1 ст.46.
Но если ТСПУ не на вашей сети, а у аплинков - то автоматически это не снимает с вас этой обязанности.
В законе не сказано, что ТСПУ должны стоять именно в сети оператора связи - сказано, что они должны использоваться для ограничения доступа к информации должны использоваться ТСПУ.
Если ТСПУ поставили в сеть оператора связи, то по дефолту это означается, что трафик в сети этого оператора контролируется ТСПУ и соответствующие подтверждающие (или, как говорят в бухгалтерии - "оправдательные") документы имеются.
Если ТСПУ стоит в другом месте - то оправдательных документов нет. И или надо их родить совместно с аплинками и РКН, или "ой" и надо ограничивать по-старинке.
Если у вас нет ТСПУ, то это не тот случай, о котором я говорю - т.к. я отвечал на утверждение, что "установка тспу никак не отменяет обязанность провайдера самостоятельно блокировать ресурсы". Как раз отменяет.
В вашем же случае убрать свою систему блокировки можно только по согласованию с вашими аплинками и РКН.
Старые - это до принятия поправок в закон "Об информации...", когда вообще по предписаниям прокуратуры блокировали. По нынешним временам - это очень давно.
В данном случае блокировали на основании закона по реестру, и на основании изменений в этот же закон - сняли ответственность (вообще любую, в т.ч. перед абонентами) с провайдеров в случае установки ТСПУ. Но зато наказывается самовольный пропуск трафика мимо ТСПУ.
Но изменение не запретило блокировать собственными силами провайдеров, потому продолжает работать у некоторых провайдеров.
Отменяет, и обязанность, и ответственность за неблокировку. В закон было внесено соответствующее изменение, и (по нашим временам) - достаточно давно уже.
Но некоторые провайдеры сохраняют существующую систему в дополнение к ТСПУ.
Просто у них определение КПД отличается от вашего.
Будет в нормативном акте написано, что в таких-то случаях надо поступать по-другому - они и будут поступать по-другому.
Потому что вы смотрите с ИТшной точки зрения, а с их точки зрения - это неэффективно, т.к. пока они будут переписываться - подозреваемый может узнать сам факт того, что он подозреваемый, что лишит смысла проводимые ОРМ (включая уже понесённые затраты на них).
Понял, спасибо. Проблема только в реализации POP3, выходит. Майки должны были для него скопировать настройку от IMAP'а, а они, похоже, забыли, и получилась фигня...
Есть галочка "использовать шифрованную проверку пароля", а есть список значений для "использовать шифрование соединения" с типами шифрования.
И вот ЧТО они там настраивали в оригинале - непонятно.
Хм... С этими тётеньками стране имеет место некоторая проблема - персонал куда-то с почты разбежался, говорят, платят мало...
Вот тут достаточно хорошо помню, что не выкладывали, максимум "напишите запрос, может быть дадим, но не факт". И относительно недавно, насколько отложилось в памяти, таки переиграли этот момент, наверное, всё-таки добившись разрешения на это.
Ага, в 2024г https://habr.com/ru/news/826490/
+
Понятно.
Хотя тут https://git.openelbrus.ru/mcst/osl?filter=webkit пара webkit'ов находится вроде...
А вот тут можно пояснить? Вроде была новость некоторое время назад, что с сорсами ядра решили эту проблему. Или какие-то подводные камни всё равно остались?
Исторически - implicit encryption появилось раньше. Можно было через wrapper на другом порту терминировать SSL (тогда еще не TLS) соединение и перебросить в расшифрованном виде в порт "обычного" серверного демона без всякой модификации оного (даже для поддержки тогда еще SSL).
Ну а когда уже в сами серверы всё проинтегрировали - разницы уже нет, STARTTLS explicit encryption нынче стандарт. Да и балансировщики такое тоже обработают - если не терминировать на них TLS, то вообще без разницы, legacy SSL там схема или STARTTLS, а если терминировать - то всё равно уже у приличных балансировщиков есть поддержка соответствующих протоколов на прикладном уровне.
ну по крайней мере можно не гадать, кто в карму минусил... а мог бы и на вопрос ответить вместо этого.
Кстати, Use the following type of encrypted connections - не галочка, а выпадающий список с 4-мя значениями, из которых два - разные виды инициации TLS/SSL.
Так какой там всё-таки способ воспроизведения-то проблемы, что куда выставить в настройках Outlook для этого надо?
Очень сбивает с толку, знаете ли )
Ваше сообщение раньше, и потому у Оборотня-Волка всё выглядит так, что он цитировал вас, но первый абзац "выскочил" из-под цитирования.
Выходит, что всё-таки первоначально-то я правильно ответил...
Я уже запутался, кто же всё-таки написал фразу "Не могу понять зачем использовать англицизмы, которые итак понятно звучат в виде русских слов."? Т.к. она сразу в двух сообщениях у разных пользователей и не как цитата в обоих.
Причём неправильную пользовательскую настройку - для 110 порта там должно быть значение STARTTLS, а не TSL/SSL.
Возможно, не замечали баг еще и потому, что кто мог заметить - ставили в Outlook правильную настройку...
Начнём с того, что для "обычных" портов у Outlook должна быть не «Использовать TLS/SSL» (который legacy implicit encryption), а "Использовать STARTTLS", который explicit encryption (в аглицком варианте Outlook (classic) настройка называется "Use the following type of encrypted connections"), который нынче актуален (не надо новый порт для существующего протокола придумывать, есть почти для всех протоколов, включая POP3, IMAP, SMTP, FTP... Кроме HTTP) и которые именно и преобразует нешифрованное соединение в шифрованное.
Ну и да, на стороне сервера надо запрещать обмен полезной нагрузкой (включая аутентификацию) до прохождения команды протокола STARTTLS.
Странно, если Dovecot этого не умел до недавнего времени...
Затем, что с ними проще читать англоязычную документацию и работать с англоязычным интерфейсом - не надо "переводить" в голове, достаточно транслитерировать, это менее "энергозатратно".
А все первоисточники информации - к сожалению, не на русском. И к неменьшему сожалению - источники на русском не поспевают за текущей ситуацией.
Да, ИИ-перевод, которого 30 лет назад еще не было (а что было - с того было смешно, в духе "трудности стрельбы по гидам" вместо troubleshooting guide), может со временем поменять ситуацию. Но если работать приходится с англоязычным интерфейсом - то термины всё равно удобнее транслитерировать, а не переводить - потом проще в интерфейсе опознавать знакомые слова.
А вот кстати заинтересовало: по Kafka есть нормальная литература на русском, чтобы можно было "втянуться" в тему?