Поставил КАВ для проверки системы. Вирусов не находит.
Но зато на все https (и на гугл в том числе) теперь firefox выдает:

Your connection is not secure

The owner of www.google.com has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate.

Сейчас удалю Касперского, посмотрю на результат.

UPD:

Удалил Касперского, https стали доступны в фаерфоксе. Что за чепуха?

Здравствуйте, ivan2016, Вы писали:

I>Удалил Касперского, https стали доступны в фаерфоксе. Что за чепуха?
Касперский выступает в роли дополнительного прокси, чтобы просматривать зашифрованный трафик. Файрфокс не доверяет сертификату, который использует капсерский для реализации легального MITM. Отсюда и блокировка доступа.

Т.е. блокирует доступ не касперский, а браузер из-за жестких настроек HTTPS и отсутствия доверия сертификату каспера.

Здравствуйте, ivan2016, Вы писали:

I>Но зато на все https (и на гугл в том числе) теперь firefox выдает:

КАВ, скажем так, осуществляет MITM, подсовывая свой сертификат. Что бы проблем не было, нужно ставить его сертификат ручками в хранилище FF.

Здравствуйте, Aniskin, Вы писали:

A>КАВ, скажем так, осуществляет MITM, подсовывая свой сертификат. Что бы проблем не было, нужно ставить его сертификат ручками в хранилище FF.

Или отключить проверку HTTPS в Касперском.

Здравствуйте, ivan2016, Вы писали:

Попробуй очистить SiteSecurityServiceState.txt в профиле.

Здравствуйте, ivan2016, Вы писали:

i> Поставил КАВ для проверки системы. Вирусов не находит.
i> Но зато на все https (и на гугл в том числе) теперь firefox выдает:
i> Your connection is not secure

Правильно говорит.

i> Удалил Касперского, https стали доступны в фаерфоксе. Что за чепуха?

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

А на стороне сервера, возможно ли его настроить так, чтобы в подобных случаях был редирект на ту же страницу, но http?

Озадачился переводом сайта на https, но вот из-за таких приколов как-то это не радует. Начал разбираться, и не смог зайти из хрома (Windows XP) на один из сайтов, посвященных SSL в деталях — ошибка несоответствия шифров ERR_SSL_VERSION_OR_CIPHER_MISMATCH. На Windows 7 проблем с заходом нет. Причем сайт первым в поиске вылез.

Если уж переводить на https, то делать, чтобы в случае ошибок был автоматический редирект на http. Вот только возможно ли это?

Здравствуйте, prrt, Вы писали:

p> А на стороне сервера, возможно ли его настроить так, чтобы в подобных случаях был редирект на ту же страницу, но http?

Тут два ответа:

1) Нет, невозможно т.к. сервер в этот момент ничего не знает о том, что происходит на стороне клиента.
2) Это противоречит базовому предназначению HTTPS.

p> Озадачился переводом сайта на https, но вот из-за таких приколов как-то это не радует. Начал разбираться, и не смог зайти из хрома (Windows XP) на один из сайтов, посвященных SSL в деталях — ошибка несоответствия шифров ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Если скажешь название сайта, можно посмотреть точнее, т.к. там может быть много причин: нет поддержки SNI, нет поддержки сертификатов SHA-256 без какого-то обновления, поддерживаются далеко не все современные шифры.

Можешь сам вставить название сайта в SSL Server Test и посмотреть результат.

p> Если уж переводить на https, то делать, чтобы в случае ошибок был автоматический редирект на http. Вот только возможно ли это?

Если тебе требуется поддержка устаревших\неподдерживаемых ОС\браузеров, то придется несколько заморочиться (выделенный IP для сайта, набор шифров с fallback на поддерживаемыми данными ОС\браузерами).

Здравствуйте, Anton Batenev, Вы писали:

AB>Касперский для сбора телеметрии и отсылки куда надо а так же вставки рекламных банеров в код страницы осуществляет MITM-атаку, а единственное предназначение HTTPS — это защита от подобных атак.

Не единственное.

Здравствуйте, Anton Batenev, Вы писали:

AB>Если скажешь название сайта, можно посмотреть точнее, т.к. там может быть много причин: нет поддержки SNI, нет поддержки сертификатов SHA-256 без какого-то обновления, поддерживаются далеко не все современные шифры.
AB>Можешь сам вставить название сайта в SSL Server Test и посмотреть результат.
Сайт вот этот — https://dxdt.ru
Ну и как раз мой случай: Chrome 49 / XP SP3 Server sent fatal alert: handshake_failure

AB>Если тебе требуется поддержка устаревших\неподдерживаемых ОС\браузеров, то придется несколько заморочиться (выделенный IP для сайта, набор шифров с fallback на поддерживаемыми данными ОС\браузерами).
Выделенный IP — это не проблема, это и так есть. А вот по поводу fallback шифров хотелось бы узнать поподробнее — набор шифров же задаётся исключительно конфигурацией сервера (т.е. это зона ответственности openssl)? Или еще и сам покупаемый сертификат не каждый подойдет? Если всё-таки переводить, то покупать сертификат придется, т.к. нужен wildcard, на все поддомены тоже.
А поддержка всего старого нужна. Иногда на работе стоит старьё, админы не обновляют специально, т.к. не нужно. Таких людей мало, но терять их не хотелось бы.

В идеале хотелось бы сделать базовую простейшую http версия сайта, которая работает всегда и везде, и https для современных браузеров и систем. Вот только проблема в том, что если из поиска кто-то перейдет по https ссылке, и сайт не откроется, то сам он вряд ли исправит адрес на http.

Здравствуйте, Aniskin, Вы писали:

A>Здравствуйте, ivan2016, Вы писали:

I>>Но зато на все https (и на гугл в том числе) теперь firefox выдает:

A>КАВ, скажем так, осуществляет MITM, подсовывая свой сертификат. Что бы проблем не было, нужно ставить его сертификат ручками в хранилище FF.

А какие проблемы с безопасностью возможны если добавить сертификат вручную в броузер? Вот скажем если случится настоящий mitm (кроме mitm касперского), файерфокс ругаться же уже не будет?

Здравствуйте, IID, Вы писали:

IID>Не единственное.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, ivan2016, Вы писали:

I>>Удалил Касперского, https стали доступны в фаерфоксе. Что за чепуха?
DOO>Касперский выступает в роли дополнительного прокси, чтобы просматривать зашифрованный трафик. Файрфокс не доверяет сертификату, который использует капсерский для реализации легального MITM. Отсюда и блокировка доступа.

DOO>Т.е. блокирует доступ не касперский, а браузер из-за жестких настроек HTTPS и отсутствия доверия сертификату каспера.

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

Здравствуйте, DOOM, Вы писали:

DOO>Т.е. блокирует доступ не касперский, а браузер из-за жестких настроек HTTPS и отсутствия доверия сертификату каспера.
Как по мне так браузер как раз делает всё правильно.

Здравствуйте, prrt, Вы писали:

p> AB>Можешь сам вставить название сайта в SSL Server Test и посмотреть результат.
p> Сайт вот этот — https://dxdt.ru
p> Ну и как раз мой случай: Chrome 49 / XP SP3 Server sent fatal alert: handshake_failure

А, ну тут все просто — "кривой" набор шифров на сервере. Этот сайт не только в XP не откроется, но и, скажем, в Opera Presto вне зависимости от ОС.

p> AB>Если тебе требуется поддержка устаревших\неподдерживаемых ОС\браузеров, то придется несколько заморочиться (выделенный IP для сайта, набор шифров с fallback на поддерживаемыми данными ОС\браузерами).
p> Выделенный IP — это не проблема, это и так есть. А вот по поводу fallback шифров хотелось бы узнать поподробнее — набор шифров же задаётся исключительно конфигурацией сервера (т.е. это зона ответственности openssl)? Или еще и сам покупаемый сертификат не каждый подойдет? Если всё-таки переводить, то покупать сертификат придется, т.к. нужен wildcard, на все поддомены тоже.

Сертификаты сейчас только SHA-256, и для их поддержки в XP нужен Service Pack 3. По этому с технической точки зрения у тебя здесь выбора нет. Дальше тебе нужно проверить, что корневой сертификат того центра сертификации, у которого ты будешь приобретать сертификат, присутствует в нужной тебе ОС/браузере (у некоторых браузеров собственные наборы корневых сертификатов отличающиеся от системных). Большинство центров имеют сводную табличку по поддержке типа такой, такой, или такой.

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

Что касается самих шифров, то если ты не силен в расшифровке селекторов типа:

kEECDH+AES128:kEECDH+AES256:kRSA+AES128:kRSA+AES256:!aNULL

то просто идешь по знакомой ссылке скажем для google.com и явно прописываешь шифры в порядке их следования. Например, конфигурация для nginx:

server {
    listen [::]:443 ssl default_server ipv6only=off;

    server_name example.com *.example.com;

    ssl_certificate           /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key       /etc/nginx/ssl/example.com.key;
    ssl_dhparam               /etc/nginx/ssl/dh2048.pem;
    ssl_session_cache         shared:SSL:1m;
    ssl_session_timeout       5m;
    ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers               ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:...;
    ssl_prefer_server_ciphers on;
...
}

Проверяешь на всякий случай через вызов:

$ openssl ciphers -v 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:...'

На выходе у тебя должен получиться тот же набор шифров (или меньше в зависимости от openssl) в том же порядке.

Тут весь смысл в том, что сначала идут PFS ECDHE-* шифры (при чем AES128 перед AES256, т.к. AES256 раза в два медленней, а стойкость у него близка к AES128) для современных браузеров, потом обычные RSA-* для Android / Opera Presto, и последний шанс в виде 3DES дается совсем уж древним клиентам (IE 8 / XP). Список шифров "имени гугла", конечно же, не является последней истиной и ты волен составлять список по своему усмотрению, но в интернет-гигантах обычно данный вопрос тщательно исследуют на предмет поддержки разного рода legacy (и сертификат у них обычно от "правильного" центра сертификации).

Строка с явным заданием списка шифров достаточно большая, по этому можно ее сократить написав селектор. Всякие CAMELIA, PSK, SRP, SEED и GOST (если вдруг он каким-то чудом пробрался в список поддерживаемых) можно смело выпиливать (по аналогии с "!aNULL"), т.к. ими никто не пользуется.

Файл dh2048.pem получается вызовом типа:

$ openssl dhparam -out /etc/nginx/ssl/dh2048.pem 2048

и не является обязательным (в этом случае будет использовано значение по умолчанию).

p> В идеале хотелось бы сделать базовую простейшую http версия сайта, которая работает всегда и везде, и https для современных браузеров и систем. Вот только проблема в том, что если из поиска кто-то перейдет по https ссылке, и сайт не откроется, то сам он вряд ли исправит адрес на http.

Если я правильно понимаю текущие тенденции, то скоро у HTTP-сайтов не будет шансов открыться в современном браузере и тебе придется делать выбор "или-или". Доля HTTPS трафика уже более 50% и растет.

Здравствуйте, IID, Вы писали:

IID> AB>Касперский для сбора телеметрии и отсылки куда надо а так же вставки рекламных банеров в код страницы осуществляет MITM-атаку, а единственное предназначение HTTPS — это защита от подобных атак.
IID> Не единственное.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, IID, Вы писали:

IID>>Не единственное.

KV>

Ещё прослушка (sniffing).
От MITM можно защититься просто подписав пакеты, не шифруя их.

Здравствуйте, Михaил, Вы писали:

М>А какие проблемы с безопасностью возможны если добавить сертификат вручную в броузер? Вот скажем если случится настоящий mitm (кроме mitm касперского), файерфокс ругаться же уже не будет?

Я думаю, в этом случае руганется сам Касперкий. Не проверял.

Здравствуйте, CaptainFlint, Вы писали:

CF>Или отключить проверку HTTPS в Касперском.

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

Здравствуйте, Anton Batenev, Вы писали:

p>> Сайт вот этот — https://dxdt.ru
p>> Ну и как раз мой случай: Chrome 49 / XP SP3 Server sent fatal alert: handshake_failure
AB>А, ну тут все просто — "кривой" набор шифров на сервере. Этот сайт не только в XP не откроется, но и, скажем, в Opera Presto вне зависимости от ОС.

Шаман, однако! (c)

P.S. Только что проверил — для Opera Presto этого сайта как будто не существует, зато в Firefox он открывается без проблем.