Transport layer security браузер mac os
На macOS рекомендуется использовать последнюю доступную сборку КриптоПро CSP 5.0.
- macOS 11.4 (в других поддерживаемых версиях macOS настройки аналогичны)
- КриптоПро CSP 5.0 R2
- КриптоПро ЭЦП Browser plug-in 2.0
Порядок настройки:
1) Установка КриптоПро CSP 5.0 R2:
Скачайте дистрибутив КриптоПро CSP 5.0 R2 (загрузка доступна после предварительной регистрации на сайте) .
Распакуйте скачанный архив macos — uni . tgz .
Откройте распакованную папку macos — uni .
Запустите файл ru.cryptopro.csp-5.0.12000.dmg.
Следуйте инструкциям установщика.
2 ) Установка КриптоПро ЭЦП Browser Plug-in 2.0:
Запустите скачанный файл cprocsp-pki-2.0.pkg.
Следуйте инструкциям установщика.
Более подробная информация об установке и настройке КриптоПро ЭЦП Browser Plug-in 2.0 на macOS есть на этой странице .
Для дальнейшей настройки используйте графическую панель Инструменты КриптоПро:
3) Установка личного сертификата (при подключенном ключевом носителе):
4) Проверить правильность настройки можно на тестовой странице проверки плагина .
Если настройка произведена корректно, то в поле Сертификат появится строка, соответствующая сертификату.
После выбора сертификата и нажатия кнопки Подписать появится надпись Подпись сформирована успешно.
5) Проверка статуса лицензии КриптоПро CSP 5.0:
6) Активация лицензии КриптоПро CSP 5.0:
Примечания:
a) При необходимости отдельной установки сертификатов
корневых удостоверяющих центров (например, в случае использования неквалифицированного сертификата) или
промежуточных удостоверяющих центров (например, в случае с проблемами автоматического построения цепочки сертификатов по ссылкам из сертификатов)
эти сертификаты можно установить следующим образом:
b) Поддерживаемые ключевые носители:
- USB флеш-накопитель
- жесткий диск компьютера
- Рутокен (для Рутокен S необходима установка драйвера (для macOS 10.9 — 10.13, для macOS 10.14 — 11) и перезагрузка компьютера, при использовании Рутокен S возможны проблемы )
- ESMART
- JaCarta (eToken не поддерживается)
- другие менее распространенные виды токенов
Внимание: в КриптоПро CSP 4.0 ключевые носители eToken и JaCarta не поддерживаются.
c) Возможность работы на macOS с ЭЦП на порталах нужно уточнять в технической поддержке порталов.
Если в требованиях к рабочему месту при работе на портале с ЭЦП только наличие КриптоПро CSP и КриптоПро ЭЦП Browser plug-in, то, вероятнее всего, на этом портале есть возможность работы на macOS.
d) Инструкция по входу на портал gosuslugi.ru , используя сертификат электронной подписи на macOS в связке с КриптоПро CSP, доступна по ссылке .
e) Для работы на портале nalog.ru необходимо:
— иметь в наличии квалифицированный сертификат электронной подписи и соответствующий ему ключ,
— при использовании сертификата по ГОСТ Р 34.10-2012 выполнить команду:
При появлении строки Password: нужно ввести пароль пользователя в операционной системе macOS и нажать клавишу Enter.
— для входа в личный кабинет ИП или ЮЛ с помощью электронной подписи использовать только браузер Chromium GOST (браузер с поддержкой TLS сертификатов по ГОСТ Р 34.10-2012) и входить по прямой ссылке:
https://lkul.nalog.ru — для юридических лиц,
https://lkipgost2.nalog.ru/lk — для индивидуальных предпринимателей.
Чтобы удалить выбранный ранее сертификат электронной подписи из кеша Chromium GOST перезапустите браузер.
При использовании в качестве ключевого носителя облачного токена или простого USB-флеш накопителя Chromium GOST необходимо запускать из Терминала с помощью команды:
Можно также скопировать ключевой контейнер с USB флеш-накопителя на жесткий диск как описано здесь , чтобы не запускать Chromium GOST из Терминала.
Источник
Обходим проверку сертификата SSL
В этом кратком обзоре я хотел бы поделиться своим опытом, как отключить проверку SSL для тестовых сайтов, иначе говоря, как сделать HTTPS сайты доступными для тестирования на локальных машинах.
В современное время https протокол становится все популярней, у него масса плюсов и достоинств, что хорошо. Правда для разработчиков он может вызывать легкий дискомфорт в процессе тестирования.
Всем известно, что при посещении сайта у которого “временно” что-то случилось c сертификатом вы обнаружите предупреждение, которое показывается, если сертификат безопасности не является доверенным net::ERR_CERT_AUTHORITY_INVALID?
Все современные браузеры показывают сообщение об ошибке HSTS
Самый простой способ обхода данного запрета — это, разумеется, нажатие на вкладку “Дополнительные” и согласиться с Небезопасным режимом.
Но не во всех браузерах как оказывается, есть данная возможность. Так я столкнулся с данной проблемой в Chrome на Mac OS
Разработчики данной операционной системы настолько обеспокоены безопасностью пользователей, что даже убрали доступ в «Небезопасном режиме» к сайту, несмотря на то, что это сайт владельца устройства.
Ну что ж, поскольку, вести разработку в других, более сговорчивых браузерах было не комфортно, вот способы как обойти эту проблему:
— Все хромоподобные браузеры (Chrome, Opera, Edge …) могут открыть небезопасную веб страницу, если на английской раскладке клавиатуры набрать фразу:
прямо на данной веб странице. Это даст возможность работать с сайтом без оповещение об ошибке на момент текущей сессии браузера, пока вы не закроете вкладку Chrome.
— Если же вам предстоит более длительная работа с сайтом, то рекомендую для этих нужд создать отдельного тестового пользователя на рабочем столе и указать ему необходимы флаги.
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe» —ignore-certificate-errors
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome —ignore-certificate-errors —ignore-urlfetcher-cert-requests &> /dev/null
Achtung! Данные манипуляции необходимо выполнять с выключенным Chrome приложением, иначе чуда не произойдет.
Если вы оставите сертификат ненадежным, то некоторые вещи не будут работать. Например, кэширование полностью игнорируется для ненадежных сертификатов.
Браузер напомнит, что вы находитесь в небезопасном режиме. Поэтому крайне не рекомендуется шастать по злачным сайтам Интернета с такими правами доступами.
*Так же есть метод с добавлением сертификатов тестируемого сайта в конфиги браузера Настройки->Безопасность->Настроить сертификаты->Импорт… но мне он показался не продуктивным и очень муторным, поэтому не привожу
Надеюсь моя краткая статья кому-то пригодится при разработке и тестировании сайтов =)
Источник
Как легко расшифровать TLS-трафик от браузера в Wireshark
Многим из вас знаком Wireshark — анализатор трафика, который помогает понять работу сети, диагностировать проблемы, и вообще умеет кучу вещей.
Одна из проблем с тем, как работает Wireshark, заключается в невозможности легко проанализировать зашифрованный трафик, вроде TLS. Раньше вы могли указать Wireshark приватные ключи, если они у вас были, и расшифровывать трафик на лету, но это работало только в том случае, если использовался исключительно RSA. Эта функциональность сломалась из-за того, что люди начали продвигать совершенную прямую секретность (Perfect Forward Secrecy), и приватного ключа стало недостаточно, чтобы получить сессионный ключ, который используется для расшифровки данных. Вторая проблема заключается в том, что приватный ключ не должен или не может быть выгружен с клиента, сервера или HSM (Hardware Security Module), в котором находится. Из-за этого, мне приходилось прибегать к сомнительным ухищрениям с расшифровкой трафика через man-in-the-middle (например, через sslstrip).
Логгирование сессионных ключей спешит на помощь!
Настраиваем браузеры
Нам необходимо установить переменную окружения.
Windows
Откройте свойства компьютера, затем «Дополнительные параметры системы», затем «Переменные среды…»
Добавляем новую пользовательскую переменную «SSLKEYLOGFILE», и указываем путь до файла, куда мы хотим его сохранять.
Linux и Mac OS X
/.bashrc на Linux или в
/.MacOSX/environment на OS X, чтобы вам не пришлось ее устанавливать каждый раз после перелогина.
В следующий раз, когда вы запустите Firefox или Chrome из Dev channel, они будут логгировать TLS-ключи в этот файл.
UPD: Если у вас ничего не работает на OS X, загляните в комментарии (оригинальной статьи). Похоже, Apple изменила работу переменных окружения в новой версии OS X. Попробуйте запускать Firefox и Wireshark из этого же терминального окна:
Спасибо Tomi за это замечание.
Настраиваем Wireshark
Вам понадобится Wireshark версии 1.6 и новее. Открываем настройки Wireshark: 
Разворачиваем секцию «Protocols»:
Указываем путь к файлу:
Результат
Вот что мы обычно видим, когда инспектируем TLS-пакет:
А вот что происходит, когда мы переключаемся на вкладку «Decrypted SSL Data». Теперь мы можем видеть текст запроса. Победа!
Заключение
Надеюсь, теперь вам будет гораздо проще перехватывать TLS. Одна примечательная особенность этого метода заключается в том, что устанавливать Wireshark на компьютер, который генерирует TLS-трафик, не требуется, поэтому вам не придется устанавливать ненужные клиентам программы, вы можете сохранить дамп в файл на сетевой диск или просто скопировать его с машины, и использовать с дампом трафика.
Источник
Как подружить «современный» TLS и «устаревшие» браузеры?
Тему подсказало обсуждение предыдущего поста, в котором прозвучал голос заботливого администратора веб-сервера: TLS 1.2 и AEAD – выбор здорового человека, но кто пожалеет пользователей «устаревших» браузеров? Давайте это обсудим – мнимую несовместимость «современного» TLS и «устаревших» браузеров.
Гипотеза звучит следующим образом: если на веб-сервере оставить поддержку только устойчивых версий протокола защиты транспортного уровня TLS (1.2 и 1.3) и шифронаборов (AEAD), пользователи «устаревших» браузеров зайти на сайт не смогут.
Совершим необязательный экскурс в историю… В 2005 году (т.е. 16 лет тому назад), американское Агентство национальной безопасности анонсировало корпус стандартов, руководств, рекомендаций и прочих поддерживающих документов по использованию криптографических алгоритмов – NSA Suite B Cryptography.
В 2009 году IETF опубликовал RFC5430 Suite B Profile for Transport Layer Security, где установил, какие протоколы и шифронаборы должны использоваться для HTTPS-соединения, чтобы соответствовать требованиям АНБ. Уже тогда для соответствия этим требованиям веб-сервер и веб-браузер должны были поддерживать TLS версии 1.2 и шифронаборы TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 и TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
То есть, как минимум последние 11 лет разработчики знали, каким требованиям должна соответствовать их продукция, чтобы иметь возможность претендовать на американский госзаказ. Поэтому следующий факт вы, вероятно, воспримете без удивления: все реально используемые сегодня браузеры поддерживают упомянутый шифронабор в варианте с 128-битным шифроключом, а многие (но не все) – и с 256-битным.
На этом можно было бы закончить статью, порекомендовав всем администраторам веб-серверов оставить поддержку только TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 и не забивать себе голову мифами о несовместимости TLS 1.2 с «устаревшими» браузерами, если бы не нюанс: в TLS версии младше 1.3 алгоритм цифровой подписи в шифронаборе должен совпадать с алгоритмом в TLS-сертификате, а веб-серверов с сертификатом, подписанным по алгоритму ECDSA, в доменной зоне .RU менее 6%, оставшиеся используют для подписи RSA.
Кто виноват – вопрос отдельного исследования, нас же интересует что делать? Давайте для начала вспомним, что к устойчивым шифронаборам сегодня относятся не только рекомендуемая АНБ комбинация ECDHE+ECDSA+AES, но и другие:
Итого 19 устойчивых шифронаборов, однако не все из них подходят для использования в реальной жизни на публичном веб-сервере: алгоритм шифрования CAMELLIA, как и AES в режиме CCM, поддерживается чуть более, чем никем, с CHACHA20 и его верным спутником POLY1305 знакомы лишь относительно современные браузеры, а для использования шифронаборов на основе ECDSA, как уже было сказано, требуется соответствующий TLS-сертификат. Таким образом у нас остается лишь 4 «дополнительных» шифронабора:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.
Соблазнительно предположить, что если браузер поддерживает комбинацию ECDHE+ECDSA, то уж с ECDHE+RSA он точно справится, но это не всегда так – многие умеют только в DHE+RSA, и чтобы удовлетворить запросы всех старых браузеров, на сайте с RSA сертификатом необходимо поддерживать два шифронабора:
Это даст нам совместимость как минимум со следующими операционными системами и браузерами:
Android 4.4.2 + Android Browser (Chrome);
Windows XP + Chrome 49/Firefox 49/ Opera 12.18;
Windows 7 + Internet Explorer 11/Chrome 31/Firefox 31;
OS X + Firefox 29/Chrome 37;
iOS 9 + Safari 9;
Java 8b.
Про *nix системы не скажу – зависит от сборки, но очевидно, что проблемы как таковой не существует. Единственная проблема возникнет с Windows Phone 8.1 + IE 10, которые поддерживают только одну устойчивую комбинацию – ECDHE+ECDSA.
А что же делать пользователям Windows XP + IE 6 или какого-нибудь Android 2.3? – спросит заботливый админ. Продолжать сидеть без доступа к современному Интернету, – отвечу я, – поскольку даже поддержка веб-сервером протокола SSL 2.0 им ничем не поможет. Дело в том, что даже если накатить на Windows XP все выпущенные для него обновления (по май 2019 года) и обновить штатный браузер до версии 8, это принесет лишь поддержку TLS 1.2, но не устойчивых шифронаборов. Кроме того, Windows XP как не знал, так и не узнает, что такое Server Name Indication (SNI), HTML 5 Live HTML и CSS 3.
Готовы ради упертых «полутора землекопов» держать для сайта выделенный IP и не обновлять верстку? Тогда добавьте поддержку, например, TLS_RSA_WITH_AES_256_CBC_SHA256, но скорее следует предположить, что современный пользователь Windows XP уже давно пользуется альтернативным браузером, который поддерживает даже TLS 1.3. То же верно и для Android 2.3, установив на который Firefox 27, мы получим полноценную поддержку TLS 1.2 и AEAD шифронаборов, а не установив – просто не сможем пользоваться значительной частью современных сайтов даже по HTTP.
Все вышесказанное, разумеется, не является призывом к отказу от поддержки более стойких шифронаборов, которые будут востребованы современными браузерами, и которые следует предлагать для согласования в первую очередь.
Чтоб два раза не вставать, рассмотрим кратко и ситуацию с эллиптическими кривыми. NSA Suite B Cryptography признает только две из них – NIST P-384 и NIST P-256, поддержка которых на веб-сервере обеспечит доступ к сайту как современных, так и «устаревших» браузеров. Собственно, достаточно поддерживать только NIST P-384 для «старичков» и Curve25519 для современных браузеров; ну разве что еще NIST P-521 добавить, для некоторых «передовых старичков».
Подытожим: если мы хотим, чтобы сайт оставался доступен для «устаревших» браузеров, но при этом поддерживал только устойчивые версии протокола защиты транспортного уровня и шифронаборов, поступим следующим образом.
Для сайта с TLS-сертификатом, подписанным по алгоритму ECDSA, включим поддержку шифронабора TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
Для сайта с TLS-сертификатом, подписанным по алгоритму RSA, включим поддержку шифронаборов TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 и TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.
Для обоих сайтов включим поддержку эллиптической кривой NIST P-384 или NIST P-256 и зададим порядок предпочтения шифронаборов и эллиптических кривых, согласно которым вышеуказанные наборы и кривые предлагаются браузерам для согласования после более устойчивых, например после TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 и Curve25519 соответственно.
Источник
