일부 오래된 클라이언트가 MD5 및 SHA1 서명만 지원할 수 있는 시나리오가 있습니다. 분명히 이것들은 일반적으로 더 이상 사용되지 않는 것으로 간주되지만 여전히 지원해야 합니다. 이러한 클라이언트를 업그레이드하는 것은 수행할 수 있는 작업이 아닙니다(펌웨어 업데이트는 더 이상 릴리스되지 않으며 이상적으로는 이러한 장치를 모두 종료하고 싶지만 그것도 불가능합니다).
여전히 MD5 또는 SHA1 서명 인증서를 얻을 수 있다고 가정합니다.
처음 연결할 때 클라이언트가 보낸 ClientHello 블록에 포함된 수신 TLS 버전을 기반으로 모든 (https) 서버에서 다른 인증서를 제공할 수 있습니까?
클라이언트에서 들어오는 처음 몇 바이트를 읽은 다음 최악의 시나리오에서 다른 요청을 처리하는 대체 포트에 연결을 연결하는 작은 "프록시"를 작성하면 가능하다고 생각하지만 가능하면 피하는 것이 좋습니다. 기존 웹 서버가 그러한 기능을 지원하는 경우입니다.
내레이터: 제가 아는 한 SSL/TLS 프로토콜에는 다운그레이드 공격에 대한 보호 기능이 포함되어 있으므로 서버가 1.2를 지원하고 클라이언트도 1.2를 지원하는 경우 1.0으로의 다운그레이드가 발생하면 연결이 종료되어야 합니다(활성 상태인 경우). 맨인 공격 발생) - 중간 공격). 나는 이것이 이전 SSL/TLS 버전을 계속 지원하면서 최소한 MD5 또는 SHA1 서명 인증서를 제공하는 위험을 최대한 줄여야 한다고 생각합니다.
답변1
Lua 확장 및 SSL 부분이 포함된 Nginx는 핸드셰이크 시작과 클라이언트가 보내는 내용을 기반으로 노출할 인증서를 선택할 수 있지만 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
그것은 다음과 같이 말합니다:
요청별로 SSL 인증서 체인과 해당 개인 키를 설정하는 데 특히 유용합니다.
...
SSLv3 프로토콜이나 더 낮은 버전을 사용하는 이전 SSL 클라이언트를 선택적으로 거부하는 등 클라이언트의 SSL 핸드셰이크 요청으로 몇 가지 흥미로운 작업을 수행할 수도 있습니다.
SNI 부분을 읽어 클라이언트가 액세스하려는 호스트 이름과 함수를 통해 raw_client_addr클라이언트 또는 서버 IP(멀티홈 IP의 경우)에 쉽게 액세스 할 수 있습니다 . 문서에 따르면 클라이언트의 ClientHello에 액세스하는 다른 부분을 볼 수 없지만 IP를 기준으로 클라이언트를 구별할 수 있거나 두 개의 별도 서버 이름이 있는 경우 위의 솔루션을 찾을 수 있습니다. 특정 인증서가 함께 연결되어 작동할 수 있습니다.raw_server_addrserver_name
읽다https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_ssl_certby.c클라이언트가 보낸 암호화 제품군 목록에 액세스하는 구체적인 방법이 표시되지 않습니다. 그러나 이 코드는 openssl 라이브러리에서 모든 기본 "SSL" 정보를 가져오므로 원하는 것이 기술적으로 가능하다고 생각되지만 코딩만 필요합니다.
이제 두 가지 사항이 더 있습니다.
1) "아직 MD5 또는 SHA1 서명 인증서를 얻을 수 있다고 가정합니다."
이것은 어려울 수 있습니다. 적어도 기본 작동 시 공개적으로 알려진 CA에서. CAB 포럼 요구 사항(https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf) 38페이지에 이런 내용이 있습니다.
사용자 인증서
다이제스트 알고리즘: SHA1*, SHA-256, SHA-384 또는 SHA-512
* SHA-1은 섹션 7.1.3에 정의된 표준에 따라 RSA 키와 함께 사용할 수 있습니다.
그런 다음:
7.1.3.알고리즘 객체식별자
2016년 1월 1일부터 CA는 SHA-1 해시 알고리즘을 사용하여 새로운 가입자 인증서 또는 하위 CA 인증서를 발급할 수 없습니다.
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설명하되 핵심 부분을 인용하자면 다음과 같습니다.
기본적으로 TLS_FALLBACK_SCSV를 사용하면 클라이언트는 서버 오류를 유발하지 않는 방식으로 다운그레이드된 연결 시도 시 숨겨진 버전 번호를 보낼 수 있습니다.
Wikipedia 페이지는 다음 위치에 있습니다.https://en.wikipedia.org/wiki/Transport_Layer_Security다운그레이드 공격에 대해서도 자세히 설명합니다.
그런데 이는 TLS 1.3에서 4.1.3을 참조하여 개선되었습니다. RFC8446의 서버 인사말:
TLS 1.3은 서버의 임의 값에 성능 저하 방지 메커니즘을 내장합니다. ClientHello에 대한 응답 으로 TLS 1.2 이하를 협상하는
TLS 1.3 서버는
ServerHello에서 임의 값의 마지막 8바이트를 구체적으로 설정해야 합니다.
그리고
모든 핸드셰이크 모드에서 완성된 MAC(및 존재하는 경우 서명)은 다운그레이드 공격으로부터 보호합니다. 또한 섹션 4.1.3에 설명된 대로 이전 TLS 버전으로의 다운그레이드는
nonce의 특정 바이트를 사용하여 감지할 수 있습니다. TLS 1.3 및 다운그레이드에 대한 자세한 내용은 [BBFGKZ16]을 참조하세요.
답변2
나는 매우 비슷한 문제가 있습니다. 귀하의 요구 사항을 충족하는 서버를 찾을 수 있을 것이라고 생각하지 않습니다. 나도 생각한다그만 찾는 게 좋을 것 같아:
연결을 보호하기 위해 MD5 또는 SHA1 인증서에 의존해서는 안 됩니다. 이러한 인증서는 누군가가 위조할 위험이 있으므로 취약한 것으로 간주됩니다. 이제 모든 클라이언트는 이전 MD5 및 SHA1 인증서를 거부해야 합니다.
보안되지 않은 연결을 통해 서버와 통신하는 클라이언트를 피해야 합니다. 업그레이드할 수 없는 클라이언트나 서버가 있으면 자체 보안 샌드박스에 넣어야 합니다.
문제를 해결하는 방법
당신처럼 나도 업그레이드할 수 없는 오래된 소프트웨어를 지지합니다. 안전 권장사항이 무엇이든 우리는 보유한 자원을 활용하여 작업해야 합니다.
나는 추천한다터널. 이는 독립 실행형 서버로 실행되어 수신되는 모든 연결을 전달합니다. 먼저 연결이 암호화되거나 해독됩니다.
이를 사용하려면 이전 호스트에 설치하는 것이 좋습니다. 이전 소프트웨어에서 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 ]]]