По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Много раз в день вы посещаете веб-сайты, на которых вас просят войти под своим именем пользователя, адресом электронной почты и паролем. Банковские сайты, сайты социальных сетей, почтовые службы, сайты электронной коммерции и новостные сайты - это всего лишь несколько типов сайтов, использующих этот механизм.
Каждый раз, когда вы входите на один из этих сайтов, вы, по сути, говорите: «Да, я доверяю этому сайту, поэтому я хочу поделиться с ним своей личной информацией». Эти данные могут включать ваше имя, пол, физический адрес, адрес электронной почты, а иногда даже информацию о кредитной карте.
Но откуда вы знаете, что можете доверять определенному веб-сайту? Иными словами, что делает веб-сайт для защиты вашей транзакции, чтобы вы могли доверять ей?
Эта статья направлена на демистификацию механизмов, которые делают сайт безопасным. Мы начнем с обсуждения веб-протоколов HTTP и HTTPS и концепции безопасности транспортного уровня (TLS - Transport Layer Security), которая является одним из криптографических протоколов. Затем мы объясним центры сертификации (CA - Certificate Authorities) и самозаверяющие сертификаты и как они могут помочь защитить веб-сайт. Наконец, я представлю некоторые инструменты с открытым исходным кодом, которые вы можете использовать для создания и управления сертификатами.
Защита маршрутов через HTTPS
Самый простой способ понять защищенный веб-сайт - это увидеть его в действии. К счастью, сегодня найти защищенный веб-сайт гораздо проще, чем незащищенный веб-сайт в Интернете. Но, поскольку вы уже находитесь на сайте wiki.merionet.ru, будем использовать его в качестве примера. Независимо от того, какой браузер вы используете, вы должны увидеть значок, который выглядит как замок рядом с адресной строкой. Нажмите на значок замка, и вы должны увидеть что-то похожее на это.
По умолчанию веб-сайт не является безопасным, если он использует протокол HTTP. Добавление сертификата, настроенного через хост сайта, может преобразовать сайт из незащищенного сайта HTTP в защищенный сайт HTTPS. Значок замка обычно указывает, что сайт защищен через HTTPS.
Нажмите на сертификат, чтобы увидеть CA сайта. В зависимости от вашего браузера вам может понадобиться скачать сертификат, чтобы увидеть его.
Здесь вы можете узнать кое-что о сертификате, кем, кому и когда был выдан. Эта информация о сертификате позволяет конечному пользователю проверить, что сайт безопасен для посещения.
ВНИМАНИЕ: Если вы не видите знак сертификата на веб-сайте или если вы видите знак, указывающий на то, что веб-сайт не защищен, пожалуйста, не входите в систему и не выполняйте действия, требующие ваших личных данных. Это довольно опасно!
Если вы видите предупреждающий знак, который редко встречается на большинстве общедоступных веб-сайтов, это обычно означает, что срок действия сертификата истек или используется самозаверяющий сертификат вместо сертификата, выпущенного через доверенный CA.
Интернет-протоколы с TLS и SSL
TLS - это текущее поколение старого протокола Secure Socket Layer (SSL). Лучший способ понять его место - посмотреть на модель OSI.
Есть шесть уровней, которые составляют Интернет, каким мы его знаем сегодня: физический, данные, сеть, транспорт, безопасность и приложения. Физический уровень является базовой основой, и он наиболее близок к реальному оборудованию. Прикладной уровень является наиболее абстрактным и ближайшим к конечному пользователю. Уровень безопасности можно рассматривать как часть уровня приложений, а TLS и SSL, которые являются криптографическими протоколами, разработанными для обеспечения безопасности связи по компьютерной сети, находятся на уровне безопасности.
Основным вариантом использования TLS является шифрование связи между веб-приложениями и серверами, такими как веб-браузеры, загружающие веб-сайт. Протокол TLS также можно использовать для шифрования других сообщений, таких как электронная почта, обмен сообщениями и передача голоса по IP (VOIP).
Центры сертификации и самозаверяющие сертификаты
Центр Сертификации (CA) - это доверенная организация, которая может выдавать цифровой сертификат.
TLS и SSL могут сделать соединение безопасным, но для механизма шифрования необходим способ его проверки - это сертификат SSL/TLS. TLS использует механизм, называемый асимметричным шифрованием, который представляет собой пару ключей безопасности, называемых закрытым ключом (private key) и открытым ключом (public key). Важно знать, что центры сертификации, такие как GlobalSign, DigiCert и GoDaddy являются внешними доверенными поставщиками, которые выпускают сертификаты, которые используются для проверки сертификата TLS/SSL, используемого веб-сайтом. Этот сертификат импортируется на хост-сервер для защиты сайта.
Прежде чем какой-либо крупный веб-браузер, такой как Chrome, Firefox, Safari или Internet Explorer, подключится к вашему серверу по протоколу HTTPS, он уже имеет в своем распоряжении набор сертификатов, которые можно использовать для проверки цифровой подписи, найденной в сертификате вашего сервера. Эти цифровые сертификаты веб-браузера называются сертификатами CA. Если с сертификатом на сервере все ок, то мы попадаем на сайт, а если нет, то браузер покажет нам предупреждение. Закрытые ключи, используемые для подписи сертификатов сервера, уже имеют соответствующие пары открытых ключей в веб-браузерах пользователей.
Однако CA может быть слишком дорогим или сложным, когда вы просто пытаетесь протестировать веб-сайт или услугу в разработке. У вас должен быть доверенный ЦС для производственных целей, но разработчикам и администраторам веб-сайтов необходим более простой способ тестирования веб-сайтов, прежде чем они будут развернуты в рабочей среде - именно здесь приходят самозаверяющие сертификаты.
Самозаверяющий сертификат - это сертификат TLS/SSL, подписанный лицом, которое его создает, а не доверенным центром сертификации. Создать самозаверяющий сертификат на компьютере очень просто, и он может позволить вам протестировать защищенный веб-сайт, не покупая дорогой сертификат, подписанный СА, сразу. Хотя самозаверяющий сертификат определенно рискованно использовать в производственной среде, он является простым и гибким вариантом для разработки и тестирования на подготовительных этапах.
Инструменты с открытым исходным кодом для генерации сертификатов
Для управления сертификатами TLS/SSL доступно несколько инструментов с открытым исходным кодом. Наиболее известным из них является OpenSSL, который включен во многие дистрибутивы Linux и в macOS. Тем не менее, другие инструменты с открытым исходным кодом также доступны.
OpenSSL - Самый известный инструмент с открытым исходным кодом для реализации библиотек TLS и шифрования Apache
EasyRSA - Утилита командной строки для создания и управления PKI CA
CFSSL - PKI/TLS "Швейцарский нож" от Cloudflare
Lemur - Инструмент создания TLS от Netflix
Пока что это обсуждение предполагает, что сетевые устройства будут учитывать отметки, обнаруженные в IP-пакете. Конечно, это верно в отношении частных сетей и арендованных сетей, где условия доверия были согласованы с поставщиком услуг. Но что происходит в глобальном Интернете? Соблюдают ли сетевые устройства, обслуживающие общедоступный Интернет-трафик, и соблюдают ли значения DSCP, а также устанавливают ли приоритет одного трафика над другим во время перегрузки? С точки зрения потребителей Интернета, ответ отрицательный. Общедоступный Интернет - лучший транспорт. Нет никаких гарантий ровной доставки трафика, не говоря уже о расстановке приоритетов.
Даже в этом случае глобальный Интернет все чаще используется как глобальный транспорт для трафика, передаваемого между частными объектами. Дешевые услуги широкополосного доступа в Интернет иногда предлагают большую пропускную способность по более низкой цене, чем частные каналы глобальной сети, арендованные у поставщика услуг. Компромисс этой более низкой стоимости - более низкий уровень обслуживания, часто существенно более низкий. Дешевые каналы Интернета дешевы, потому что они не предлагают гарантий уровня обслуживания, по крайней мере, недостаточно значимых, чтобы вселить уверенность в своевременной доставке трафика (если вообще). Хотя можно отмечать трафик, предназначенный для Интернета, провайдер не обращает внимания на эти отметки. Когда Интернет используется в качестве транспорта WAN, как тогда можно эффективно применять политику QoS к трафику?
Создание качественного сервиса через общедоступный Интернет требует переосмысления схем приоритизации QoS. Для оператора частной сети публичный интернет-это черный ящик. Частный оператор не имеет никакого контроля над общедоступными маршрутизаторами между краями частной глобальной сети. Частный оператор не может установить приоритет определенного трафика над другим трафиком на перегруженном общедоступном интернет-канале без контроля над промежуточным общедоступным интернет-маршрутизатором.
Решение для обеспечения качества обслуживания через общедоступный Интернет является многосторонним:
Контроль над трафиком происходит на границе частной сети, прежде чем трафик попадет в черный ящик общедоступного Интернета. Это последняя точка, в которой оператор частной сети имеет контроль над устройством.
Политика QoS обеспечивается в первую очередь путем выбора пути и, во вторую очередь, путем управления перегрузкой.
В понятие выбора пути неявно подразумевается наличие более одного пути для выбора. В развивающейся модели программно-определяемой глобальной сети (SD-WAN) два или более канала глобальной сети рассматриваются как пул полосы пропускания. В пуле индивидуальный канал, используемый для передачи трафика в любой момент времени, определяется на момент за моментом, поскольку сетевые устройства на границе пула выполняют тесты качества по каждому доступному каналу или пути. В зависимости от характеристик пути в любой момент времени трафик может отправляться по тому или иному пути.
Какой трафик отправляется по какому пути? SD-WAN предлагает детализированные возможности классификации трафика за пределами управляемых человеком четырех-восьми классов, определяемых метками DSCP, наложенными на байт ToS. Политика выбора пути SD-WAN может быть определена на основе каждого приложения с учетом нюансов принимаемых решений о пересылке. Это отличается от идеи маркировки как можно ближе к источнику, а затем принятия решений о пересылке во время перегрузки на основе метки. Вместо этого SD-WAN сравнивает характеристики пути в реальном времени с определенными политикой потребностями приложений, классифицированных в реальном времени, а затем принимает решение о выборе пути в реальном времени.
Результатом должно быть взаимодействие пользователя с приложением, аналогичное полностью находящейся в собственности частной глобальной сети со схемой приоритизации QoS, управляющей перегрузкой. Однако механизмы, используемые для достижения подобного результата, существенно отличаются. Функциональность SD-WAN зависит от способности обнаруживать и быстро перенаправлять потоки трафика вокруг проблемы, в отличие от управления проблемой перегрузки после ее возникновения. Технологии SD-WAN не заменяют QoS; скорее они предоставляют возможность "поверх" для ситуаций, когда QoS не поддерживается в базовой сети.
Когда вы разрабатываете какое-то программное обеспечение, вы поначалу можете не задумываться о часовых поясах. Если только вы не живете в стране, которая имеет несколько часовых поясов, например, в США или России.
Не так давно я столкнулся с проблемой, которая была связана с часовыми поясами. Было несколько юнит-тестов, имеющих дело с датами. Они работали в моем офисе во Франции, но не работали в Марокко у новых членов нашей команды.
Вот тот самый юнит-тест, который работает во Франции, но не работает в Марокко.
Для меня это была возможность научиться правильно обрабатывать дату и время в международном программном обеспечении. В этой статье я расскажу о часовых поясах и поделюсь некоторыми правилами, которым нужно следовать.
Краткое введение в часовые пояса
Поскольку земля имеет форму практически сферы, то солнце восходит в Японии, а садится в Америке. Если бы все использовали глобальное время, то, например, 9:00 было бы восходом солнца в Японии, но закатом в Америки. Это было бы не очень удобно.
Для того, чтобы время согласовывалось с фазами солнца, необходимо перейти от глобального времени ко времени в соответствии с вашим местоположением. В результате земной шар разбивается на часовые пояса (time zones), и каждый из них имеет некоторое смещение (offset). Это смещение представляет собой количество минут, которое необходимо добавить к глобальному времени, чтобы получить время вашего часового пояса. Это смещение может быть положительным или отрицательным.
Глобальное время называется UTC, оно расшифровывается как Universal Time Coordinate (всемирное координированное время). Вы также могли слышать о GMT – часовом поясе без смещения.
Например, когда по UTC время 10:50, то в Сан-Франциско – 03:50 со смещением -0700, а в Пекине – 18:50 со смещением +0800. Однако смещение может быть не только в целых часах. Например, смещение Непала составляет +0545.
В придачу к этому смещению, связанному с часовым поясом, в некоторых странах еще дополнительно смещают часы два раза в год. DST, или летнее время, добавляет еще один час к смещению часового пояса перед наступлением летнего времени. Затем часы переводятся обратно зимой. Цель такого смещения заключается в том, чтобы сделать дневное время длиннее.
Самый простой способ определить часовой пояс – использовать базу данных часовых поясов IANA. В результате вы получите строку, такую как Europe/Paris (Европа/Париж), в соответствии с шаблоном Регион/Город. Кроме того, Microsoft поддерживает собственную базу данных часовых поясов Microsoft, которая используется в их операционных системах. Но использование этой базы может вызвать проблемы при запуске кроссплатформенных приложений .NET Core.
IANA по-прежнему остается лучшим вариантом. База данных Microsoft обновляется не так часто, имеет меньшую историю и использует довольно любопытные названия часовых поясов (например, Romantic Standard Time – романтическое стандартное время) и подвержена ошибкам. Например, постарайтесь не перепутать следующее: Arab Standard Time, Arabic Standard Time и Arabian Standard Time.
И последнее: есть множество способов записать дату. К счастью, спецификация ISO 8601 устанавливает общее правило для представления даты.
Ноябрь 11, 2018 в 12:51:43 AM (в часовом поясе UTC+00:00)
2018-11-05T12:51:43Z