Варьируя сертификат, основанный на клиентской TLS версии в ClientHello
В GNU и большинстве современных BSD find:
find . -maxdepth 1 -type f -name 'TEMP*' ! -name "*[0-9][0-9]"
POSIXly:
find . ! -name . -prune -type f -name 'TEMP*' ! -name "*[0-9][0-9]"
ksh или bash -O extglob или zsh -o kshglob:
ls -ld TEMP*@([^0-9]?|?[^0-9]) [T]EMP TEMP?
Nginx с его расширением lua и его частью ssl может выбирать сертификат для предоставления на основе начала рукопожатия и того, что клиент отправил как ClientHello, но, возможно, не то, что вам нужно, (список алгоритмов поддерживается ).
Полная документация находится по адресуhttps://github.com/openresty/lua-resty-core/blob/master/lib/ngx/ssl.mdи https://github.com/openresty/lua-nginx-module/#ssl_certificate_by_lua_block
.В нем говорится:
It is particularly useful for setting the SSL certificate chain and the corresponding private key on a per-request basis.
...
One can also do interesting things with the SSL handshake requests from the client side, like rejecting old SSL clients using the SSLv3 protocol or even below selectively.
Вы можете легко получить доступ к IP-адресу клиента или сервера (для многосетевых )через функции raw_client_addrи raw_server_addr, а также к имени хоста, к которому пытается подключиться клиент, прочитав часть SNI с помощью server_name. Основываясь на документации, я не вижу доступа к другой части клиента ClientHello, но вы могли бы найти решение уже с вышеизложенным, если вы можете различать своих клиентов на основе их IP, возможно, или если у вас есть два отдельных имени сервера, каждое можно привязать к конкретному сертификату.
Чтениеhttps://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_ssl_certby.cЯ не вижу конкретного метода доступа к списку наборов шифров, отправленных клиентом. Однако этот фрагмент кода получает всю базовую информацию «SSL» из библиотеки openssl, поэтому я подозреваю, что то, что вы хотите, технически возможно, но просто нужно закодировать.
Теперь два других момента:
1 )«Предположим, я все еще могу получить подписанный сертификат MD5 или SHA1».
Это может быть трудно. По крайней мере, из общеизвестного ЦС при работе по умолчанию. Требования CAB Forum(https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf)приведены на стр. 38:
Subscriber Certificates
Digest algorithm: SHA1*, SHA-256, SHA-384 or SHA-512
* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in Section 7.1.3.
, а затем:
7.1.3. Algorithm Object Identifiers
Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm.
2 )«Насколько я понимаю, протокол SSL/TLS содержит защиту от атак с понижением версии, поэтому, если сервер поддерживает версию 1.2, а клиент также поддерживает версию 1.2, то при понижении версии до версии 1.0 соединение должно быть разорвано (в случае активного человека -в --средней атаке )».
Да, но только при использовании расширения TLS_FALLBACK_SCSVи, возможно, запрете повторного согласования клиента во время существующего сеанса. См. пояснения в https://crypto.stackexchange.com/questions/19673/how-does-tls-fallback-scsv-help#19674.но цитируя его основную часть:
Essentially, TLS_FALLBACK_SCSV allows clients to send a hidden version number in the downgraded connection attempt in a way that doesn't trigger the server bugs.
Страница Википедии по адресуhttps://en.wikipedia.org/wiki/Transport_Layer_Securityтакже подробно обсуждает вещи об атаках с понижением версии.
Кстати, это улучшено в TLS 1.3, цитируя 4.1.3. Привет серверу из RFC8446:
TLS 1.3 has a downgrade protection mechanism embedded in the server's random value. TLS 1.3 servers which negotiate TLS 1.2 or below in
response to a ClientHello MUST set the last 8 bytes of their Random
value specially in their ServerHello.
и
For all handshake modes, the Finished MAC (and, where present, the signature) prevents downgrade attacks. In addition, the use of
certain bytes in the random nonces as described in Section 4.1.3
allows the detection of downgrade to previous TLS versions. See
[BBFGKZ16] for more details on TLS 1.3 and downgrade.
У меня была очень похожая проблема. Я не верю, что вы найдете сервер, который делает то, что вы просите. Я также думаю, что тебе следует перестать искать:
НЕ следует полагаться на сертификаты MD5 или SHA1 для защиты любых подключений. Эти сертификаты считаются уязвимыми, поскольку существует риск того, что кто-то может подделать эти сертификаты. Все клиенты теперь должны отклонять старые сертификаты MD5 и SHA1.
Вам следует избегать общения клиентов с вашими серверами по незащищенным соединениям. Если какие-либо клиенты или серверы не могут быть обновлены, вам следует поместить их в собственную безопасную песочницу.
Как решить проблему
Как и вы, я поддерживал старое программное обеспечение, которое нельзя было обновить. Какими бы ни были советы по безопасности, нам всем приходится работать с тем, что у нас есть.
Я рекомендую stunnel . Он работает как автономный сервер, который перенаправляет все соединения, которые он получает :, сначала либо шифруя, либо расшифровывая их.
Чтобы использовать это, в идеале вы должны установить его на старый хост. Отключите SSL в старом программном обеспечении и настройте его для незашифрованного подключения к stunnel вместо подключения к вашему серверу с (небезопасным )шифрованием:
[ "Sandbox" ] [ Wherever ]
[[ old box ]] [[ Wherever ]]
[[[ old Client ] ---->[ stunnel client ]]] ---->[[[ actual server ]]]
Если установка на тот же ящик невозможна, установите его на новый ящик , надежно подключенный к старому хосту. Это может быть просто Raspberry Pi, подключенный к тому же коммутатору :
.[ Securely on the same LAN ("Sandbox") ] [ Wherever ]
[[ old box ] [ new box ]] [[ Wherever ]]
[[[ old Client ]] ---->[[ stunnel client ]]] ---->[[[ actual server ]]]
Если старое программное обеспечение отказывается подключаться без шифрования, вы можете снова использовать stunnel, действуя как сервер, предлагающий старый сертификат MD5 или SHA1. Опять же, они должны быть физически связаны, потому что вы должны думать о соединении со старым сертификатом, как о незашифрованном :
.[ Securely on the same LAN ("Sandbox") ] [ Wherever ]
[[ old box ] [ new box ]] [[ Wherever ]]
[[[ old Client ]] ---->[[ stunnel server ]---->[ stunnel client ]]] ---->[[[ actual server ]]]