집 질문 rc4 암호를 사용하는 것은 안전하지 않은 것으로 간주됩니다. 독립적인 문제 해결

rc4 암호를 사용하는 것은 안전하지 않은 것으로 간주됩니다. 독립적인 문제 해결

어떤 이유로 일부 HTTPS 사이트가 열리지 않았습니다(전부는 아닙니다!). 브라우저에서 이러한 사이트를 열려고 하면 "이 사이트는 보안 연결을 제공할 수 없습니다."라는 오류 창이 나타납니다. 사이트가 표시되지 않음 구글 크롬, Opera 및 Yandex 브라우저. HTTPS가 없으면 HTTPS 프로토콜과 HTTP 프로토콜을 통해 페이지에 액세스할 수 있는 페이지만 열리지만 일부 사이트는 열리지 않습니다. Google Chrome에서 HTTPS 사이트를 열 때 오류는 다음과 같습니다.

이 사이트는 보안 연결을 제공할 수 없습니다.
sitename.ru 사이트는 지원되지 않는 프로토콜을 사용합니다.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
클라이언트 및 서버 지원 다른 버전 SSL 프로토콜 및 암호 제품군. 서버가 안전하지 않은 것으로 간주되는 RC4 암호를 사용하고 있을 가능성이 큽니다."

Opera 및 Yandex 브라우저에서 오류는 거의 동일하게 보입니다. 그러한 사이트를 어떻게 열 수 있습니까?

대답

이미 알아차렸겠지만 문제는 컴퓨터와 HTTPS 사이트 간의 SSL 통신 문제와 관련이 있습니다. 이 오류의 원인은 매우 다를 수 있습니다. 이 글에서는 다양한 브라우저에서 "이 사이트는 보안 연결을 제공할 수 없습니다"(이 사이트는 보안 연결을 제공할 수 없습니다, ERR_SSL_PROTOCOL_ERROR) 오류를 수정하기 위한 모든 방법을 수집하려고 했습니다.

사실에도 불구하고 바로 지적하고 싶습니다. 구글 브라우저 Chrome, Opera 및 Yandex 브라우저 출시 다른 회사, 실제로 이러한 모든 브라우저는 동일한 엔진을 기반으로 합니다. Chrome 및 HTTPS 사이트를 여는 오류 문제는 동일한 방식으로 해결됩니다.

먼저 문제가 HTTPS 사이트 자체에 있지 않은지 확인해야 합니다. 다른 기기(휴대폰, 태블릿, 집/회사 컴퓨터 등)에서 열어보세요. 또한 IE/Edge 또는 모질라 파이어 폭스. Firefox에서 유사한 오류가 기사에서 논의되었습니다.

브라우저 캐시 및 쿠키, SSL 캐시 지우기

브라우저 캐시 및 쿠키는 일반적인 원인 SSL 인증서 오류. 먼저 브라우저에서 캐시와 쿠키를 지우는 것이 좋습니다. Chrome에서는 키보드 단축키를 눌러야 합니다. Ctrl + Shift + 삭제, 기간을 선택합니다( 항상) 데이터 지우기 버튼( 데이터 삭제/cleardata).

Windows에서 SSL 캐시를 지우려면:

섹션으로 이동 제어판 -> 브라우저 속성;
탭을 클릭하십시오 콘텐츠;
버튼을 클릭 SSL 지우기 (SSL 상태 지우기);
"SSL 캐시가 성공적으로 지워졌습니다"라는 메시지가 나타나야 합니다.
브라우저를 다시 시작하고 ERR_SSL_PROTOCOL_ERROR 오류가 남아 있는지 확인하는 것이 남아 있습니다.

타사 브라우저 확장 비활성화

비활성화(제거)하는 것이 좋습니다. 타사 확장브라우저, 특히 대상 사이트로의 트래픽 전달을 방해할 수 있는 모든 종류의 익명화, 프록시, VPN, 바이러스 백신 확장 및 기타 유사한 애드온. 다음으로 이동하여 Chrome에서 활성화된 확장 프로그램 목록을 볼 수 있습니다. 설정 -> 추가 도구 -> 확장, 또는 페이지로 이동하여 크롬://확장/. 모든 의심스러운 확장을 비활성화합니다.

바이러스 백신 및 방화벽 설정 확인

컴퓨터에 바이러스 백신 프로그램또는 방화벽(종종 바이러스 백신에 내장되어 있음) 사이트에 대한 액세스가 차단되었을 수 있습니다. 바이러스 백신 또는 방화벽이 사이트에 대한 액세스를 제한하는지 이해하려면 작업을 일시적으로 중단해 보십시오.
많은 최신 바이러스 백신에는 기본적으로 SST/TLS 사이트 인증서를 확인하기 위한 모듈이 있습니다. 안티바이러스가 사이트가 불충분한 보안(또는) 인증서 또는 SSL 프로토콜의 오래된 버전(동일)을 사용하고 있음을 감지하면 해당 사이트에 대한 사용자의 액세스가 제한될 수 있습니다. HTTP/HTTPS 트래픽 스캐닝을 비활성화하고 SSL 인증서. 아시다시피 모든 것은 설치한 바이러스 백신에 따라 다릅니다. 예를 들어:

날짜 및 시간 설정 확인

컴퓨터의 잘못된 날짜와 시간(및 )은 HTTPS 사이트에 대한 보안 연결을 설정할 때 오류를 일으킬 수도 있습니다. 결국 인증을 할 때 시스템은 사이트와 상위 인증 기관의 인증서 생성 날짜와 만료 날짜를 확인합니다.

Windows 루트 인증서 업데이트

컴퓨터가 격리된 세그먼트에 있거나 오랫동안 업데이트되지 않았거나 서비스가 완전히 비활성화된 경우 자동 업데이트, 컴퓨터에 신뢰할 수 있는 새 루트 인증서(TrustedRootCA)가 없을 수 있습니다. 시스템을 업데이트하는 것이 좋습니다. 설치 최신 업데이트보안, Windows 7의 경우 - 반드시 SP1() 및 시간대 업데이트()를 설치하십시오.

다음 문서에 따라 루트 인증서를 수동으로 업데이트할 수 있습니다(이렇게 하면 HTTP 트래픽 및 기타 여러 문제가 가로채는 것을 방지할 수도 있음).

QUIC 프로토콜 지원 비활성화

Chrome에 프로토콜 지원이 활성화되어 있는지 확인 퀵(빠른 UDP 인터넷 연결). QUIC 프로토콜을 사용하면 사이트에 연결할 때 훨씬 빠르게 연결을 열고 모든 TLS(HTTPs) 매개변수를 협상할 수 있습니다. 그러나 경우에 따라 문제가 발생할 수 있습니다. SSL 연결. QUIC 비활성화 시도:

페이지로 이동: chrome://flags/#enable-quic;
옵션 찾기 실험적 QUIC 프로토콜;
Default 옵션의 값을 다음으로 변경하십시오. 장애가 있는;
크롬을 다시 시작합니다.

TLS 및 SSL 프로토콜 지원 활성화

그리고 가장 마지막 단락- 대부분의 경우 문제를 해결하려면 이전 버전의 TLS 및 SSL 프로토콜에 대한 지원을 활성화하는 것으로 충분합니다. 대부분의 경우 가장 효과적이겠지만, 일부러 글의 끝으로 옮겼습니다. 이유를 설명하겠습니다.

TLS 및 SSL 프로토콜의 이전 버전은 개발자의 단순한 변덕이 아니라 공격자가 HTTPS 트래픽에서 데이터를 가로채고 수정할 수 있도록 하는 많은 취약점이 있기 때문에 비활성화됩니다. 이전 프로토콜을 아무 생각 없이 활성화하면 인터넷 보안이 크게 저하되므로 다른 모든 것이 확실히 도움이 되지 않는 경우 이 방법을 최후의 수단으로 사용해야 합니다.

최신 브라우저와 운영 체제는 레거시 및 취약한 SSL/TLS 프로토콜(SSL 2.0, SSL 3.0 및 TLS 1.1)에 대한 지원을 오랫동안 포기했습니다. TLS 1.2 및 TLS 1.3이 이제 표준으로 간주됩니다.

사이트가 클라이언트/브라우저에서 지원하는 것보다 낮은 버전의 SSL/TLS 프로토콜을 사용하는 경우 사용자에게 보안 연결을 설정하는 동안 오류가 표시됩니다.

SSL/TLS 프로토콜의 이전 버전을 활성화하려면(다시 말하지만 이것은 안전하지 않습니다):

위의 모든 방법이 "이 사이트는 보안 연결을 제공할 수 없습니다" 오류를 제거하는 데 도움이 되지 않으면 다음을 시도해 보십시오.

일반 이론: 이 데이터의 암호화를 지원하는 HTTP 데이터 전송 프로토콜의 확장인 HTTPS는 암호화 프로토콜 자체가 아닙니다. 암호화 프로토콜은 SSL 또는 TLS와 같은 암호화를 담당합니다.

동시에 모든 요구르트가 똑같이 유용하지는 않습니다. SSL은 완전히 구식이며 TLS 버전 1.0도 있으므로 오늘날에는 TLS 버전 1.1 또는 1.2만 사용하는 것이 좋습니다. 그건 그렇고, 2000년에 채택된 최신 버전의 HTTPS 사양은 TLS를 통한 HTTP라고 하며 SSL에 대한 언급은 거의 없습니다.

그러나 이것은 이론일 뿐입니다. 실제로 TLS 1.2는 여전히 제한된 수의 사이트에서만 지원되며 TLS 1.1에서는 이미 눈에 띄게 개선되었지만 모든 곳에서 그런 것은 아닙니다. 최신 버전의 TLS를 지원하는 문제는 "클라이언트 측"에도 있으며 나중에 자세히 설명합니다.

따라서 컴퓨터에서 현재 암호화 프로토콜의 최신 버전만 사용하려면 여러 가지 우스꽝스러운 몸짓을 합니다. 왜요? 맞습니다. 아무도 우리 컴퓨터에서 TLS 1.1/1.2를 활성화하지 않을 것이기 때문입니다. 우리에게는 Windows의 "진실성"확인 만 켜고 시작에 많은 "쓰레기"가 채워질 것입니다. 그러나 나는 탈선합니다.

서정적 탈선: 컴퓨터 사용자의 90%가 여전히 Windows 3.11(90년대 초반에 그러한 OS가 있었음) 또는 극단적인 경우 Windows 98 SE를 사용할 수 있다고 진심으로 확신합니다(이 확신은 실제로 확인되었습니다). 쓰기 기계"와 브라우저는 다른 것을 요구하지 않으므로 새롭고 훨씬 더 개선된 인터페이스와 "혁신적인" 새 버전의 OS에 대해 우리에게 거짓말을 하지 않습니다.

하는 것도 사실이다 현대 기술, 보안과 관련하여 오래된 운영 체제에 어떤 식으로든 고정할 수 없습니다. 원칙적으로 불가능해서가 아니라 제조사가 이를 하지 않았기 때문입니다. 따라서 제품군의 모든 운영 체제 Windows 버전 XP 이하(그리고 이미 가까운 미래에 있는 것까지)는 안타깝게도 네트워크 보안 면에서 절망적으로 구식입니다.

여기에서 가사를 마칩니다. 다음 모든 논의는 Windows XP 이상(Vista, 7 또는 8)이 사용된다는 사실을 기반으로 합니다. 그리고 우리 자신은 전혀 사악한 피노키오가 아니기 때문에 적시에 사용하는 OS에 필요한 모든 업데이트와 "패치"를 설치합니다.

따라서 우선 Microsoft TLS/SSL 보안 공급자(schannel.dll)의 책임인 OS 수준에서 TLS 1.1 및 TLS 1.2 지원을 활성화하고 SSL 및 TLS 1.0을 비활성화해야 합니다. 그것은 우리에게 무엇을 줄 것입니까? 자체 TLS 지원 모듈이 없지만 시스템 지원 모듈을 사용하는 모든 프로그램은 현재 버전의 TLS를 사용합니다.

이것은 이론적으로 지원이 이러한 방식으로 구성된다는 것입니다. 현재 버전브라우저를 포함한 TLS 인터넷 익스플로러. 사실 그의 심지어 최신 버전여덟 번째 Windows XP용은 1.0보다 높은 TLS 버전을 지원하지 않습니다. 아래에 윈도우 비스타- 지원하지만 Windows XP에서는 - 아니요 또한 TLS 1.0 사용 금지를 무시합니다. 어때요? 질문은 내가 아니라 Microsoft에 대한 것이지만 우리는 여전히 제조업체의 지침에 따라 우리에게 필요한 작업을 수행할 것입니다.

그리고 다음을 수행합니다. 레지스트리로 이동합니다.
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols에서 PCT 1.0, SSL 2.0, SSL 3.0 및 TLS 1.0 섹션을 찾아 각각의 클라이언트 및 서버 하위 섹션에서 DisabledByDefault 키를 생성합니다(유형 - DWORD )에 값 1(일)을 할당합니다.

그런 다음 동일한 위치에서 TLS 1.1 및 TLS 1.2 섹션을 찾아 앞서 언급한 키를 유사하게 생성하지만 다른 값(0(영))을 할당합니다. 같은 장소에서 약한 암호화 및 해싱 알고리즘 RC2, RC4, DES, MD4 및 MD5를 비활성화하고 암호화 없이 보안 연결을 설정하는 것도 금지합니다(예, 이것은 누군가의 건강에 좋지 않은 환상에서 발생합니다). 상대적으로 강력한 Triple만 남겨둡니다. DES 및 SHA.

어떻게, 무엇을, 어디서 변경해야 하는지 설명하는 것은 솔직히 게으르므로 아래는 레지스트리를 적절하게 변경하는 .reg 파일의 내용입니다. 이 모든 내용을 조심스럽게 클립보드에 복사하고 새로 만들어야 합니다. 텍스트 파일, 내용을 붙여넣고 이 파일을 .reg 확장자로 저장하고 실행한 다음 재부팅하십시오.

재부팅 후 문제가 발생한 경우 네트워크 연결, 다음 파일에 대해 동일한 작업을 수행해야 합니다. 레지스트리에서 수행한 모든 변경 사항을 제거한 다음 (맞습니다, 자식) 다시 재부팅합니다. 레지스트리에서 손상된 레지스트리 섹션의 값을 전혀 찾지 못한 경우 OS는 부팅 시 기본값으로 값을 다시 생성합니다.

고급 사용자는 변경 사항을 완전히 롤백하는 대신 첫 번째 파일을 편집하여 개별 프로토콜과 알고리즘을 활성화 및 비활성화하는 데 어려움을 겪을 수 있습니다. 안주인 참고 사항: 회사를 이용하는 경우 로컬 네트워크, 더군다나 도메인의 경우 문제가 발생할 가능성이 있으니, 네트워크 관리자와 함께 맥주 한병을 마시면서 해결 방법을 찾아보는 것을 추천합니다;)

또한 참고: 크롬 브라우저, Firefox, Opera 및 Safari, 즉 Internet Explorer 엔진을 기반으로 하지 않는 모든 것은 자체 SSL 및 TLS 지원 모듈을 사용하므로 논의한 설정에 의존하지 않습니다. 그러나 이것이 (설정의 의미에서) 무시될 수 있음을 의미하지는 않습니다. 그러나 우리는 다음 시간에 브라우저 자체의 설정에 대해 이야기할 것입니다.

TLS 1.1 및 1.2 활성화, SSL 및 TLS 1.0 비활성화:

"활성화"=dword:00000000

"DisabledByDefault"=dword:00000001
"활성화"=dword:00000000

"DisabledByDefault"=dword:00000001

"DisabledByDefault"=dword:00000000

"AllowInsecureRenegoClients"=dword:00000 000
"AllowInsecureRenegoServers"=dword:00000 000

"활성화"=dword:00000000

모든 것이 고장 났습니까? 변경 사항을 제거합니다.

창 레지스트리 편집기버전 5.00

[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl olSet\Control\SecurityProviders\SCHANNEL]

Google, Microsoft 및 Mozilla는 RC4 암호화 알고리즘에 대한 지원을 완전히 중단하는 데드라인을 발표했습니다.

RC4에 대한 사이버 공격의 위협이 커짐에 따라 이 알고리즘은 빠르게 안정성을 잃기 시작했으며 주요 브라우저 공급업체는 1월 말이나 2월 초에 이 알고리즘을 완전히 포기하기로 결정했습니다.

Mozilla의 Richard Barnes에 따르면 Firefox에서 RC4에 대한 지원은 1월 26일에 예정된 버전 44 릴리스와 함께 중단될 예정입니다. "RC4를 비활성화하면 Firefox가 더 이상 RC4를 사용해야 하는 서버에 연결할 수 없게 됩니다."라고 회사 대변인이 개발자 포럼에서 설명했습니다. "우리가 보유한 데이터에 따르면 그러한 서버는 거의 없지만 Firefox 사용자가 거의 액세스하지 않지만 여전히 존재합니다."

구글의 아담 랭글리(Adam Langley)는 크롬의 해당 릴리스가 1월이나 2월에 일반 대중에게 제공될 것이라고 말했습니다. 그는 날짜를 지정하지 않았으며 독점적으로 RC4를 사용하는 HTTPS 서버가 비활성화될 것이라고만 말했습니다. "Chrome이 HTTPS 연결을 설정할 때 보안을 유지하기 위해 최선을 다해야 합니다."라고 Langley는 전용 메일링 리스트에서 언급했습니다. [이메일 보호됨]- 에 이 순간 HTTPS 연결에서 RC4를 사용하는 것은 이러한 요구 사항을 충족하지 않으므로 향후 Chrome 릴리스에서 RC4에 대한 지원을 제거할 계획입니다."

현재 및 안정적 파이어폭스 버전, 베타 버전은 RC4를 제한 없이 사용할 수 있지만 실제로는 각각 0.08%와 0.05% 연결에 대해서만 사용합니다. Chrome의 경우 이 수치는 0.13%로 약간 높습니다. Langley는 "계속 작업하려면 각 서버의 운영자가 구성을 약간 변경하여 더 강력한 암호 제품군으로 이동하면 될 것입니다."라고 말했습니다.

Microsoft는 제품의 오래된 알고리즘에 대한 지원 종료를 발표했습니다. 마이크로소프트 엣지및 IE 11; 지원은 내년 초 기본적으로 비활성화됩니다. Microsoft Edge의 수석 프로젝트 관리자인 David Walp는 "Microsoft Edge 및 Internet Explorer 11은 TLS 1.2 또는 1.1에서 TLS 1.0으로 다운그레이드할 때 RC4만 사용합니다. - RC4를 사용하여 TLS 1.0으로 대체하는 경우는 대부분 실수로 발생하지만 이러한 상황은 순전히 메시지 가로채기 공격과 구별할 수 없습니다. 이러한 이유로 2016년 초에는 Windows 7, Windows 8.1 및 Windows 10″에서 Microsoft Edge 및 Internet Explorer의 모든 사용자에 대해 RC4가 기본적으로 비활성화됩니다.

10년 이상 동안 연구자들은 이 알고리즘을 사용하여 암호문을 만드는 데 사용되는 임의의 값을 선택할 가능성을 지적하면서 RC4의 불완전성에 대해 불평해 왔습니다. 일정 시간이 주어지면, 컴퓨팅 파워특정 수의 TLS 요청에 액세스하면 공격자에 대한 암호 해독이 어렵지 않습니다.

2013년 일리노이 대학의 다니엘 J. 번스타인(Daniel J. Bernstein)의 연구를 통해 RC4의 알려진 취약점을 공격하여 TLS 세션을 손상시키는 실용적인 방법을 만들 수 있었습니다. 공개된 최초의 그러한 실험 중 하나였습니다.

지난 7월 벨기에 연구원들은 RC4를 공격하여 이전에 가능하다고 생각했던 것보다 훨씬 짧은 시간에 피해자의 쿠키를 가로채 해독할 수 있었습니다.

단지에 대해. 프로그램들. 철. 인터넷. 창