gladilov.org.ru gladilov.org.ua

49 заметок с тегом

сеть

DMCA теперь разрешает перепрошивку роутеров

Правозащитные организации Software Freedom Conservancy (SFC) и Electronic Frontier Foundation (EFF) добились внесения поправок в «Закон об авторском праве в цифровую эпоху» (DMCA, Digital Millennium Copyright Act), добавляющих прошивки к маршрутизаторам в список исключений, на которые не распространяются ограничения DMCA.

Раз в три года в Библиотеке Конгресса США созывается специальная комиссия, которая в ходе публичных слушаний принимает решение о пересмотре списка исключений с описанием ситуаций к которым закон DMCA не может быть применим. Данный список формируется для защиты от возможных злоупотреблений и необоснованных ограничений, которые могут продвигаться под прикрытием DMCA, не являясь при этом объектом нарушения авторских прав.

Показать

Утверждённые в этом году исключения разрешают установку альтернативных прошивок на маршрутизаторы и другие сетевые устройства (в том числе совершая jailbreak и обходя привязки к прошивкам с DRM). Исключение даёт пользователю возможность продлить жизненный цикл своего устройства после истечения срока поддержки производителем, установив альтернативную прошивку, такую как OpenWrt.

Также одобрены исключения, позволяющие легально проводить исследования прошивок устройств с целью выявления и подтверждения возможного нарушения копилефт-лицензий, требующих открытия производных работ. Исключение действует для всех типов устройств, кроме игровых консолей.

Ранее действующие исключения, связанные с разрешением разблокирования, смены прошивки, ремонта и установки приложений, независимо от того одобрены они производителем или нет, ранее действующие для смартфонов (jailbreak), планшетов и прочих мобильных устройств, расширены в отношении возможности замены программной начинки умных телевизоров.

Расширены категории устройств для которых действуют исключения, позволяющие самостоятельно проводить ремонт. Проект Right to Repair добивается предоставления исключений для ремонта любых устройств и в этом году удалось приблизится к намеченной цели. Одобрены поправки, разрешающие диагностику, техническое обслуживание и ремонт любых потребительских устройств, включая электронные книги, проигрыватели дисков и умные динамики, а также ремонт транспортных средств, морских судов и медицинских устройств. Для медицинских устройств разрешён как ремонт так и извлечение данных, хранящихся на собственном устройстве, независимо от того имплантировано устройство или нет.

Продлены исключения, связанные дешифровкой материалов c DVD, Blu-Ray и online-сервисов, которые используются для составления ремиксов с включением в них отдельных отрывков видео. Из действия DMCA также выведены компьютерные игры и игровые консоли, производители которых прекратили поддержку своих продуктов (любители компьютерных игр могут легально вносить изменения в старые игровые приложения и прошивки игровых консолей для обхода привязок к внешним игровым сервисам и серверам аутентификации). Продлены исключения, позволяющие использовать альтернативные материалы в 3D-принтерах.

Не был удовлетворён запрос на включение исследований соблюдения конфиденциальности в продлённое исключение, разрешающее исследователям безопасности анализировать программные продукты с целью выявления уязвимостей и самостоятельно исправлять найденные уязвимости. Комиссия заключила, что в подобном изменении нет необходимости, так как исследования конфиденциальности подпадают под определение исследований безопасности и принятия отдельного исключения для них не требуется.

Не одобрены были и поправки, допускающие ремонт игровых консолей (ремонт игровых консолей ограничен возможностью самостоятельной замены оптических накопителей) и устройств с прошивками, применяемыми в коммерческих или промышленных целях за исключением транспортных средств и медицинских устройств. Например самостоятельный ремонт и изменение настроек робота-пылесоса считается нелегальным.

Из нерешённых проблем также отмечается отсутствие исключений для распространения инструментов, используемых для ремонта — поставка утилит, обходящих блокировки производителей по-прежнему считается нелегальной. Отмечается, что комиссия не имеет полномочий принять исключение по этому вопросу, так как он требует реформирования законодательства. Таким образом складывается ситуация, что пользователь получил право самостоятельно изменить прошивку и обойти привязку к периферийным устройствам на своём Xbox, но распространение кода для осуществления таких действий является незаконным.

Источники:
https://public-inspection.federalregister.gov/2021-23311.pdf
https://www.opennet.ru/opennews/art.shtml?num=56066
https://sfconservancy.org/news/2021/oct/28/2021-DMCA-final-exemptions-win/

Компания Intel развивает протокол HTTPA, дополняющий HTTPS

Инженеры из компании Intel предложили новый протокол HTTPA (HTTPS Attestable), расширяющий HTTPS дополнительными гарантиями безопасности произведённых вычислений. HTTPA позволяет гарантировать целостность обработки запроса пользователя на сервере и убедиться в том, что web-сервис заслуживает доверия и работающий в TEE-окружении (Trusted Execution Environment) на сервере код не был изменён в результате взлома или диверсии администратора.

Показать

HTTPS защищает передаваемые данные на этапе передачи по сети, но не может исключить нарушение их целостности в результате атак на сервер. Изолированные анклавы, создаваемые при помощи таких технологий, как Intel SGX (Software Guard Extension), ARM TrustZone и AMD PSP (Platform Security Processor), дают возможность защитить важные вычисления и снизить риск утечек или изменения конфиденциальной информации на конечном узле.

HTTPA для гарантирования достоверности переданной информации позволяет задействовать предоставляемые в Intel SGX средства аттестации, подтверждающие подлинность анклава, в котором произведены вычисления. По сути HTTPA расширяет HTTPS возможностью удалённой аттестации анклава и позволяет проверить то, что он выполняется в подлинном окружении Intel SGX и web-сервису можно доверять. Протокол изначально развивается как универсальный и помимо Intel SGX может быть реализован и для других TEE-систем.

Помимо штатного для HTTPS процесса установки защищённого соединения, HTTPA дополнительно требует согласования сессионного ключа, заслуживающего доверия. Протокол вводит в обиход новый HTTP-метод «ATTEST», который позволяет обрабатывать три типа запросов и ответов:

«preflight» для проверки, поддерживает ли удалённая сторона аттестацию анклавов;
«attest» для согласования параметров аттестации (выбор криптографического алгоритма, обмен уникальными для сеанса случайными последовательностями, генерация идентификатора сеанса и передача клиенту открытого ключа анклава);
«trusted session» — формирование сессионного ключа для доверительного обмена информацией. Сессионный ключ формируется на основе ранее согласованной предварительной секретной последовательности (pre-session secret), сформированной клиентом с использованием полученного от сервера открытого ключа TEE, и сгенерированных каждой стороной случайных последовательностей.

HTTPA подразумевает, что клиент заслуживает доверия, а сервер нет, т. е. клиент может использовать данный протокол для верификации вычислений в TEE-окружении. При этом HTTPA не гарантирует, что производимые в процессе работы web-сервера остальные вычисления, производимые не в TEE, не были скомпрометированы, что требует применения отдельного подхода к разработке web-сервисов. Таким образом, в основном HTTPA нацелен на использование со специализированными сервисами, к которым предъявляются повышенные требования к целостности информации, такие как финансовые и медицинские системы.

Для ситуаций когда вычисления в TEE должны быть подтверждены как для сервера, так и для клиента предусмотрен вариант протокола mHTTPA (Mutual HTTPA), выполняющий двухстороннюю верификацию. Данный вариант более усложнённый из-за необходимости двустороннего формирования сессионных ключей для сервера и клиента.

Источники:http://www.opennet.ru/opennews/art.shtml?num=56050
https://arxiv.org/pdf/2110.07954.pdf

TLS 1.0 и 1.1 официально признаны устаревшими

Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры Интернет, опубликовал RFC 8996, официально переводящих протоколы TLS 1.0 и 1.1 в разряд устаревших технологий.

Спецификация TLS 1.0 была опубликована в январе 1999 года. Спустя семь лет было выпущено обновление TLS 1.1 с улучшениями безопасности, связанными с генерацией векторов инициализации и добавочного заполнения. По данным сервиса SSL Pulse по состоянию на 16 января протокол TLS 1.2 поддерживают 95.2% web-сайтов, допускающих установку защищённых соединений, а TLS 1.3 — 14.2%. Соединения по TLS 1.1 допускают 77.4% HTTPS-сайтов, а TLS 1.0 — 68%. Примерно 21% из первых 100 тысяч сайтов, отражённых в рейтинге Alexa, до сих пор не используют HTTPS.

Главными проблемами TLS 1.0/1.1 является отсутствие поддержки современных шифров (например ECDHE и AEAD) и наличие в спецификации требования по поддержке старых шифров, надёжность которых на современном этапе развития вычислительной техники поставлена под сомнение (например, требуется поддержка TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, для проверки целостности и аутентификации используется MD5 и SHA-1). Поддержка устаревших алгоритмов уже приводила к появлению таких атак, как ROBOT, DROWN, BEAST, Logjam и FREAK. Тем не менее, данные проблемы непосредственно не являлись уязвимостями протокола и закрывались на уровне его реализаций. В самих протоколах TLS 1.0/1.1 отсутствуют критические уязвимости, которые можно использовать для осуществления практических атак.

Факап года в самом начале

В открытый доступ попало полное содержимое внутреннего Git-репозитория компании Nissan North America. Причиной утечки стал запущенный компанией Git-сервер на базе платформы Bitbucket, для доступа к которому использовалась выставленная по умолчанию учётная запись с именем «admin» и паролём «admin».

В том числе были получены исходные тексты мобильных приложений, диагностических утилит, сервисов NCAR/ICAR, информационной системы для взаимодействия с дилерами, портала для управления логистикой, серверных бэкендов, внутренних информационных систем, автомобильных сервисов, а также различных программ для работы с клиентами, маркетинга и управления продажами. Анализ полученного кода уже позволил выявить в коде диагностической системы ASIST шифрование пароля устаревшим алгоритмом RC4 с жёстко прошитым ключом «Amalesh».

Источники:
http://www.opennet.ru/opennews/art.shtml?num=54366
https://www.zdnet.com/article/nissan-source-code-leaked-online-after-git-repo-misconfiguration/

2021   в мире   сеть   события

Обнаружена уязвимость в чипах Qualcomm и MediaTek с WPA2

Исследователи из компании Eset выявили новый вариант (CVE-2020-3702) уязвимости Kr00k, применимый к беспроводным чипам Qualcomm и MediaTek. Как и первый вариант, которому были подвержены чипы Cypress и Broadcom, новая уязвимость позволяет дешифровать перехваченный Wi-Fi трафик, защищённый с использованием протокола WPA2.

Напомним, что уязвимость Kr00k вызвана некорректной обработкой ключей шифрования при отсоединении (диссоциации) устройства от точки доступа. В первом варианте уязвимости при отсоединении выполнялось обнуление сессионного ключа (PTK), хранимого в памяти чипа, так как дальнейшая отправка данных в текущем сеансе производиться не будет. При этом оставшиеся в буфере передачи (TX) данные шифровались уже очищенным ключом, состоящим только из нулей и, соответственно, могли быть легко расшифрованы при перехвате. Пустой ключ применяется только к остаточным данным в буфере, размер которого составляет несколько килобайт.

Показать

Ключевым отличием второго варианта уязвимости, проявляющейся в чипах Qualcomm и MediaTek, является то, что вместо шифрования нулевым ключом данные после диссоциации передаются вообще не зашифрованными, несмотря на то, что флаги шифрования устанавливаются. Из протестированных на наличие уязвимости устройств на базе чипов Qualcomm отмечены D-Link DCH-G020 Smart Home Hub и открытый маршрутизатор Turris Omnia. Из устройств на базе чипов MediaTek протестирован маршрутизатор ASUS RT-AC52U и IoT-решения на базе Microsoft Azure Sphere, использующие микроконтроллер MediaTek MT3620.

Для эксплуатации обоих вариантов уязвимостей атакующий может отправить специальные управляющие кадры, вызывающие диссоциацию, и перехватить отправляемые следом данные. Диссоциация обычно применяется в беспроводных сетях для переключения с одной точки доступа на другую во время роуминга или при потере связи с текущей точкой доступа. Диссоциацию можно вызвать отправкой управляющего кадра, который передаётся в незашифрованном виде и не требует аутентификации (атакующему достаточно достижимости Wi-Fi сигнала, но не требуется подключение к беспроводной сети). Проведение атаки возможно как при обращении уязвимого клиентского устройства к неуязвимой точке доступа, так и в случае обращения не подверженного проблеме устройства к точке доступа, на которой проявляется уязвимость.

Уязвимость затрагивает шифрование на уровне беспроводной сети и позволяет проанализировать лишь устанавливаемые пользователем незащищённые соединения (например, DNS, HTTP и почтовый трафик), но не даёт возможность скомпрометировать соединения с шифрованием на уровне приложения (HTTPS, SSH, STARTTLS, DNS over TLS, VPN и т. п.). Опасность атаки также снижает то, что за раз атакующий может расшифровать только несколько килобайтов данных, которые находились во время отсоединения в буфере передачи. Для успешного захвата отправляемых через незащищённое соединение конфиденциальных данных, атакующий либо должен точно знать момент их отправки, либо постоянно инициировать отсоединение от точки доступа, что бросится в глаза пользователю из-за постоянных перезапусков беспроводного соединения.

Проблема устранена в июльском обновлении проприетарных драйверов к чипам Qualcomm и в апрельском обновлении драйверов для чипов MediaTek. Исправление для MT3620 было предложено в июле. О включении исправлений в свободный драйвер ath9k у выявивших проблему исследователей информации нет. Для тестирования устройств на подверженность обоих вариантов уязвимости подготовлен скрипт на языке Python.

Дополнительно можно отметить выявление исследователями из компании Сheckpoint шести уязвимостей в DSP-чипах Qualcomm, которые применяются на 40% смартфонов, включая устройства от Google, Samsung, LG, Xiaomi и OnePlus. До устранения проблем производителями детали об уязвимостях не сообщаются. Так как DSP-чип представляет собой «чёрный ящик», который не может контролировать производитель смартфона, исправление может затянуться и потребует координации работ с производителем DSP-чипов.

DSP-чипы используются в современных смартфонах для совершения таких операций как обработка звука, изображений и видео, в вычислениях для систем дополненной реальности, компьютерного зрения и машинного обучения, а также в реализации режима быстрой зарядки. Среди атак, которые позволяют провести выявленные уязвимости, упоминаются: Обход системы разграничения доступа — незаметный захват данных, таких как фотографии, видео, записи звонков, данные с микрофона, GPS и т. п. Отказ в обслуживании — блокирование доступа ко всей сохранённой информации. Скрытие вредоносной активности — создание полностью незаметных и неудаляемых вредоносных компонентов.

Источники
https://www.opennet.ru/opennews/art.shtml?num=53512
https://blog.checkpoint.com/2020/08/06/achilles-small-chip-big-peril/

Let’s Encrypt перешёл к проверке хоста из разных подсетей

Некоммерческий удостоверяющий центр Let’s Encrypt, контролируемый сообществом и предоставляющий сертификаты безвозмездно всем желающим, объявил о внедрении новой схемы подтверждение полномочий на получение сертификата для домена. Обращение к серверу, на котором размещён используемый в проверки каталог «/.well-known/acme-challenge/», теперь будет осуществляться с использованием нескольких HTTP-запросов, отправляемых с 4 разных IP-адресов, размещённых в разных датацентрах и принадлежащих к разным автономным системам. Проверка признаётся успешной только, если как минимум 3 из 4 запросов с разных IP оказались успешными.

Показать

Проверка с нескольких подсетей позволит минимизировать риски получения сертификатов на чужие домены путём проведения целевых атак, перенаправляющих трафик через подстановку фиктивных маршрутов при помощи BGP. При использовании многопозиционной системы проверки атакующему потребуется одновременно добиться перенаправления маршрутов для нескольких автономных систем провайдеров с разными аплинками, что значительно сложнее, чем перенаправление единичного маршрута. Отправка запросов с разных IP кроме того повысит надёжность проверки в случае попадания единичных хостов Let’s Encrypt в списки блокировки (например, в РФ некоторые IP letsencrypt.org попадали под блокировку Роскомнадзора).

До 1 июня будет действовать переходных период, допускающий генерацию сертификатов при успешном прохождении проверки из первичного датацентра, при недоступности хоста с остальных подсетей (например, такое может случиться, если администратор хоста на межсетевом экране разрешил запросы только с основного датацентра Let’s Encrypt или из-за нарушения синхронизации зон в DNS). На основе логов будет подготовлен белый список для доменов, у которых наблюдаются проблемы с проверкой с 3 дополнительных датацентров. В белый список попадут только домены с учётной записью в ACME с заполненными контактными данными. В случае если домен не попал в белый список автоматически заявку на помещение также можно отправить через специальную форму.

В настоящее время проектом Let’s Encrypt выдано 113 млн сертификатов, охватывающих около 190 млн доменов (год назад было охвачено 150 млн доменов, а два года назад — 61 млн). По статистике сервиса Firefox Telemetry общемировая доля запросов страниц по HTTPS составляет 81% (год назад 77%, два года назад 69%), а в США — 91%.

Дополнительно можно отметить, намерение компании Apple прекратить в браузере Safari доверие к сертификатам, время жизни которых превышает 398 дней (13 месяцев). Ограничение планируется ввести только для cертификатов, выписанных начиная с 1 сентября 2020 года. Для полученных до 1 сентября сертификатов с длительным сроком действия доверие будет сохранено, но ограничено 825 днями (2.2 года).

Изменение может негативно отразиться на бизнесе удостоверяющих центров, продающих дешёвые сертификаты с длительным сроком действия, доходящим до 5 лет. По мнению Apple генерация подобных сертификатов создаёт дополнительные угрозы безопасности, мешает оперативному внедрению новых криптостандартов и позволяет злоумышленникам длительное время контролировать трафик жертвы или использовать для фишинга в случае незаметной утечки сертификата в результате взлома.

Источник

Леннарт ’мать его’ Поттеринг представил systemd-homed

Леннарт Поттеринг (Lennart Poettering) на конференции All Systems Go 2019 представил новый компонент системного менеджера systemd — systemd-homed, нацеленный на обеспечение переносимости домашних каталогов пользователей и их отделения от системных настроек. Основная идея проекта в создании самодостаточных окружений для данных пользователя, которые можно переносить между разными системами, не заботясь о синхронизации идентификаторов и конфиденциальности.

Окружение домашнего каталога поставляется в форме монтируемого файла-образа, данные в котором зашифрованы. Параметры учётных данных пользователя привязаны к домашнему каталогу, а не к системным настройкам — вместо /etc/passwd и /etc/shadow используется профиль в формате JSON, хранимый в каталоге ~/.identity. В профиле указаны параметры, необходимые для работы пользователя, включая данные об имени, хэше пароля, ключах для шифрования, квотах и предоставляемых ресурсах. Профиль может быть заверен цифровой подписью, хранимой на внешнем токене Yubikey.

Показать

Параметры также могут включать дополнительные сведения, такие как ключи для SSH, данные для биометрической аутентификации, изображение, email, адрес, часовой пояс, язык, лимиты на число процессов и память, дополнительные флаги монтирования (nodev, noexec, nosuid), данные о применяемых пользователем серверах IMAP/SMTP, информация о включении родительского контроля, параметры резервного копирования и т. п. Для запроса и разбора параметров предоставляется API Varlink.

Назначение и обработка UID/GID производится динамически в каждой локальной системе, к которой подключается домашний каталог. При помощи предложенной системы пользователь может держать свой домашний каталог при себе, например на Flash-накопителе, и получать рабочее окружение на любом компьютере без явного заведения на нём учётной записи (наличие файла с образом домашнего каталога приводит к синтезу пользователя).

Для шифрования данных предлагается использовать подсистему LUKS2, но systemd-homed также позволяет использовать и другие бэкенды, например, для незашифрованных каталогов, Btrfs, Fscrypt и сетевых разделов CIFS. Для управления переносимыми каталогами предложена утилита homectl, которая позволяет создавать и активировать образы домашних каталогов, а также изменять их размер и задавать пароль.

На уровне системы работа обеспечивается следующими компонентами:
systemd-homed.service — управляет домашним каталогом и встраивает JSON-записи напрямую в образы домашнего каталога;
– pam_systemd — обрабатывает параметры из JSON-профиля при входе пользователя и применяет их в контексте активируемого сеанса (проводит аутентификацию, настраивает переменные окружения и т. п.);
– systemd-logind.service — обрабатывает параметры из JSON-профиля при входе пользователя, применяет различные настройки управления ресурсами и выставляет лимиты;
– nss-systemd — модуль NSS для glibc, синтезирует классические записи NSS на основе JSON-профиля, предоставляя обратную совместимость с UNIX API для обработки пользователей (/etc/password);
– PID 1 — динамически создаёт пользователей (синтезирует по аналогии с применением директивы DynamicUser в unit-ах) и делает их видимыми для остальной системы;
– systemd-userdbd.service — транслирует учётные записи UNIX/glibc NSS в записи JSON и предоставляет унифицированный API Varlink для запроса и перебора записей.

Из достоинств предложенной системы отмечается возможность управления пользователями при монтировании каталога /etc в режиме только для чтения, отсутствие необходимости синхронизации идентификаторов (UID/GID) между системами, независимость пользователя от конкретного компьютера, блокировка данных пользователя во время перехода в спящий режим, применение шифрования и современных методов аутентификации. Systemd-homed планируется включить в основной состав systemd в выпуске 244 или 245.

Видео

На Опёнке сразу забурлили, вот несколько комментариев с противоположными мнениями: Показать



Объясните недалёкому, для чего нужен systemd-homed?


– Для корпораций, в будущем твой домашний каталог будет на их серверах в облаке, а локальный компьютер будет тивоизирован и у тебя не будет к нему root доступа.


– Потому что это только в убогой винде все настройки лежат кучкой, в папке c:\windows\system32\config и ещё шести файлах профиля, которые суммарно составляют «реестр Windows». В гениальной же Linux настройки равномерно размазаны тонким слоем по всей системе. И если пользователь захочет просто скопировать окружение на другой комп, он затрахается собирать конфиги по всему диску, ибо где только они не разбросаны... Разве что в своп-разделе нет, и то ещё не уверен — не удивлюсь, если есть и такие компоненты системы, которые их даже там хранят.
Вот для того, чтоб прошерстить весь диск и собрать всё это барахло в единую кучку, и предназначена данная штука.


– что бы когда будет нужно (уже не в столь далёком будущем), отправить «товарищу майору» (или сэру мэйджору?) всё, что можно найти в «домике». Естественно, предварительно открыв канал через уже придуманный systemd. А кто не согласится — отключим газ. Ну или комп. Или хотя бы домик — что бы доказуху не потёрли.
Чует моё сердце, что этот sd довром не кончится — нас ждут весёлые времена и масса открытий. И, возможно, в самое ближайшее время.

Источник

50 лет с момента публикации RFC-1

7 апреля 1969 года был опубликован Request for Comments: 1 (документ, содержащий технические спецификации и стандарты, широко применяемые во всемирной сети). Каждый документ RFC имеет собственный уникальный номер, который используется при ссылке на него. Сейчас первичной публикацией документов RFC занимается IETF под эгидой открытой организации Общество Интернета (англ. Internet Society, ISOC). Именно Общество Интернета обладает правами на RFC.

Документ RFC-1 был написан Стивом Крокером (в то время он был аспирантом Калтеха). Именно он придумал публиковать технические документы в формате RFC. Также он участвовал в создании ARPA «Network Working Group», в рамках которого впоследствии был создан IETF. C 2002 года работал в ICANN, а с 2011 по 2017 возглавлял эту организацию.

Источник

25 лет Рунету

Сегодня — день рождения Рунета!

7 апреля 1994 года для России был зарегистрирован домен .RU и внесён в международную базу данных национальных доменов верхнего уровня. Перед этим, 4 декабря 1993 года, на собрании крупнейших российских провайдеров того времени (Demos Plus, Techno, GlasNet, SovAm Teleport, EUnet/Relcom, X-Atom, FREEnet) было подписано Соглашение «О порядке администрирования зоны .RU».

Показать

Таким образом, Россия была официально признана государством, представленным в Интернете. Согласно соглашению, обязанности по администрированию и техническому сопровождению национального домена .RU были переданы Российскому НИИ Развития Общественных Сетей (РосНИИРОС), который до 2000 года регистрировал все домены в зоне RU.

Уже в первый день существования зоны в ней были зарегистрированы, а впоследствии и делегированы первые доменные имена. До этого все отечественные ресурсы Сети, начиная с 1991 года, размещались в международных доменах и в зоне .SU. Однако, после распада Советского Союза началась работа над созданием доменов новых независимых государств, и со временем появились 15 доменов для бывших советских республик.

Сегодня в России введен еще один домен .рф — национальный домен верхнего уровня для Российской Федерации. Это первый в Интернете домен на кириллице. Отличием от введённого ранее домена «.ru» является то, что в домене «.рф» все имена второго уровня пишутся исключительно кириллицей. Регистрация имён в новой зоне началась в ноябре 2009 года и сначала была доступна только для государственных структур и владельцев торговых знаков. Открытая регистрация доменных имён всех желающих в зоне .рф началась спустя год — в ноябре 2010 года.

30 лет Всемирной паутине

12 марта 1989 года английский специалист в области информатики сэр Тимоти Бернерс-Ли (Tim Berners-Lee) предложил руководству CERN глобальный гипертекстовый проект, который позволил бы ученым организовать совместное хранение и общий доступ к информации. Это был проект Всемирной паутины — World Wide Web или WWW, который был одобрен и реализован.

Ключевые элементы, которые Бернерс-Ли разработал и реализовал совместно со своими соратниками, и сейчас лежат в основе Паутины. Это идентификаторы URL (частный случай унифицированного идентификатора ресурса URI), протокол передачи гипертекстовых документов HTTP и язык разметки таких документов HTML.

Показать

В рамках проекта были выработаны первые спецификации, которые стали стандартами WWW, создан первый в мире веб-сервер «httpd» и первый в мире гипертекстовый веб-браузер, одновременно служивший редактором HTML, работающим по принципу WYSIWYG (What You See Is What You Get — «что видишь, то и получишь»).

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

Источник

Ранее Ctrl + ↓
Наверх