Chrome is very picky when it comes to this particular topic, it considers cipher suite to be modern if it has either AES_128_GCM or CHACHA20_POLY1305 as an AEAD construction. Source.
That does sound like a configuration issue in Azure. Chrome is specifically complaining about your cipher suite order. I don’t know how to configure Azure, so I can’t give specific advice, but if you want to fix this message you should find the relevant configuration option to change your cipher suite order. Mozilla has some good advice on cipher suites: https://wiki.mozilla.org/Security/Server_Side_TLS.
Требования к современному набору шифров:
— шифр AES_128_GCM (режим Galois/Counter) или CHACHA20_POLY1305
— обмен ключами DHE_RSA, ECDHE_RSA или ECDHE_ECDSA
Список соответствующих наборов:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
Изначально Microsoft поддерживает шифрование в режиме Galois/Counter в контексте методов обмена ключами RSA, DHE_RSA и ECDHE_ECDSA. Для использования последнего требуется сертификат с другим типом ключа.
Поддержка Galois/Counter в контексте ECDHE_RSA (самого популярного метода) введена лишь в Windows Server 2016.
Следующие наборы шифров поддерживаются Microsoft (НЕ принимая во внимание Windows Server 2016) и удовлетворяют требованиям Chrome:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Использовать первый — себе и вашим посетителям дороже! Сервер будет использовать прописанные по умолчанию 1024-разрядные параметры Диффи-Хеллмана без возможности изменения, это даже менее безопасно, чем использование обычного RSA, хоть и не отвечающего требованиям Chrome. “Современный набор шифров” в случае DHE_RSA — это просто театр безопасности. Chrome не учитывает разрядность параметров и вообще не позволяет их посмотреть в интерфейсе браузера, в отличие от Internet Explorer. Требуется Wireshark или другой сетевой анализатор.
В ближайшем будущем поддержка традиционного Диффи-Хеллмана будет вообще удалена из Chrome как раз по причине того, что 95% таких соединений используют 1024-разрядные параметры.
Даже если начать требовать от сайтов как минимум 2048-разрядные параметры, остаются две фундаментальные проблемы, одна хуже другой:
Для обмена ключами должны использоваться безопасные простые числа. Это числа q=2p+1, где p тоже простое (число Софи Жермен). Однако у браузеров попросту нет времени на проверку такого соответствия.
Браузеры вообще не проверяют, что используется простое число. Составные числа тоже работают, хоть это и недопустимо.
Остаётся только TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, но для его использования нужен сертификат с ключом не RSA, а на эллиптических кривых. Let’s Encrypt планирует добавить поддержку в следующем году, но тогда уже выйдет Windows Server 2016 с поддержкой современного режима шифрования совместно с ECDHE_RSA.
Сейчас у вашей компании две проблемы:
Используется Microsoft IIS вместо nginx или другого нормального сервера.
Используется сертификат уровня Domain Validation, выданный без проверки документов. Кем было потверждено владение доменом? На чьё имя выдан сертификат? Как я могу быть уверен, что этот сертификат не был получен мошенническим путём? Представьте, что вы когда-то для своего (суб)домена сделали в DNS A-запись на сервер, над которым позже потеряли контроль. Следующий пользователь сервера запросто подтвердит владение и получит такой же сертификат Let’s Encrypt, у которого даже не будет персональных и банковских данных того, кем было подтверждено владение. Это реальные случаи. Могу вам на примере самого же Let’s Encrypt показать.
У обычных центров сертификации даже для получения сертификата Domain Validation запрашиваются ПД, пусть и не проверяются. Начиная с Organization Validation, ПД запрашиваются и проверяются.
Вам следует приобрести сертификат Extended Validation, чтобы название организации писалось в адресной строке. Это позволит посетителям сразу же быть уверенным, что для шифрования данных используется публичный ключ, ассоциированный с сертификатом, выданным на имя вашей организации после проверки документов, без необходимости открывать свойства сертификата, как в случае с Organization Validation. Ещё одно преимущество Extended Validation — упоминание в сертификате ОГРН, уникально отличающего вашу организацию от других со схожими названиями. Ах, да, ещё для Extended Validation проверка статуса обязательна. Если статус проверить не удалось (например, из-за тех. работ на стороне центра сертификации), названия организации в адресной строке не будет, только зелёный замочек. Для остальных сертификатов Chrome проверку статуса даже не делает. Если сертификат отозван, об этом узнают только пользователи Firefox и Internet Explorer, которых меньше, чем пользователей Chrome. Создаётся впечатление, что о безопасности клиентов не заботитесь.
