01 ERR_SSL_VERSION_OR_CIPHER_MISMATCH_TLS 이란?

클라이언트가 브라우저에서 https 접속 시 브라우저에서 아래와 같은 오류가 발생하는 이슈로

해당 문구는 Chrome에서 발생하는 메시지이고, 브라우저 별로 메시지가 상이함


[Internet Explorer]

이 페이지를 표시할 수 없습니다.

[고급] 설정에서 TLS 1.0 TLS 1.1 및 TLS 1.2를 켠 다음 해당 홈페이지에 다시 연결해 보세요.

안전하지 않은 RC4와 같은 암호 그룹을 사용할 수도 있습니다.

 

[Chrome]

“사이트에 보안 연결할 수 없음”

해당 홈페이지에서 지원되지 않는 프로토콜을 사용합니다

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

 

[firefox]

“보안 연결 실패”

해당 홈페이지에 접속하는 중에 오류가 발생했습니다.

SSL_ERROR_NO_CYPHER_OVERLAP

 

02 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 오류 발생 원인

서버에서 낮은 알고리즘만을 이용한 통신 환경 제공 시

클라이언트 측에서 낮은 브라우저 환경으로 인해, 낮은 알고리즘을 통한 통신 환경을 시도할 경우

           - 낮은 브라우저 : Chrome 48 이하, Internet Explorer 11 이하, Microsoft Edge 이하, Firefox 44 이하 ( 정책 적용 버전은 공지 내용과 다를 수도 있음 )

 

           - 낮은 알고리즘 : RC4를 포함한 알고리즘 ( 예: RC4-SHA, RC4-MD5, ECDH-RSA-RC4-SHA 등 )

 

03 RC4 알고리즘의 취약성

 03.1 RC4 암호란?

       - 1987년 Ron Rivest가 설계한 스트림 암호로 1995년부터 SSL의 표준 암호화 프로토콜

 

       - 2011년 BEAST(Browser Exploit Against SSL/TLS) 공격에 취약점 발견

 

       - 2014년 POODLE 공격에 취약점 발견

 

 03.2 BEAST 공격이란?

           - 사용자 브라우저 취약점을 이용하여 중간에서 HTTPS 쿠키를 훔쳐 공격하는 기법

 

 03.3 POODLE 공격이란?

           - TLS 연결을 SSL 3.0으로 낮춰 SSL 3.0 취약점을 이용하여 암호문 해독하는 공격 기법

 

  03.4 현재 RC4 알고리즘 규제 현황

           - Google, Mozilla, Microsoft 등 2016년 초부터 브라우저의 RC4 지원 중단 선언

 

           - 금융보안원 RC4 규제 가이드 발표 ( 하단 출처 참조 )

 

04 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 오류 해결 방안

 → 서버에서 RC4 알고리즘 비활성화

 

[IIS]

RC4알고리즘 000000000으로 Enabled

 

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ RC4 128/128]

“Enabled”= dword : 00000000

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ RC4 40/128]

“Enabled”= dword : 00000000

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ RC4 56/128]

“Enabled”= dword : 00000000

 

[Apache]

RC4 알고리즘 전체 사용 안함

SSLProtocol ALL –SSLv2 –SSLv3 –TLSv1

SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3

 

[Tomcat]

ciphers="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"

        disableSessionTickets="true"

        honorCipherOrder="false"

        protocols="TLSv1.2, TLSv1.3">

 

[client PC]

사용자의 브라우저에서 높은 수준의 알고리즘으로 접속하도록 설정

인터넷 옵션-고급- SSL 3.0, TLS 1.0 사용 제한하고, TLS 1.1, TLS 1.2를 사용하도록 체크 설정 후 확인

 

05 사이트 확인

https://ssllabs.com 홈페이지에서 도메인 입력 후 프로토콜 사용 여부 확인 가능

 

 

참고 URL : https://blog.naver.com/ucert/221956614604

 

 

 

 

SNI 는 Server Name Indication(서버 이름 표시)의 줄임말로 하나의 포트에 2개 이상의 인증서 설정이 가능하게 해주는 것입니다.

 

아파치의 경우, 아래 조건이 충족해야 하니, 참고 부탁드립니다.

 

Web Server : 2.2.12 이상

OpneSSL : openssl 0.9.8f

1. cd c:\inetpub\adminscripts

2. 명령 프롬프트에서 다음 명령을 입력하여 기본 웹 사이트의 SSL 바인딩을 확인
Ex) adsutil get w3svc/1/SecureBindings

3. 바인딩 제거
Ex) adsutil set w3svc/1/SecureBindings ""
Https://”로 접근하는 페이지는 모든 화면을 암호화하게 되는데, 암호화된 페이지 내에 http로 시작하는 절대경로가 포함된 개체가 있거나(예. “src"로 불러오는 이미지나 “js”파일 등…) 프레임의 사용으로 인해 보안된 페이지와(Https://) 보안되지 않은 페이지(Http://)가 한 화면에 보이게 되는 경우에 이러한 메시지가 나타나게 됩니다. 

따라서 이러한 경우에는 다른 서버에서 이미지 등의 개체를 가져오는 경우에는 보안된 서버로 이전을 하시고 “html”에 있는 절대경로를 모두 상대경로로 바꾸어주시거나, https://로 바꾸어 주셔야 합니다. 

그러나 작업이 많다면 중요한 개인정보(로그인, 회원가입등…) 트랜잭션에서 “form=https://...”로 하여 중요한 정보를 보안하고 다시 “http”로보내는 방식을 통해 “https”에서 이미지를 로딩하지 않게 하는 방법도 있습니다
Begin, End로 구문딘 X509형식의 개인키와 공개키를 PKCS#12 방식의 키페어 파일로 변환하고자 한다면 UNIX 또는 LINUX에 설치된 OPENSSL을 통해 만들 수 있습니다.

Ex) $ openssl pkcs12 –export –in [파일 이름].crt –inkey [파일 이름].key –out [파일 이름].pfx
1. 해당 웹 문서를 클릭하고 마우스 오른쪽 버튼을 눌러서 등록 정보를 봅니다. 

2. "파일 보안" 탭을 선택하고 "익명 액세스 및 인증제어"에서 "편집"을 선택 합니다. 

3. "익명 액세스 허용"과 "기본 인증"에 체크하고 "확인"을 선택 합니다. 

4. "보안 통신"에서 "편집" 버튼을 선택 합니다. 

5. "이 리소스를 액세스할 때 안전채널이 필요합니다"를 체크하고 "클라이언트 인증서 무시"를 선택합니다.
    나머지는 디폴트 값을 그대로 사용합니다. (각각의 경로에 http://로 설정되어 있는 것을 모두 https://로 바꾸어주어야 합니다)

6. 이제 이 페이지에 접속할 때는 https://를 통해서만 접속이 가능합니다.

※ 이 부분은 웹문서 접속시에 오직 보안접속만을 가능하게 설정하는 부분입니다.
이 설정을 하시면 일반 http://로는 접속이 불가능하며 https://에 의해서만 접속이 가능하게 됩니다.
KEY파일은 웹 서버내에 보관되어져 있는 고객의 개인키로서, 인증기관은 그에 대한 어떠한 정보도 가지고 있지 않으며 가지고 있어서도 안되는 파일입니다. 

인증서는 고객이 웹 서버에서 생성하신 개인키와 쌍이되는 공개키를 인증기관에 보냈을 때, 이를 인증기관에서 심사하여 전자 서명을 해주는 파일입니다.

고객이 개인키를 가지고 있지 않은 경우에는 인증서 설치가 불가능하며, 백업본이 없을 경우 인증서 재발급이 필요합니다.
프로세스 재기동시 비밀번호 입력 없이 자동 시작을 원하신다면 shell script 파일을 생성 합니다.
(인증서 비밀번호가 없다면 다음과 같은 작업이 불필요 합니다.)

[root@localhost httpd]# vi conf.d/pass.sh

#!/bin/sh
echo “password”
* 설명 : 기존 password를 확인하여 수정합니다. (패스워드가 변경된 경우 변경된 패스워드로 수정합니다.)

:wq

※ OS가 윈도우에 설치 된 apache 서버일 경우 key 패스워드를 제거해야 합니다.
한 서버에 여러 개의 도메인을 사용하는 경우 SSL 설치가 가능합니다.
다만 한 서버에 여러 개의 도메인 설치하여 각 도메인이 같은 포트 사용을 원하실 경우 멀티 또는 와일드 인증서로 발급하여 적용 하는 것을 권장드립니다.

SSL 인증서는 도메인 기준으로 발급 되기에 ip가 변경 되어도 영향을 받지 않습니다.

도메인은 동일하나 서버가 이전하여 ip가 변경 됐다면, 새로운 서버에 기존처럼 인증서 설치를 해주시면 됩니다.

기술지원센터

02-512-5495

dev_tech@ucert.co.kr

|

365일 24시간 지원, 유서트